Make the variables in appsettings.json environment-swappable with Octopus.

Get started:

1. Go to Octopus' web UI.
2. Search at the "Projects" tab for your project.
3. Go to the "Process" tab at the left.
4. Drill into the "Update Web.Config Environment" option, assuming that is one of your steps. (If this step is greyed-out, click on the three dots in a vertical line at its upper right corner and pick "Enable" from the options there.)
5. Click "JSON Configuration Variables" herein.
6. Fill in line items for:
   • appsettings.Development.json
   • appsettings.Production.json
   • appsettings.Test.json
7. Go into Visual Studio 2019 Preview and copy what is in appsettings.json to...
   • appsettings.Development.json
   • appsettings.local.json
   • appsettings.Production.json
   • appsettings.Test.json
8. Back at the "Variables" tab beneath the "Process" tab at the left setup variables for .json file variables with breakouts for Development, Production, and Test named Development, Production, and Test. If you are like me and you cannot add a new variable with "Add Another Value" and "Add To List" then pick "Duplicate Variable" from the menu at comes out of clicking on the three dots in a vertical line at the upper right of any one variable. (This seems like an outright bug in Octopus!) Variable names need to match up with .json settings names. If you are going to drill down beyond the top tier seperate the name chunks in Octopus with colons as you might with dots in JavaScript.
9. Make all the variable slots in appsettings.json have empty values with open quotes immediately followed by closed quotes or something comparable and similarly put #{variable} in the same slots in appsettings.Development.json, appsettings.Production.json and appsettings.Test.json
10. Put #{variable} in your deployable files and #{variable} should not really just only say #{variable} put instead the variable part of #{variable} should be replaced with your specific variable name as denoted in Octopus.
11. Right-click on your UI project in Visual Studio 2019 Preview and pick Debug from the settings pane that appears with Application, Build, Build Events, Package, Debug, Signing, TypeScript Build, and Resources down the upper left edge. Herein there is probably one environment variable named ASPNETCORE_ENVIRONMENT and you should change it's value to "local" as "Development" no longer applies.
12. On the Angular frontend side, the head of a headless app, you will need to have a similar breakout for environment.ts. You will find a production configuration in angular.json and you should make development and test copies. You will want to make environment.development.ts and environment.test.ts to sit along with environment.ts and environment.production.ts too. At the "Update Web.Config Environment" step under CONFIGURE FEATURES, the "Substitute Variables in Files" setting will make the most of the #{variable} trick and you sort of have to use this with environment.ts stuff. However, for appsettings.json you may just check "JSON Configuration Variables" and this will try to match up a variable name in Octopus to a parameter in the JSON object in making replacements.

 
 

Things to try when it does not work:

1. In the "Update Web.Config Environment" Process option, click on "Inline Source Code" and look at the script being used to find the appsettings.json files at IIS. It will either be PowerShell, C#, Bash or F#. Maybe you have the wrong file path.
2. Whenever you want to experiment with a change herein in attempt to kick the build awake, instead of recommitting some code to increment the version number which will likely be required to have a successful build, you may click "Create Release" in Octopus above the left nav with Overview, Process, Variables, Channels, Releases, and Settings in it and then click Version to manually change the version number. I would recommend just bolting a letter onto the end of the current version number instead of incrementing the build number as you might when checking in code honestly. When you click "Save" here at the upper right there will be a button for "Deploy to Development" to take its place and on the other side of that a button that says "Deploy" to click before the build gets underway. Between "Deploy to Development" and "Deploy" you will have to cancel the last build if the last build was both created manually like this in this hacky way and also a failure.
3. Go to "Releases" at Overview, Process, Variables, Channels, Releases, and Settings to drill into the particular deployments and look at their errors. The errors should reveal the names of the servers being pushed to so that you my remote desktop in there and poke around some too.