How to update (merge) web.config using web deployment (msdeploy)?

Question

I am trying to set up the deployment chain for some of our ASP.NET applications. The tool of choice is Web Deploy (msdeploy) - for now. Sorry, I ran into a problem.

Thus, a brief overview of the circuit:

• The web developer creates the code and validates it in SVN;
• Buildserver sees the update and builds the .zip package for the msdeploy website.
• . The ZIP package is automatically placed inside our installer and sent to various clients;
• Clients run the installer on their web server (-s);
• The installer uses the built-in msdeploy to deploy the .zip package and create a new website or update an existing one.

Msdeploy makes it easy to deploy a new instance, but I don’t understand how to install the upgrade. The main problem is the web.config file. Each client would certainly make some adjustments there to suit their particular environment. The installer himself suggests setting some more important parameters during the first installation (achieved using the msdeploy parameter mechanism), but they can be done manually by others.

On the other hand, developers also sometimes make changes to web.config, adding some new settings or removing obsolete ones. Therefore, I cannot just tell msdeploy to ignore the whole file. I need some advanced XML modification mechanism. It may be a script that is supported by the developers, but then it should be run ONLY when updating, and not in new installations.

I do not know how to do that.

In addition, sometimes there is absolutely fantastic update logic. For example, the application comes with our company logo, but some customers have replaced this .png file to display their own logo. Recently, we needed to update the logo, but only for customers who did not replace it.

Similarly, there may be some cache folders that might need to be cleared when updating NOME, but not in others. Or folders with custom content that cannot be affected (but come with default content on initial installation). Etc.

How do you usually achieve this double behavior for msdeploy packages? Do I really need to create 2 different packages for each application?

Answer 1

Suggestion from personal experience:

Isolate Settings

Your customers should be able to customize their settings, and the best way is to provide them with something like an override file. Thus, you install a new package and follow it, superimposing your client settings on top of the standard setting. If its a new installation, then nothing to overlap.

> top-level -- > standard files | images | This will never be touched or changed by customer settings.txt | __ > customer files -- images | Customer hacks this to their heart content settings.txt_override | -- 

Yes, this means that some kind of merging process should happen, and there should be some kind of script that does this, but this approach has several advantages.

• For settings that suddenly become redundant, simply issue a warning about this.
• If the client has its own logo, you can specify it in the override file
• The message is clear to customers. Stay away from standard files.
• If clients request more custom parameters, then write by default if it does not exist in the override file during updates.

Vilx, in response to your question, the logic for determining whether it is an update or not should be contained in the script itself.

To run update script before installation

 msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat" 

Or run update script after installation

 msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat" 

More here

As for how you know its update, your script can check a text file called "version.txt", and if it exists, the bat script will be updated. The version must be contained in a text file. The bit is basic, but it should work.

It also gives you the added benefit of allowing you to more elegantly combine client custom settings between versions, since you know which properties can be overridden for that particular version.

Answer 2

There are some general suggestions (not related to msdeploy), but I hope this helps:

• I think you will need to provide several installers in any case: for the initial setup and for each update from version to version.

• I would like to offer my clients to merge the configuration files themselves. You could simply provide them with either a detailed description of waht that has been added / changed / deleted and / or include a utility that simplifies merging. Perhaps this and these links will give you some pointers.

• As for merging replaced logos, another client setup, I think that the best approach would be to support branding your application. I mean, move all the branding data to a place where your new update installers will not touch this.

• as for the other adjustments made by your clients, they do so at their own peril and risk, so the only help you could provide is to include a detailed list of changes (perhaps even a list of modified files from the previous version) and the How- article To merge sources with tools like Araxis Merge or similar

• Or .. you can create a utility and include it in the installation program, which will try to perform all complex merging on the client machine. I would not recommend this, as it requires a lot of effort / resources.

• One more thing: you could focus on backing up your previous client copy before upgrading. Thus, even the client will have problems with the update - it will always be possible to roll back. The only thing you need is to provide a good feedback channel that your customers can use to shoot their problems. This feedback will allow you to find out what problems your customers have and how to make the update process more comfortable.

Answer 3

I would rely on the above, but I would do it with transformations and rigorous documentation about who is setting something up. How you do this now depends on client intervention in the configuration, which is critical to the application deployment process.

Create three areas of configuration files. One for development, one for building "generic" and one that is an empty template for editing by the client.

• The development instance should be self-evident. This is a transformation that accepts a generated product template and creates a web configuration for your development server. (it looks like you are aiming for a process like CI here)
• The production generic transformation should install the application for a hypothetically perfect instance of the application. It will look like installation if the architect had his own way.
• Client transformation is used by clients to customize web configurations as needed to meet their own needs. Write some documentation and see what happens. Edit documents when you help clients in this process.

Is this what you were looking for? Thoughts?