Release version not being read from assembly and defaulting to 1.0.0

[carlin-q-scott]

Environment

How do you use Sentry? Sentry SaaS

Which SDK and version?

• Sentry.AspNetCore 3.13.0
• Microsoft.AspNetCore 5.0.0
• .NET 5.0

Steps to Reproduce

1. Set my Website AssemblyVersion and AssemblyFileVersion in my .csproj file
2. Ran my project in Debug mode from Visual Studio
3. Triggered a Sentry Event

Expected Result

I expected my release version to be set to either of the versions I set in my csproj.

Actual Result

My release version is 1.0.0. The Assembly name is correct.

[carlin-q-scott]

This is how I get my version at runtime for health check API:

• AssemblyVersion: System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString()
• AssemblyFileVersion: System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location).FileVersion.ToString()

I noticed that this is not how sentry-dotnet does it. For one thing, you're using the EntryAssembly rather than the ExecutingAssembly. Is that because the executing assembly would be Sentry.DotNetCore?

[bruno-garcia]

I believe this changed recently. Might have been a regression

[SimonCropp]

while we look into this. a workaround is to set SentryOptions.Release to a custom value.

[mattjohnsonpint]

It would appear this behavior changed in #1079, release with 3.6.0. A code comment was added at that time:

// Note: even though the informational version could be "invalid" (e.g. string.Empty), it should
// be used for versioning and the software should not fallback to the assembly version string.
// See https://github.com/getsentry/sentry-dotnet/pull/1079#issuecomment-866992216

Then during a refactoring in #1083, another code comment was added:

// TODO: Lets change this in a new major to return the Version as fallback

However, in the docs we still say this:

The SDK will first look at the entry assembly's AssemblyInformationalVersionAttribute, which accepts a string as value and is often used to set a GIT commit hash.

If that returns null, it'll look at the default AssemblyVersionAttribute which accepts the numeric version number.

SO - we made a breaking behavioral change and are documenting the old behavior. I propose we restore the behavior that is documented.

It might also be worth documenting that a <Version> tag in a .csproj will also work. While that's primarily for nuget package versions, it also sets the AssemblyInformationalVersionAttribute. (And also, the SENTRY_RELEASE environment variable will override all of the above.)

[bruno-garcia]

Thanks @mattjohnsonpint for the thorough detective investigation here. I believe your conclusion makes sense. There's low risk in changing this since it doesn't affect grouping or alerting or anything.

[mattjohnsonpint]

Ok, first - I would like to apologize because I was wrong. I totally misinterpreted those comments and how they relate to the code. It turns out we actually didn't make any breaking change. The current Sentry code only reflects that an empty string ("") on AssemblyInformationalVersion will still be passed along. It will still fallback to the AssemblyVersion if AssemblyInformationalVersion is not provided.

What's actually going on here is that there is an AssemblyInformationalVersion attribute on the assembly. Even if you don't specify one, it gets created by default whenever you use a project with the new .NET SDK csproj style. It's part of <Project Sdk="Microsoft.NET.Sdk">, and controlled by <GenerateAssemblyInfo> (see docs) - or more specifically, <GenerateAssemblyInformationalVersionAttribute>. The default value is set by <Version>, which itself defaults to "1.0.0.0". This is all just part of the new .NET project system.

SO - if you want to pick up a version number from an AssemblyVersion in Sentry, you'll have to disable auto-generating an AssemblyInformationalVersion in your csproj. For example:

<PropertyGroup>
    <AssemblyVersion>1.2.3.4</AssemblyVersion>
    <GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
</PropertyGroup>

Though, IMHO - by the time you are modifying your csproj - you might as well just set the <Version> directly instead.

<PropertyGroup>
    <Version>1.2.3.4</Version>
</PropertyGroup>

You could also turn off generation completely, and set your own attributes somewhere in C# code, like the older project style would do in AssemblyInfo.cs.

<PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

[assembly:AssemblyVersion("1.2.3.4")]

Since there's no ability for us to distinguish who created the AssemblyInformationalVersion, I believe the Sentry SDK is doing the best it can do already and shouldn't be changed in this regard. Instead, we should update the documentation to clarify how this behavior differs between the old and new csproj styles - at least with respect to where Sentry will automatically pick up version numbers from.