Regression in changing the case of environment

[manuel-zulian]

Environment

How do you use Sentry? Sentry.AspNetCore

Which SDK and version?
3.9.4

Steps to Reproduce

There seems to be a regression for this issue: #999
In particular, I noticed this morning that I get the environment lower-cased even if I set the option "AdjustStandardEnvironmentNameCasing" to false.

It might be due to the changes in this file: https://github.com/ajbeaven/sentry-dotnet/blob/53323f0ea6b788a06aeb2cecf693fdf23e1b71a1/src/Sentry.AspNetCore/SentryAspNetCoreOptionsSetup.cs which seems to be different from the version that actually fixed the issue: https://github.com/getsentry/sentry-dotnet/pull/1057/files

EDIT My bad, there doesn't seem to be any change in the files above.

Expected Result

Environment not lowercased

Actual Result

Environment lowercased (from Staging to staging)

[lucas-zimerman]

Hi Manuel, thank you for opening the Issue.
It sounds like a bug, we will investigate it and give you better feedback soon :D

EDIT: I suppose that you are setting AdjustStandardEnvironmentNameCasing to false inside of UseSentryCallback? if so, as a workaround for now, could you try setting AdjustStandardEnvironmentNameCasing to false inside of AppSettings?

  "Sentry": {
    "AdjustStandardEnvironmentNameCasing": false
  }

Ideally, the problem will be solved in a future release.

[manuel-zulian]

I can confirm that setting the property in the appsettings file fixes the issue.

I am currently setting it in:

                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseSentry(o =>
                    {
                        o.AdjustStandardEnvironmentNameCasing = false;
                    });

                    webBuilder.UseStartup<Startup>();
                });

[lucas-zimerman]

Indeed, the property is being ignored once set inside of UseSentry, in the meantime, use the AppSettings option while a fix isn't released.

[bruno-garcia]

A simpler solution would be for Sentry not to care about environment casing: getsentry/sentry#6568

[bruno-garcia]

What if we make this property to internal? Does ASP.NET Core configuration binding still work?

sentry-dotnet/src/Sentry.AspNetCore/SentryAspNetCoreOptions.cs

Lines 46 to 54 in 2639611

	/// <summary>
	/// Controls whether the casing of the standard (Production, Development and Staging) environment name supplied by <see cref="Microsoft.AspNetCore.Hosting.IHostingEnvironment" />
	/// is adjusted when setting the Sentry environment. Defaults to true.
	/// </summary>
	/// <remarks>
	/// The default .NET Core environment names include Production, Development and Staging (note Pascal casing), whereas Sentry prefers
	/// to have its environment setting be all lower case.
	/// </remarks>
	public bool AdjustStandardEnvironmentNameCasing { get; set; } = true;

This way we remove the pitfall.

[bruno-garcia]

We can try the making it internal approach while documenting to use the framework configuration strategies (even a callback is possible through IOptions). Or any other breaking change.

[SimonCropp]

we could add a static SentryAspNetCoreOptions.DefaultEnvironmentNameCasing. then use that to derive true/false for AdjustStandardEnvironmentNameCasing on SentryAspNetCoreOptions construction

[SimonCropp]

on second thoughts. given the root fix is getsentry/sentry#6568. lets obsolete AdjustStandardEnvironmentNameCasing with a message to use app config. then we can burn it in the next major

[mattjohnsonpint]

I'm not a fan of obsoleting that. Not everyone uses app config files, and the problem is indicative of a larger issue.

The root cause appears to be that SentryAspNetCoreOptionsSetup is too early to be setting options based on other options. The environment name setup should be moved later, so that anything the user sets is still applied - whether it came from configuration or code.