Visual Studio Windows Service app.config/Slow Cheetah

modelling

(bill.bassler) #1

I have been following the guidance for config file default naming for both Web and Windows service projects. https://octopus.com/docs/deployment-process/configuration-files\
We utilize Visual Studio and Slow Cheetah for Windows Services, so by default there is a built in dependency of .config to Visual Studio Build Configurations defined in the Configuration Manager. In the case of Windows Services, from what I can tell, the the naming convention required by Octopus is not supported well by this tooling. e.g. MyService.exe.Test.config is not created. app.Test.config is created based on a Visual Studio Configuration Manager Configuration along Slow Cheetah transforms nested under the app.config. The screenshot on the referenced doc implies a manual add of a config file named to support Octopus naming conventions may be required. i.e. not based on the Visual Studio standard approach of associating config file to Configuration and a root app.config. One approach that I have used before is to essentially override the default transforms conventions by defining “Additional Transforms” in the Configuration Transforms/Features sub step explicitly against the format of e.g. app.Test.config -> MyService.exe.config. Can I assume that this is the best approach for Visual Studio config behaviors? I typically have a Visual Studio Build solution configuration for Web projects anyway and so Add Transform for the Windows Service is already available.


(Kenneth Bates) #3

Hi Bill,

Thanks for getting in touch! You’re right on the money - defining additional transforms in that feature to overwrite the values exactly as you’ve mentioned is the best approach. This feature allows you to use any transform and config files that don’t match the standard naming conventions.

I hope this helps! Don’t hesitate to reach out if you have any further questions. :slight_smile:

Best regards,

Kenny