Developing For .NET

I have not needed to create a Setup project since installing VS2008, but this afternoon I needed to share a utility program with a coworker friend of mine (who is not technical), so I opened the solution and added a Setup and Deployment project. Everything seemed to be fine. I added the primary output of my application’s project and adjusted the company name and product name properties, as well as some other settings, just like I used to do in VS2005.

The problem occurred when I wanted to create Start Menu and Desktop shortcuts for the application. In VS2005, double clicking the Application Folder would show you the list of DLLs, EXEs, and other files that would be installed. You could right-click the main project output file and create a shortcut to the program, which could then be copied to the User’s Desktop and User’s Program Menu directories. And you could also add icons and assign them to the shortcuts.

This was what I wanted to do in VS2008, but double clicking on the folders in File System does nothing. As a result, you cannot select the output file as instructed in the MSDN documentation. This is very frustrating: the Setup and Deployment project has always worked well for me (these are internal distribution installers), but now with VS2008 it no longer appears to function properly. The resulting MSI did work and did install the software, but without an icon and without shortcuts in the desired locations.

If you know the solution for this, please leave a comment. If I find a solution to this, I’ll be sure to share it. For now, all I can do is share the pain.

Like a lot of other developers, I use the Setup & Deployment Projects in Visual Studio 2005 to create MSI files for software installs. Typically, this is a Windows Forms based application. For our in house users, especially those testing new software, there could be many iterations of a piece of software. Of course, this means installing the updated version every time I make a correction or add a new feature. Unfortunately, this has also always meant uninstalling the previous version using the trusty old “Add/Remove Programs” option in the Control Panel. Needless to say, this tends to grate on the users nerves after the first 20 reinstalls.

So, you might be wondering why I did not simply use the RemovePreviousVersions Property of the Deployment Project. The problem was that it never worked. I would set that property to TRUE and still the installer would not proceed until the previous version was uninstalled. While I found this truly annoying, it was never a big enough deal to spend a lot of time trying to figure out why the property was not working as expected… until now…

Have you ever ignored a problem until one day you just say “darn it – I’m going to figure this out no matter what it takes!”? Well, for whatever reason that was my attitude this morning. And fortunately for me, it didn’t take too long to figure out. The key is in the property name itself: RemovePreviousVersions. It is the Version part that somehow managed to elude me all this time, and therein lies the secret: I was never changing the version number. I had always focused on the Previous part before, assuming some kind of temporal meaning, incorrectly assuming that Previous meant Prior. Sometimes, our own brains just get in the way.

Of course, once I read it properly, the solution presented itself: I needed to change the Version number. I think part of my mental block here is that Versioning never occurred to me. If I remember correctly, in Visual Studio 2003, you specified a wild card and versioning happened automatically. That doesn’t appear to be the case now: I’m not saying it isn’t, but I am saying that I’m not going to take the time to investigate it. What I am going to do, from now on, is increment the Version property of the Deployment Project whenever I am preparing to deploy the Installer.

I’m going to chalk this one up as a Homer Simpson “DOH!” [slaps forehead], but hey, we all have them! Maybe this one can help someone else get over the same hurdle.

So I’ve been developing Smart Device apps for the last two years, both in VS2003 and now in VS2005. But as the only CF developer in a tiny shop, I have always been able to install them by just using the Deployment option in Visual Studio. Now, however, one of the products I’ve been working on is ready to go to the field for some testing, which means other people have to be able to install it.

Frankly, most of the documentation on deplying CF.NET apps is pretty scary. CAB files, custom INI files, Registry entries, the works. I’ve definitely been spoiled by the MSI features available to Windows forms apps. So I’ve been digging around and experimenting, and I created a CAB file for install and then found the Smart Device CAB project, so I created that but it still required the user to manually copy it over to the device and double click it and yada yada yada. Too much for most of my target audience, and not very professional.

So I dug some more, and I was about to give up, when I found this article on MSDN about using MSI to handle the install to a Smart Device. I went through the article, and after a little trial an error I got it to work. Here are the highlights:

1. Create your solution and build all the projects. Use Release to keep them as small as possible.
2. Add a Smart Device CAB project to your solution. Add all your project outputs to the applications folder and add a shortcut to your EXE to the Program Files folder. Build this project.
3. Add a new Class Library project to your solution. This is an MSI installer helper class that handles events like before_install and after_install. The cool thing is that these events will be found and used automagically later. Fill out the events and build this project. This file has some Registry stuff in it and references a custom INI file that you will need to create, but the forumla is very simple.
4. Add a new Setup project to your solution. This will be the MSI file that is eventually used to communicate with ActiveSync and install the CF application. By adding custom actions to the installer and referencing the helper DLL we created in step 3, the before and after events will automagically find themselves and fire.

OK, so this is in no way a step by step instruction list. For that, you will want to read the article (like 20 times). It is a little dense but thorough, and I was able to get it to work. I did encounter a permissions problem in the afterInstall event, so I still need to hash that one out, but it did install the app on my device.

One quirk I found was that the article instructs you to add a reference in the MSI project to the System folder and to place your output there for the CABs and the INI file. Unfortunately, this doesn’t jive with the pathing samples in the Helper class code in the article, which references System/TEMP/MyProject. In looking at it, I think the TEMP path is the best way to go, so just create the TEMP/MyProject path in the System special folder and dump your output CAB and INI files there.

Next I’ll be tackling how to integrate CF .NET deployment in the same MSI, so stay tuned.