shahine.com/omar/

I have successfully built and used the MSI support in visual studio now for many projects. However I keep cutting myself with two problems.

RemovePreviousVersions doesn’t always work.

I just found out a little gem. If you rely on this feature there is NO WAY to garuntee that it will work. If the end user installs the first version of your product using “just for me” or “all users” and then they change their mind the second time around (on upgrade) the old version won’t be removed.

This has been a mystery for me for a long while now. I’ve been stumped, and I found the answer on Usenet. What a bummer. Any suggestions?

COM registration doesn’t always work

There is absolutely no way I can figure out a rock solid 100% foolproof way of doing regasm on a dll at install time (to register a .net dll using COM). The built in MSI property vsdraCOM does not work. I verified this on my desktop machine at work. But it works fine on my laptop. Go figure. I even wrote a custom Install action and I found out that this doesn’t work on at least one person’s machine.

I’m beginning to realize that my time is better spent doing other stuff then messing with any .NET class that needs to be exposed as a COM object. I’m just going to start pretending that this feature doesn’t even exists so I can stop cutting myself.

The reason I ran into this problem recently was to add contextual menu support to the Windows Explorer for individual jpeg files. Yes, you can do this with a registry entry (which is what I do for folders), however, if you select more than one file, the shell launches n instances of your application rather than bundling up the files as multiple arguments. Making a Windows Forms app that forces only once instance of itself to be running is non trivial and involves such things as .NET remoting which I know zero about. That leaves you writing a lot of horrible code to impliment weird COM interfaces, and exposing your class as a COM Class in .NET.

Sigh. Perhaps this will be fixed in Vista.