Xml transformations woes

Hi,

Using Octopus 3.2.3

I have some important changes to web.config that needs to be performed on deployment. These changes includes removal of sections (e.g. httpmodules) etc. I do NOT want to have these transformations in source control. These are deployment specific changes that should be handled by Octopus…

Now I see that I can’t really store such transformation files in Octopus. And I can’t specify the transformation xml either right? Only option is to specify e.g. “customerX.config => web.config”. Problem is that “customerX.config” is not in the nuget package. I have tried to put the xml transformation file on the Octopus server and then to specify “c:\tx\customerX.config => web.confg” but that hits an exception (System.ArgumentException: Second path fragment must not be a drive or UNC name).

What can I do here? This is really important for us…am I missing something?

With thanks…

Hi,
Unfortunately as you have discovered Octopus Deploy does not support absolute server paths or server-embedded transform documents. Our best suggestion for this is to either convert the documents to use variable replacements for full Octopus Deploy management, or use a tool such as SlowCheeta to perform the XML transforms during the build process. Scott Hanselman wrote an interesting blog detailing how it all comes together. Remember that these transforms themselves can result in files that, coupled with the variable replacement feature in OctopusDeploy can still inject the deployment-time variables you are after.
I’m sorry this isn’t the perfect solution you were hoping for but hopefully this helps you achieve what you are after.
Robert

Ok I solved it like you suggested. I’m doing the transformations in Teamcity using a small powershell script. Then in Octopus I just run the variable substitution routine on web,config. Works quite alright…

Thanks.

Hi,
Great to hear that you got it sorted out. Give us a yell if you get stuck again and we would be glad to provide help to get your deployments going again.
Cheers,
Robert