by Miha Markič
6. August 2009 19:06
Lately I’ve built a .net class library that supports COM as well. To make setup file I usually use Visual Studio’s Setup Project because I rarely do anything complicated during the installation ant Setup Project does the work fine for me.
This time the setup was a bit different, more complicated, because I needed to register my COM stuff during the installation. So I’ve built the setup file and tried the installation inside VMWare Workstation’s guest as I always do. COM objects were registered fine but type library (TLB) wasn’t registered at all when setup project is built on Vista/Visual Studio 2008. The later isn’t strictly required for running the code but it surely helps developers with strong typing support. There are several options to solve the issue ranging from building on XP to coding the post install/uninstall actions. Well, none of them looks very appealing to me thus I’ve decided to try the Advanced Installer from Caphyon this time.
I can say that creating a setup file for my .net application with Advanced Installer was a breeze – I had a working MSI setup in 10 minutes. The process consisted of importing the Visual Studio Setup Project (which I already had – I could start from scratch or by importing the library project) and adjusting few properties. Truth, mine wasn’t a complicated one but it surely solved type library registration with a click on the checkbox. It actually solved my problem in 10 minutes. Any other option would be either more annoying or it would take more time.
Advanced Installer is not just easy to use. It looks like a powerful and flexible authoring tool as well and certainly not limited to (simple) .net applications only.
by Miha Markič
27. June 2009 19:22
Let’s say you’ve build a WinForms application and put some DevExpress (or any other 3rd party controls installed in GAC I suppose) controls in there. At some point you have to deploy the application and let’s say you’ll use ClickOnce technology. Its easy, go to Project Properties/Publish tab, select where to publish and click Publish button. The next step is to try the application and of course you try it at your development computer – it works, no surprise there. However, when your client runs it on his computer it will most probably throw some sort of exception at the very beginning. Besides the obvious Murphy law involvement, why’s that? After all it worked on *development* computer.
There are two problems in this process.
1. ClickOnce doesn’t include 3rd party assemblies by default. This is probably true for all 3rd party assemblies that reside in GAC on development computer or in other words, those which are marked with CopyLocal=false (I admit it, I never researched in details). It should include those who are marked CopyLocal=true. Now, if you look at your Application Files in Publish tab of Project Properties you’ll see that all three DevExpress assemblies are marked with Publish Status = Prerequisite (Auto) flag – it means that your application expects those assemblies already installed on target machine:

To include them in your deployment package change their Publish Status flag to Include. Like this:

All required assemblies will be published to client’s computer and the application will work, or at least will work as good or as bad as on development computer.
2. Your testing process isn’t good. You should always test deployment scenarios on non-development machine(s). VMWare Workstation is of great help. Besides the great virtualization desktop platform it also support integration in Visual Studio itself so you can pretty easily launch application in guest OS or even remotely debug it and even record the session. The other virtualization option on desktop is MS’ VirtualPC, an inferior application but free. You could use virtualization servers as well (MS HyperV, VMWare Server, etc.).
That’s it.