views:

228

answers:

4

I'm having a rather annoying and time consuming problem with a .NET program. Our clients all use a piece of software we wrote in Visual Studio 2005 (running .NET framework 3.5). The application is a setup project that gets its files from another project. The problem is that whenever I do a code change and upload the new version to the server, certain pc's don't get the change. Here's the steps we do for upgrading:

  1. Uninstall the old software using Add/Remove Programs.
  2. Reboot the machine.
  3. Go to our website and run the setup.msi file.
  4. Install the new software.
  5. Run the application.

The problem is that when they run the application, they are still getting the old version. It only occurs on certain pc's with no particular pattern. I'm positive it's not internet caching because a co-worker copied the msi file over there directly through ftp. We get around the problem by copying our installed directory, including the manifest, deploy, exe and all that stuff, onto their pc. That seems to work, but it shouldn't be necessary. I'm stumped. I've tried everything. I can't duplicate the problem--the setup works fine for me; even if I have the old version, it upgrades it. Is Windows somehow caching the setup or something I should know about? Please help :) Thanks!

A: 

The issue may be related to chaching on the download side. If it were me, I'd make sure the msi included the version number in it's name (e.g. MyAppInstaller_1.1.3.msi) to ensure that nothing funky is happening on the download.

ZombieSheep
I'd agree - i've seen this sort of download cache problem before particularily with corporate proxies.
morechilli
Even if I'm not using a browser to download it? I've tried it from Filezilla through an ftp but still get the same problem.
+1  A: 

I've had this happen where one of the GUIDs for the MSI was not changed between builds.

Also check the version number. I've had this happen as well where the only the revision number had changed (1.0.0.0 -> 1.0.0.1 is not enough, must be 1.0.1.x).

Jon B
I was thinking about that as well. But then, why would it work on some machines and not others?
Several reasons - older version never installed, installed by different user, MSI not cached or deleted, etc. Worth trying, anyway.
Jon B
By GUID I assume you mean the package code/product code?
sascha
Thanks. I'll give it a try. It will have to be a little while, though, because our customer's maintence guy is coming to do windows updates to the machines.
A: 

Are you sure the target users are UNINSTALLING the older version before installing the new one? I've had problems from users who didn't uninstall the older version, and the new version didn't overwrite it. You can try the following

  • Set the default directory in the installer to a different location than the older version.
  • Give the short-cut a different name (append the version number to it).

Because I don't think caching does anything like this (if files are downloaded through a browser, they're downloaded to a specific location when they're completed and not kept in a cache).

Edit: Morechillies may be on to something. Some corporates may be trying to duplicate the web. It could be proxy caching... But I am not truly convinced.

Cyril Gupta
A: 

You sure you're using 3.5 and 2005?

If you're using 2008, see a discussion of the difference between MSI support on one vs the other.

Having said that, this doesnt explain inconsistent behaviour - it should be consistently wrong. Perhaps in some cases, people are doing explicit uninstalls and succeeding?

Ruben Bartelink