Transforming *.config files (not web.config)

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.

Am I missing something in the Octopus setup?


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:

This link will show you how to create the transformation files:

This works for non-web.config files too!

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.

In case it helps anyone in the future the answer is to check the ‘XML variables’ option for the step, as discussed in this post:

That fixed non web config transforms for me.

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.

Hi Nick,

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:


Hi Paul,

Thank you for your response.

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.

Thank you,



Nicholas Brandon
Software Engineer, Digital Solutions
w 877.443.8264
[linkedin.gif]*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&trk=ncsrch_hits [facebook.gif] [twitter.gif]

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.

Hi Nicholas,

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:


Now you have this transform file:


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:


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.


Hi Paul,

Just came across this problem myself. It’s unintuitive to assume that app.*.config won’t transform.

Can you please add a note to the configuration transforms section (see attached image) and perhaps link back to this discussion?



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

umbracoSettings.Integration_WE.config => umbracoSettings.config

This I found finds the files inside the Config folder.

Hope this helps,


Hi Tim,

Thanks for sharing your solution! I am sure it will help others in the future :slight_smile: