How can changing the ProductCode and UpgradeCode on a deployment project cause an application to now not run at all? Or better yet ... How do you fix it when it does?

Question

I have an application I just deployed built on Win XP Pro SP3 using VS 2008 Sp1 and targeted at Framework 3.5. I built the msi and ran it on my own machine and then on customers machine and everything was fine.  Then customer wanted a small change so I made the small change (same day). Tested the change on my development machine using dev enviroment and then using msi on my machine and both worked fine.  But didn't work on customers machine anymore.

Due to customer needs for different build configurations, I changed the ProductCode and UpgradeCode for the installer so multiple deployments of the same code base could reside in parallel on customers machine.

Now when I deploy and run the msi to install it, it installs just fine but when I run the .exe I get the hourglass-mouse cursor very briefly and then nothing happens.  I have a try-catch around my main code that will log data if any exceptions are thrown during start up or run time. There is nothing being logged and in task manager the app isn't running. It like it never even starts.  Almost like main function gets called but immediately exits.

If I uninstall the app and run the old msi on customers machine then the code runs fine.  I am thinking that for some reason there is a registry setting for a class instantiation that is tied to the old ProductCode or something, but even when I put back the old ProductCode into the msi the app but didn't save the UpgradeCode and still the app won't start on customers machine.  It installs and runs on my dev machine just fine.

Any ideas as to what might cause this?  Thank you in advance. 

Answer 1

If I understand you correctly, the old version works on the client, but if you install the new version it doesn't work.

This doesn't sound like a version issue it sounds like something is wrong with your installation of the new version.
Have you tried building a virgin client machine and doing a blank install to see if it works.
Dev machines are notorious for being able to run everything because all the components are already installed, but the client machines are often missing something required because it is not part of your installation package.

If the program fails at load, then try stepping into the program in debug using F8 and see what gets loaded first as components and ensuring you are installing them all. Also if there are any relative paths or varaibles in the application ensure they are correctly populated when debugging and determine the soruce of all the values, as if any are missing then your applciation may not be able to start

Regards

Rupet

---

the problem is not what you don't know it's what you think you know that's wrong

Answer 2

A few questions:
1) Are there any overlapping files when both are installed, or is everything installed to completely separate folders?
2) Are there any registry entries that are common to both setups? 

Another setup with different ProductCode will work only if nothing at all overlaps.

---

Phil Wilson

Answer 3

Thanks so much for the replies.  After reading a bit more online about it I discovered that the Product Code is not the same as the Package Code. I had lost the original Product Code so perhaps was using the Package Code when I thought I had the Product Code and the app was being installed to the exact same directory location using two different product codes. Still not sure why that would be a problem, but ...

I got past it by changing the Product Name(which was used as the installation folder) in addition to changing the Product Code.  I still don't understand what exactly was causing the problem.  There are absolutely no registry settings being set or required by the code in my application or added by me in the MSI.  The only ones in there would be ones that are required by all apps (CLSIDs, etc) via the windows installer MSI running.  I don't add any in my project nor access any from my code.  I use XML files for all my configuration and keeping state needs instead.

So the answer to common registry entries would be, "No" except for any tied to the installation due to the install being done by the MSI.  I guess I wrote it a bit confusing when I said I have two installations ... I do have two separate installs call them A and B, but they don't share any files and it wasn't a matter of one working and the other not. It was that one was working let's say build A and then after removing build A and making a small change to build A and a product code change to build A so now build A+, it then gets installed to the same exact location on the machine as where build A used to be and it wasn't working. But by removing build A+ and then installing build A again to the same installation location the code would run again. All the files were the same between the apps except for one DLL where the same change occurred which is independent from all the other DLLs.

Build B never got removed nor changed. Only build A. Weird huh?

As far as shared files, the two different apps each get their own copy of all the files.

It has something to do with the Product Code and the installation location or CLSIDs in the registry and or shortcuts created to access the app.  Once I changed the Product Code and the name of the installation folder and name of the short cut then I could install the build and it runs just fine.  Both builds A and B run just fine now.  I haven't yet tried to make more changes, but I will by the end of the week.  I'm hopeful that this is a very obscure issue that will not manifest itself now that I am keeping the Product Code and Upgrade Code the same as the previous installation.

The weirdest part was I could copy all the files from my dev machine over into some folder and it would run just fine, but using the installer for build A after changing the Product Code but not changing the installation directory and shortcut name (build A+) neither the shortcut nor the actual app.exe would run.  Double-Click and it would just give a short hour-glass and then nothing.  I've been doing development for about 16 years on PC's using many languages and versions of windows and installation packages, everything from Win 3.11 to Win XP Pro or Server 2003 and every language from Prolog to Small-Talk to Visual Basic to Java to C++ to C# and I'd never seen where the exe would not even run just by changing the product code on an MSI.

Again thanks for the replies but I wouldn't spend any more time on this one unless you are one of those guys who just has to figure out 'WHY?' because a work around is not the right way to go in principle.  Sometimes we don't have enough time to figure out the true cause so I'm OK on this one with just knowing that somehow I'd gotten things in a bad state and I should always change the installation location if I am going to change the Product Code.  Maybe I'll read up on it in a Microsoft book someday but for now our company has started moving away from MSI's but I had to get this one out the door and MSIs is currently how our installation package is set up.  I like the method of just zipping up the working directory and xcopy the thing over and it works. :)

Thanks again and best of luck in your development efforts.