Thursday, July 17, 2014

Retargeting a Windows 8 application to Windows 8.1

Apparently, fuck Windows 8. So says everybody. Including Microsoft. That's why at some point you're going to have to retarget your Windows 8 app (if you were crazy enough to make any) for Windows 8.1. Fortunately, Microsoft provides a guide for doing so in Visual Studio 2013 here. Fortunately, it's as simple as right-clicking on your solution in the Solution Explorer and clicking on Retarget for Windows 8.1

Labels: , , , , ,

Tuesday, July 15, 2014

Making TFS builds consistent with desktop builds when invoking MSBuild directly on a .*proj file

As it turns out, MSBuild has more than a few quirks when being invoked through TFS compared to being invoked through a command line or from Visual Studio. Some of them are pretty well document. Others are not, like the fact that in a .*proj file, the OutDir variable is inherited to sub-MSBuild tasks.  There's also quirks because OutputPath is used to determine OutDir, but not in all cases. If you're going to specify OutputPath in the properties when invoking the MSBuild task, you should also explicitly override the OutDir variable as well to ensure consistency, unless you **TRULY** understand the differences between the two and how MSBuild determines OutDir, and you **REALLY** want it to be that way.

Labels: , ,

Thursday, June 26, 2014

Getting code signing to work with ClickOnce on a TFS Build Agent

Code signing is a giant pain in the butt. You have to :
  • Obtain the certificate for signing the code by:
    1. buying the certificate from an issuer.
    2. generating your own self-signed certificate
  • Configure ClickOnce within your project file with the following property elements:
    • true
    • A387B95104A9AC19230A123773C7347401CBDC69
  • Log into your machine **as the user running the build controller / agents ** and import the key to their user Personal certificate store!
You should now be able to build and sign your code on a TFS Build controller / agent.

Labels: , , , , , , , ,

Sunday, June 22, 2014

Converting an existing Windows Store app to using the Prism Framework

I began converting an existing Windows Store App to using the Prism Framework provided by Microsoft. However, I'm running into the following error:

The primary reference "Microsoft.Practices.Prism.StoreApps" could not be resolved because it was built against the ".NETCore,Version=v4.5.1" framework. This is a higher version than the currently targeted framework ".NETCore,Version=v4.5".

This post on recommends installing the Microsoft Build Tools 2013 package, which is available here:

That didn't work.

I later realized that I had installed Prism with NuGet, so I went and checked the publishing dates on the versions. The latest (and default, which I had installed) was 1.1.0. The date on 1.0.1 was much older, and after reverting to that version, I was able to get my program to compile and run with a few modifications to the steps in this tutorial. The modifications are as follows:

  • Change the return type of the App.OnLaunchApplication method to 'void' to match the 1.0.1 version of the Prism.StoreApps library.
  • In the App.OnLaunchApplication method, ensure that there's a call to :
    • NavigationService.Navigate("Main", null); where "Main" is the initial page name, and there's a MainPage class in your Views folder.
  • Move the existing MainPage class into the Views folder in the root of the project.

Labels: ,

Creating my first Windows 8 store app

As you may or may not be aware, there are multiple types of applications that can be created for Windows 8:

  • Windows store apps, which use the new Metro interface
  • Desktop-based apps which are like those created for previous versions of Windows that can still run in the Desktop app.
I'm quite familiar with creating WPF apps for Windows, but Metro apps are new, and those are what I'll be working on. With that in mind, Microsoft provides the Prism framework which helps provide additional classes, interfaces, events etc to help people develop Windows Store apps that keep consistent with Windows 8 design principles and help the apps perform properly. I'll be starting with the MSDN link here.

Labels: , , ,

Beginning to work with Windows Store apps

I really hate Windows 8. I think the majority of the applications that have been written for it are complete pieces of shit, for the following reasons:

  • The developers who wrote them didn't pay any attention to Microsoft's best practices and they :
    • perform poorly
    • don't follow UI conventions and are hard to understand as a result
    • crash 
    • don't always save data properly
  • Many are piss-poorly written and adapted by third party developers for first-party systems because those first-parties don't want to write software in a competing ecosystem, and instead want to force users to use their ecosystem, which has their own set of flaws and deficiencies. Case in point: Google. At the time of this writing, there are no native Windows 8 applications put out by Google. There's no native YouTube app for Windows 8 (which there damn well should be), presumably because those fuckers couldn't find a good way to generate advertising revenue in a Windows 8 app. (can't really blame them for that because if I see ads in an app, I immediately delete it from my device without hesitation. I can't stand that shit.)
  • Windows 8 is a shit operating system. It was built on the new Modern interface (aka Metro), and initially had piss-poor integration with the desktop paradigm on which all previous incarnations of Windows were based. Add to this the fact that Microsoft didn't give people an easy choice of which paradigm they wanted to use right off the bat, and the fact that in successive iterations like Windows 8.1 they've tacked on hacky additions to make the Metro interface more like the previous desktop interface, you end up with a shitty operating system that's a pain to use; this pain stems from the fact that it's a horrible amalgamation of multiple user interface paradigms. 
As long as Microsoft continues to force their shitty iterations of Windows on the world, I, as a software developer, will be forced to deal with it because of the immense investment most employers have in Microsoft technology. With that in mind, I'm going to start learning Windows 8 applications so that I can make myself more marketable to employers everywhere. I'm going to document my learning here for my usual reasons:
  1. So that I have a reference for myself for the future
  2. So that others may learn more easily what I have learned.

Labels: ,

Tuesday, June 17, 2014

Resolving ssh: connect to host port 22: Connection refused

There are a number of reasons why an SSH server may fail to allow a client to connect. Many aren't readily apparent, even from tailing system log files or using ssh -v on the client. Here are some of the ones I've encountered:

1. Incorrect permissions / ownership on the key files in /etc/ssh/
2. Incorrect permissions / ownership on the ~/.ssh/id_rsa private key file of the user as which we're trying to connect. I'll add more to this list as I encounter them.
3. systemd just plain being a piece of shit. Running 'systemctl restart sshd.socket' has fixed the problem in the past.

Labels: , , ,

Wednesday, May 28, 2014

Apache fails to handle requests with " must be installed for pthread_cancel to work"

I recently had an apache2 server go down while I was using it. I still don't know what caused it, but I do know how I fixed it, thanks to this thread on Launchpad. Adding to the ld pre-load got me back up and running.

echo "/lib/i386-linux-gnu/" >> /etc/
The value echoed is the path to the file on your system. It can be found with:
I hope this helps anybody who has a similar problem.

Labels: ,

Thursday, April 03, 2014

Waiting for the network to be up on the BeagleBone Black

It finally hit me today as I was reading over this article, and it should have hit me sooner. The article mentions that in order to get past the network startup hurdles in systemd, you need to wait on the NetworkManager service. However, I use connman. It didn't occur to me until today that they provide exactly the same functionality, and I just needed to swap one with the other. Now,  I have all my network dependent programs simply After=connman.service in the systemd service descriptor files, and they're golden.

Labels: , , , , , , ,

ImportError: No module named pkg_resources when trying to use pip on the BeagleBone Black

I've recently been trying to use Python on the BeagleBone Black, for a number of reasons:

  1. I want to learn a new language which could be useful to me in another job in the future (and this job, even better!)
  2. Given all the effort I've put into making our embedded systems work on multiple platforms, I think I've finally got enough infrastructure in place that we can start leveraging other cross platform products to shorten up our development time.
  3. As a scripting language capable of using bindings to other languages, Python should help me create very functional code that doesn't need extremely high performance in a very short amount of time and reduce my development time for complicated tasks.
Unfortunately, like many other things on the BeagleBone Black, things aren't going as well or as simply as you'd think they should at first glance. For starters, the pip package manager for Python isn't installed by default on the BeagleBone Black (at least not as of the 2012.12 image). So, I had to install that first:

opkg install python-pip

When I tried to run the package manager, I ran into the following error:

Traceback (most recent call last):
  File "/usr/bin/pip", line 5, in
    from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

After Googling around for a bit, I found these questions on Stack Overflow. Apparently you must also have the setuptools package installed in order to be able to use pip because it's not a simple package manager like apt in Ubuntu. It's more like emerge in Gentoo, where it downloads code packages and is capable of compiling them and performing custom installations. Fortunately, there's an opkg package for that:

opkg install python-setuptools

After that was installed, it became a simple matter of finally importing the actual package that I originally wanted that started all of this:

pip install psutil

... the process utils library for Python

Labels: , , , , , , , , ,