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.
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? http://docs.octopusdeploy.com/display/OD/Configuration+files
If you already saw that document, please share us more info about your current setup like:
A screenshot of your package contents that shows where are your app.config and transform config files
A screenshot of how you configured the config transformations on your Nuget deploy step in Octopus.
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).
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.
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?
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):
[cid:image007.png@01D133F2.9EF3B910]
Unlike web projects, the do not get deployed (see nuget screen from Team City):
[cid:image008.png@01D133F2.9EF3B910]
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.
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.
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:
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.
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.
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.
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.
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
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 2.6.4.951
Is there a better way of determining that? CLI command?
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.