We've been using the MSI editor inside VS 2005 and 2008 to build setup packages (DetectNewer = true, RemovePreviousVersions=true, incremented version property & updated ProductCode). All of our installation sites have been using Installer 3.1.

What we've noticed is that a good amount of the time (perhaps 50%), when the user runs the MSI, one or more of the existing DLLs on disk will not be replaced with the newer version from the MSI. We crack open the MSI with Orca and verify the version number of the files in the MSi against what was deployed to disk in order to make that assessment.

I thought this might be a defect in 3.1, which is quite old at this point, so I upgraded to 4.5 on my development box (XP SP3) and on one of our test servers (W2K3 SP2), but I don't see any improvement on either.

Thoughts?

Thanks

Visual Studio 2008 RemovePreviousVersions does not behave the same as Visual Studio 2005 RemovePreviousVersions, that might be what you're seeing.

2005 is essentially an uninstall of the previous product (and its files) followed by installing the new product and its files. Because of this, file versions are irrelevant.

2008 is more of an update at the file level. The upgrade will replace versioned files only if the version in the incoming setup is higher than the version already installed, all other things being equal (you didn't set the "Don't overwrite" property).

Dates are not used as criterion for updating a file, a "new" file will not replace an "old" file. Windows Installer has been around for at least ten years, and that's the way it has always worked, as at those MSDN links.

---

Phil Wilson

Hello Mininow,

Thanks for your post on MSDN forum.

I performed a test on my side, but I cannot reproduce this issue on my side. How did you package these Dlls? Are these Dlls from a Merge module? If the Dlls is from a different, theyare considered asdiffirent Dlls, and will be installed without replacing the older ones(usually they gets installed into WinSxS folder).

Based on my understanding, the upgrade mechanism for Visual Studio 2005 setup project and Visual Studio 2008 are different. In VS 2005 the older files is removed before new files get installed. However,inVS 2008 the uninstallation of the older files is at the end. And here is the file version rulefor MSI. This means both VS 2005 and VS 2008 setup project can upgrade the file if it matches the File Versioning Rules.

File Versioning Rules
http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx

Let me know if this helps, if not, could you please show usthe detailed steps to reproduce the issue? So that we can repro and investigate the issue locally.

Thanks,
Rong-Chun Zhang
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

We package the files simply by adding a setup project to the solution, then adding the primary project output of several other projects to the setup project.

The link you reference only mentions date as being a criterion for unversioned files. Is that correct? I would have thought date would have been the major criterion for every time of file (newer being better), especially for files with the same version (file version numbers obviously stay the same for projects not subject to a build process or manul renumbering).


Thanks

Visual Studio 2008 RemovePreviousVersions does not behave the same as Visual Studio 2005 RemovePreviousVersions, that might be what you're seeing.

2005 is essentially an uninstall of the previous product (and its files) followed by installing the new product and its files. Because of this, file versions are irrelevant.

2008 is more of an update at the file level. The upgrade will replace versioned files only if the version in the incoming setup is higher than the version already installed, all other things being equal (you didn't set the "Don't overwrite" property).

Dates are not used as criterion for updating a file, a "new" file will not replace an "old" file. Windows Installer has been around for at least ten years, and that's the way it has always worked, as at those MSDN links.

---

Phil Wilson

Hello Mininow,

I am writing to check the status of the issue on your side. Would you mind letting me know the result of the suggestions? If you have any additional question, welcome to post here.

Have a great day!

Thanks,
Rong-Chun Zhang
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.