We’ve got multiple installs of an application and based on the installation different certs are used.
Replacement of variables ion the cscfg files only seems to support the configuration variables and not the certificates.
We only want to replace the certificate at deploy time, not at package time (so creating different releases is not an option), i.e. we have the same release (version) deployed to multiple sites that use their own SSL Cert.
What would you recommend is the best way to do this?
I’ve tried putting variables in the cscfg files, but i get build errors because the syntax #{varible} is invalid for the xml specification of this type.
I’ve also looked at xml transforms, but these seem to only support .config files
Practical example from ServiceConfiguration.Cloud.cscfg
This is also an issue for us. We deploy the same application to multiple regions and have different certificates in each. To be able to substitute the certificate thumbprints using the variables would mean that I don’t have to create a deployment package with a different cscfg file in it for each region.
Further to my last post, here is the error i get when trying to package a cscfg file with a thumbprint in format #{variable}
Error 122 The XML specification is not valid: The ‘thumbprint’ attribute is invalid - The value ‘#{varible}’ is invalid according to its datatype ‘http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration:ThumbprintType’ - The Pattern constraint failed. D:\SOURCE\oztix\solCore\Oztix.TABS.OnlineOutlet.Azure\ServiceConfiguration.Cloud.cscfg 104 35 Oztix.TABS.OnlineOutlet.Azure
Below is the XML i used in the file
This does not work, do you have any other solutions?
Thank you for the response. We will look into the powershell script.
Please can you keep me in the loop on further suggestions / roadmap as I
would like to keep this as a configuration setting like the variables so
that non-technical staff can administer this.
I accomplished this by using a pre-deploy script that loaded up the cscfg in an xml dom and edited all of the non standard settings I needed to based on variables (vm name, certs, etc). I don’t have the script handy at the moment, but if people are interested, I’d be happy to post it here.
Have there been any improvements to this? I would prefer not to have to mess with my own powershell script, rather just have a way to replace this with something that passes build.
You should be able to use a combination of deployment features to achieve this:
CloudService.cscfg has your development thumbprint
CloudService.Environment.cscfg has the config transform, but where the value of the Thumbprint, use a Variable Substitution expression: xdt:Transform="SetAttributes(Thumbprint)" Thumbprint="#{MyThumbprint}"
Now when the deployment runs, Octopus will first perform the Substitute Variables in Files, updating your config transform file with the Thumbprints. Octopus will then run the Configuration Transform setting the attribute with the substituted thumbprint.
For more information on the ordering of these features take a look at our documentation.
I do not see a way to enable ServiceConfiguration config transforms. Is there a setting somewhere I’m missing? I can only find ways to manage the configurations (add, remove, etc.). None of the options I can find will allow the new schema (xmlns:xdt=“http://schemas.microsoft.com/XML-Document-Transform”) and attributes to build locally. This is in VS 2015 Enterprise.
Hi @djansen,
I’ll answer this one on behalf of Mike as he’s currently away on leave.
I believe the transform he is referring to is the Additional Configuration Transforms feature in your Octopus deployment step, not in Visual Studio.
So the idea is that in your development machine where you are using and writing the app, you can just include your certificate information in the normal CloudService.cscfg file. This will be used when you are running and debugging locally.
The additional file CloudService.<MyEnvironment>.cscfg is what has all the transformations that need to take place and isn’t used in Visual Studio, but simply bundled up into your nupkg so that it can be used by Octopus.
At build time, when the package is extracted the variables in CloudService.<MyEnvironment>.cscfg are replaced with what you would expect given your MyEnvironment environment scoped variables, and then you also instruct Octopus to perform the Configuration transform logic with CloudService.<MyEnvironment>.cscfg=>CloudService.cscfg, in a similar manner to normal web.config transforms.
If that does not quite make sense perhaps have a read through the documentation links Mike included in his above post.
Let me know if you still require clarification on any of the specific steps outlined in this solution.
Cheers,
Rob
Thanks for getting back! I had a chat to one of our devs and we are unable to find a solution to what you want here. The only thing you can do is deploy, browse to the deployed location and check that the files are being transformed.