Octopus Deploy .NET 6 Core deployment failing web.config environment variable setting

[dtroutt]

Hi,
I’m having an issue deploying a .NET 6 Core Web API due to a web.config environment variable error.

The project seems to me to be straight forward, and I can run and debug it locally.

The web.config sets the ASPNETCORE_ENVIRONMENT variable…

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <remove name="aspNetCore"/>
            <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
        </handlers>
        <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
            <environmentVariables>
                <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
            </environmentVariables>
        </aspNetCore>
    </system.webServer>
</configuration>

The appsettings.json file defines a database connection string and some dummy access keys…

The error is in step 3 of the deployment

The process is like this…

Step 3 uses the web.config - Changes template…

I’ve tried a number of different things all to no avail. Any ideas anyone can provide would be greatly appreciated!

[jeremy.miller]

Hey @dtroutt,

Thanks for reaching out and welcome to the Octopus forums!

It’s looking like step 3 is failing due to $environmentVariables being null.

To simplify the Environment Variable Value parameter, I think we could just have a normal project variable there and then in the variables section of the project create that variable but with 2 scopes so that when DEV is running, the value is Development, and when PROD is running, the value is Production.

Here is an example of what I mean…

The Variables:

The Usage:

With this setup, depending on the environment that is currently being deployed to, it will pull the correct value.

Would you be able to give that a try and let me know if it works for you or if you have any questions?

Best,
Jeremy

[dtroutt]

Hi Jeremy,
Thank you for your reply.

So, do I understand that I should remove the ASPNETCORE_ENVIRONMENT from the web.config file and rely on the Octopus Deploy step you pointed out to set it? That is straight forward.

Here is what was being tried, but it didn’t make it this far as it failed on step…
“This step is based on a custom ASP.NET Core - set runtime environment variable via web.config - Changes step template.”

Corporate support had me remove all web.ENV.config files and only retain the web.config file. They are currently in the process of debugging. I don’t want to make any changes while they are in there, but once I get back in I will let you know how it goes.

[jeremy.miller]

You’re very welcome!

Do you mind if we take a step back for a minute? I’ve looked at your process again. Is there any reason you can’t do the substitution on that file with Structured Configuration Variables? Structured configuration variables - Octopus Deploy

You could potentially enable this and use this on your Step 2 and not need Step 3 at all. Can you please give that documentation a look and let me know if you think it will fulfill what you need out of Step 3?

You would still need to create the variable/values as I showed in my screenshot above to make that work, though.

Looking forward to hearing back what you think.

Best,
Jeremy

[dtroutt]

Hi Jeremy,
Our web.config file was slightly changed to this, adding ‘location’ tags…

The (now) step 4 web.config handling works as expected, there is no output so it is just empty, but green!

We removed any web.‘environment’.config files leaving only the one web.config file as well.

[jeremy.miller]

Awesome news! Are you in a good state now or is there anything else you needed a hand with on this one?

Best,
Jeremy

[dtroutt]

We are in a good state. Thanks for your help Jeremy!

[jeremy.miller]

Awesome!

You’re very welcome, thanks for letting me know.

We’re here if you run into any other snags in the future.

Best,
Jeremy