How to force deployment project to update files during installation of newer version?

Question

I have a Deployment Project for my VS2008 C# application. When installing a new version of my application I want to make sure that files are updated with the files contained in the installer.

I want my installer to automatically remove any old version of the installed application. To do that I follow this procedure (also described here):

1. Set RemovePreviousVersions to True
2. Set DetectNewerInstalledVersion to True
3. Increment the Version of the installer
4. Choose Yes to change the ProductCode

For the assemblies I make sure the AssemblyVersion is set to a higher version:

[assembly: AssemblyVersion("1.0.*")]

Everything is working as intended except for my configuration files (xml files). Since I cannot find a way to "version" these files I cannot make sure that the files are updated if they have been modified on the target machine.

Is there any way to do this and how?

UPDATE: I have tried the approach/solution/workaround found here

1. Include the file directly in a project with the following properties: "Build Action -> Content file" and "Copy to Output Directory -> Copy always"
2. Then add it to the deployment project via Project Output->Database->Content Files

Unfortunately it did not make any difference. The behavior is exactly the same.

Vervet

You say you "cannot find a way to "version" these files", but are you certain they are not being overwritten correctly on (re)installation? – Youngyoungblood

Yes, I am sure of that. I can see that the content of the files is not updated and the Date Modified of the xml files never changes. When doing a repair using the msiexec with the /fa switch the files are correctly updated. – Vervet

Answer 1

If you're willing to use Orca (there may be another way to do this method, but it's the only one I know of) you may be able to set up RemoveFile directives.

See here for a typically light-weight MSDN document -- could be a starting point. http://msdn.microsoft.com/en-us/library/aa371201.aspx

Alternatively you could always create a very simple bootstrapper executable that simply calls "msiexec /i REINSTALLMODE=oums" (or whichever command-line switches are needed). Call it setup.exe if you like...

Better option long-term may be to switch to InstallShield or similar -- VS2010 includes a light version of IS and I believe they're moving away from vdproj projects.

Youngyoungblood

I was hoping that something as simple as "Always override" could be done easily but that seems not to be the case. Thanks for the alternatives. – Vervet

Answer 2

Add the following property to the Property table of the MSI: Property REINSTALLMODE with Value amus

Note: This will cause all the files in the MSI (versioned and nonversioned) to overwrite the files that are on the system.

Federalize

How do I add properties to the property table of the MSI? Is that something I can do in the post build event of the installer? – Vervet

I do this using InstallShield. Another way is to use ORCA to add the property to the MSI after it is built. – Federalize

This is almost never safe as it may trigger reinstall of system files installed by merge modules. This may downgrade system files on older versions of Windows or trigger a file protection error on newer versions of Windows. Consider using emus instead (replace files with same version) over the normal omus (replace files with lower version only). – Pict

This is VERY safe in most circumstances because you should NOT be installing system file merge modules in your application installs. (msdn.microsoft.com/en-us/library/…). The application installation should not install files into the system folder and current versions of Microsoft files should be installed using the supplied MSI or exe and NOT using merege modules. A bootstrapper can be created which contains the application MSI and the Microsoft install if needed. – Federalize

THANK YOU! I have been trying things for the last few hours and this is the only method that actually worked for me – Bolte

Answer 3

Have you tried the approach/solution/workaround found here?

1. Include the file directly in a project with the following properties: "Build Action -> Content file" and "Copy to Output Directory -> Copy always"
2. Then add it to the deployment project via Project Output->Database->Content Files

Futurity

I have tried your suggestion. Unfortunately it did not make any difference. I have updated the question. Thanks anyway. – Vervet

Answer 4

I may be incorrect here, and therefore I am exposing myself to down votes, but here goes anyway!

I believe it is on purpose that config files do not automatically get overwritten; the principle there being that you would not normally want your application's configuration overwritten when you install the new version of the program... at least not without numerous warnings and/or chances to merge configuration first.

Having your application configuration get overwritten by an updated version of a program could make for a very upset end user (in this case, web site admin).

---

Further, I know that sometimes, the developer may be the person doing the deployment. In such a case, this behavior might not seem so logical when deploying a single site to a single server; but when roles are split and/or you have multiple servers with different configurations, this can be a life saver.

Impanation

I agree that explains the reasoning behind the behaviour but the OP is looking for a fix :) I am not sure there is a clean fix though – Youngyoungblood

Yup; I got a little carried away with myself, and sorta forgot to mention, "I don't think it's easily fixed because..." first. Probably will take some custom action work. – Impanation

We have used Custom Actions and they're fairly powerful but can leave you open to all sorts of problems -- e.g. you can call an executable, but if that executable has been deleted at some point later the package cannot be uninstalled! Also they're very hard to debug... YMMV – Youngyoungblood

I am aware of the intended behavior of such configuration files although I think it is more "clean" to have user preferences in a separate file not contained in the project. I need to update these xml files to make sure any new settings (or changed default settings) is renewed. – Vervet

The problem is not limited to "configuration" files though, any data files -- images, other resources are affected. It's a real shame Microsoft didn't add an "Always Overwrite" property. – Youngyoungblood

Answer 5

You need to include the new version of your files in your custom installer and manually install these file during Custom Install routine is called This must be applied to any file that does not have version that can be tracked by the installer.

Detrimental

Answer 6

The way I did for all files that cannot support versioning is to include the files one by one, or as a zip, or anything you need in the resource to install over the existing files. During installation (Custom Installation session), I will copy the files from the resource over the installation folder. That works 100%. It is working for VS2010, 2017, 2019 or any version of VS that can support VS Installer. My installer is created using VS Installer and add custom sessions to handle the installation of these files. By using Custom Installation session, I actually can create any custom forms I need like you have in the actual application developed with VB.NET or C#. The only thing is this only happens after the main installation already installs the files to the target directory. Custom session cannot run before the main routine of the installer. https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2022

Detrimental