Console Applications

What options are available in terms of having transforms apply to Console applications?

As part of our deployment, we deploy a small Console application which takes care of scheduled notifications. Whilst Slow Cheetah works locally, Octopus does not apply the transformations.

This is a little problematic owing to the way Octopus uses a Promote To xxx workflow, which really makes the use of transformations a must.

Hi David,

Thanks for reaching out. Octopus should definitely be able to help you transforming your config files. Have you checked our “Configuration Transforms” section of our documentation?

If you already saw that document, please share us more info about your current setup like:


Yeah, I have read that stuff. But as you would (hopefully) know, Console applications are a different kettle of fish to Web applications.

We would prefer to use transforms if possible, rather than creating portal variables. I’m just not sure if Octopus supports that (I’m almost certain that is too much).

This guy came up with a hack -

But lets not gild the lily - it is a hack and a hack is a less than desirable way forward.

Please let me know what you come up with.


Hi David,

That hack was from 2013 before we had the “Additional transforms” field. Our documentation uses a web.*.config files as an example, but this will also work for regular console applications and their config files.

Try to define the name of the config files as shown in the Additional Configuration Transforms part of our documentation. If it doesn’t work, please send the info I requested on the 3 bullet points of my previous reply.


For console application transformations I think I had to do something like this:

App.#{Octopus.Environment.Name}.config => My.Executable.exe.config

This transforms App.QA.config to your executable filename.

If you console app name matches your package name you could replace that with #{Octopus.Action.Package.NuGetPackageId}

If you don’t do it like this then the App.config is the file that gets transformed, but that doesn’t then get renamed to your executable config file. Perhaps this is something Octopus could look at?

Hi Dalmiro,

The way this project is set up is that the transform files are tucked under the main App.config (I’m not sure what the proper term is for that):


Unlike web projects, the do not get deployed (see nuget screen from Team City):


I am guessing that we should manually create the transforms so they are not “tucked under” the main app.config and mark them as Content – “Copy if Newer”.

I’m going to get our dev to try that and will report back the results.







You can set them as Content/Copy if Newer event if they are grouped, and you will definitely need to do that as well, as the transformation happens after deployment on the tentacle, so they must be in the nuget package.

Thanks Sam. Will report back here and let you know how we go.


+1 to Sam’s comments

You need to set the config files as Content and Copy always. This is also explained in Octopack’s documentation:


OK. So the transform is still not being applied. I created an App.Setting called TestKey and the value had the name of the transform with Default being the App.config file itself.

When I checked the RACS.MALT.ScheduledTasks.exe.config file, the TestKey still had the value “Default”.

Attached to this Reply is the raw log file from the deployment.

This has become a point of pride, as the Contractor who is doing this for me keeps rubbishing Octopus, and thinks it can be done so much better. I utterly refute that and believe this can be done.

ServerTasks-24781.log.txt (43 KB)

You can see the transformation in your log file.

Line 446 shows App.Release.config transforming App.config.

Line 471 shows App.Staging.config transforming App.config.

As I pointed out above neither of these will update your exe.config file, as that does not match the standard pattern. You needs to add a custom transform rule:

 App.#{Octopus.Environment.Name}.config => RACS.MALT.ScheduledTasks.exe.config

Also note that App.Release.config gets run ALWAYS - so we use “Live” as our ‘release’ configuration name so it only gets run when we deploy the live version.

I don’t see anything with “TestKey” in - can you check it has the xdt:Transform attribute on it? Use SlowCheetah preview transform to check it is working correctly on your machine.

Whoops. Had a mistake in the Transform. But, still not quite there. Log attached.

Even though the Staging transform was applied after the Release, the value in the RACS.MALT.ScheduledTasks.exe.config was “Default”.

I also tried the custom rule in Sam’s reply, but the value is still ‘Default’.

The transforms look like this:

<add key="TestKey" value="Staging" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />

Any ideas as to why the AppSetting is not being transformed?

ServerTasks-24836.log.txt (45 KB)

You can now see that TestKey is being used, but still only to transform App.Staging.config to App.config, not to the custom rule above.

Not sure why that would be. I have exactly that transformation in my deployment (with my console app name) and it works fine.

An alternative is to rename your app..config files to RACS.MALT.ScheduledTasks.exe..config and include them in the content of your package.

Hi David,

Could you please follow these steps to provide us with a Deployment log that’s a bit more verbose? It should help us know a bit more of what’s going on in the background.

  1. Add these 2 variables to your project

  2. Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log.

  3. Send us the raw log of that deployment

Also if you could share the content of the following files, it would be useful for me to try to reproduce this

  • app.staging.config
  • app.release.config
  • RACS.MALT.ScheduledTasks.exe.config

If you don’t want the content of those files to be public, feel free to email them at


Hi Dalmiro, attached is a copy of the raw log and the 3 config files.


ServerTasks-24897.log.txt (204 KB)

App.Release.config (997 Bytes)

App.Staging.config (652 Bytes)

RACS.MALT.ScheduledTasks.exe.config (7 KB)

I just create a new process step myself today to do exactly the same thing and it works fine.

Below is the screenshot of my process step transform configuration.

Based on my reading of the log file you haven’t actually added the additional XML configuration transform I suggested (AdditionalXmlConfigurationTransforms element appears blank).

We are on 3.2.9 if that makes any difference to you. There was a bug with transform wildcards in 3.2.8 I think.

Hi David,

Like Sam said, the problem seems to be that your “Additional Transforms” are not being passed down to the deployment. If the transforms were being passed down properly, the variable would have a value on it instead of being empty

-[Octopus.Action[RACS.MALT.ScheduledTasks].Package.AdditionalXmlConfigurationTransforms] = ''

Once you added a value to the “additional transform” field, did you create a new release or just redeployed a new one? You need to create a brand new release for the changes on your deployment process to take effect. Could you please send us a screenshot of the field like Sam did on Octopus_config_transform.jpg?

Also please confirm your exact version of the Octopus Server.


I tried a new deployment this morning. It had not previously been deployed to the Staging environment. The log is attached. I think the relevant stuff is around line 2152.

I also attach a screenshot of the config.

Based on the small print in the left hand corner of the web interface, it looks like we are using version

Is there a better way of determining that? CLI command?

Also, is upgrading a big deal?


ServerTasks-24928.log.txt (206 KB)

Hi David,

Small print on the left hand corner is the best way yeah.

Unfortunately I can’t figure out why the deployment is not picking up your additional transforms. Version 2.6.4 is now a year old and we fixed plenty of bugs related to config transforms since then. At this point the only thing I can recommend if for you to upgrade to the latest version where I can confirm this is working as expected.

Here’s our documentation for the upgrade: . Feel free to ask any questions about the process.