I seem to be having trouble transforming non-web.config files.
I have two different types. One is part of an Umbraco website. I have:
umbracoSettings.config
umbracoSettings.Staging.config
umbracoSettings.Release.config
How do I set Octopus to transform these? I currently have them all set up as full config files and use a PostDeploy powershell to rename the required and delete redundant per environment.
The other instance is a separate TaskRunner app that sits separate to the website. This project has the following config files:
App.Config
App.Staging.Config
App.Release.Config
This becomes Project.TaskRunner.exe.config after compilation.
I have tried renaming the configs to Project.TaskRunner.exe.[environment].config but this still doesn’t work.
Your Staging and Release config files should be transformation files instead of the full config. Check out this link and scroll down to the “Configuration File Transformations” section: http://octopusdeploy.com/documentation/features/xml-config
The problem (for non-web files) is that Octopus transforms the changes onto the App.Config file. This has no effect because the files are actually generated as [AssemblyName].exe.config. Octopus needs to look for the config file in this format.
I think Octopus needs functionality to find this file. It is available at build time as the property ‘AssemblyName’ in a default visual studio project file. Perhaps it could be recorded into the NuGet package somehow? Then when the package is unpacked at deploy time we still have a reference as to the proper name for the config file to transform.
You could also add a manual override AssemblyName variable, but the first option would be better as it would remain correct if the assembly name changed.
Has this issue been addressed in 2.0? I have a set of services that have app.config and requisite transforms. However, the transforms are not being applied when the app.config is automatically output as MyApp.exe.config.
Since your application configuration file is called “MyApp.exe.config”, you need to name the transformation file “MyApp.exe.YourEnvironment.config”. If you just call it App.YourEnvironment.config then we wouldn’t know which file to run it on.
The green tip section near the bottom of this page explains how to use this feature for application configuration files:
I understand that you are using a custom format for non web app configurations. I was hoping that there were provisions in place for the standard app.*.config format of .NET.
Are there any plans to support the config format as such?
Additionally, I noticed a feature regression in OD 2.0 on the deployment page where there are now switches instead of checkboxes when choosing what to deploy. Additionally, the ability to select all is now gone. That is a pretty crucial feature for the platform that I am using OD on as we have 70+ apps in our deployment, and would like the ability to choose a single app to deploy without clicking 75 switches.
This transmission may contain information that is privileged and confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
There’s nothing custom about this - in source control/Visual Studio, your file is called App.config. But when you compile the application, assuming your executable is named Foo.exe, your config file will be named Foo.exe.config.
Suppose your package has two executables both with configuration files:
Foo.exe
Foo.exe.config
Bar.exe
Bar.exe.config
Now you have this transform file:
App.Production.config
Should we run this transform file on Foo.exe.config, or Bar.exe.config? It wouldn’t be deterministic, so instead you need to name it:
Foo.exe.Production.config
This way Octopus can match the pair of files to transform:
Foo.exe.Production.config => Foo.exe.config
We don’t have plans to support App.*.config for this reason, because it’s not clear what the file should run on. But we do have plans to allow you to specify custom formats so that you can be explicit about the pairs you want to transform.
Thanks for the feedback on the select all feature for steps, we’ll add it back in an upcoming release.
Just had this problem myself and have solved it as follows:
Created a transform file that includes the same solution configuration names that are used in the web.config transforms
eg we have a configuration called Integration_WE in the Umbraco project solution and a web.Integration_WE.config transform so I added umbracoSettings.Integration_WE.config to the Config folder.
In the Umbraco project integration WE process additional transforms section in Octopus I added a new line
