-
-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use commit SHA as additional version fallback #2664
Comments
Also please note there is an initative to have a default |
Also another thing we can do on 4.0: getsentry/sentry-javascript#9195 (comment) Lets have more fallbacks where we get the SHA from one of those env vars at compile time? We have something that at compile timer adds an That is, unless newest versions of .NET have the |
Oh @AbhiPrasad found it: |
Whatever people put in the AssemblyInformationalVersionAttribute can be obtained at run time from the Application.ProductVersion property.
Folks can add a SHA in the sentry-dotnet/src/Sentry/Reflection/AssemblyExtensions.cs Lines 32 to 36 in 3d8bb0a
I think we can close this ticket then? |
That's a .NET Framework API. Not available on .NET (Core)
He describes the parameter but you need to pass the actual value as an argument. The goal was for us to automate this (the same way that this does it for us: sentry-dotnet/src/Directory.Build.props Line 56 in 589ea4d
If they are using this lib ^ or another SourceLink library as such it would already be setting AssemblyInformationalVersionAttribute properly and we wouldn't need to do anything. For example, NuGet Trends has: https://github.com/dotnet/nuget-trends/blob/b4fbc342fec8159e01565a2dd8ae0e7362245338/src/Directory.Build.props#L20
so: AssemblyName@AssemblyVersion+GitSHA AssemblyVersion with 3 digits instead of the default 4, semver compatible. This is format is ideal. |
If we decide to change the release building logic, 4.0.0 is ideal time for "breaking" changes |
I'm not sure I follow. So if someone is not using something like I'm assuming it's not about setting this since In terms of reading it, we'd just need to pull this off the attribute that gets set. This code is a bit hacked together, but will do it: using System.Reflection;
// Get the assembly for the current executable
var assembly = Assembly.GetExecutingAssembly();
// Get the AssemblyInformationalVersionAttribute
var infoVersion = assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>();
// Extract just the informational version part
var privateBuildNumber = infoVersion?.InformationalVersion.Split('+')[1];
Console.WriteLine(privateBuildNumber); |
We would keep the value in a Sentry-specific "GitSha" attribute, so we could read it at runtime. That's only useful if they don't have set Release programatically. Nor have set AssemblyVersion (defaults to 1.0.0) so at least the commit sha differs. And if they don't use SourceLink.
It's not about hoping the user does something manually (like passing the value). It's about Sentry working OOTB with no user configuration required. We'll show commit sha in the version (appended after version number through
Something like that but wouldn't be |
I think if we used sometjhing like:
As they did in Node: minus some obvious stuff like VERCELL and instead whatever TeamCity, AppVayor, Azure DevOps and other popular .NET building tools this would be good enough |
Moved to 5.0.0 since we have too much in scope right now |
Ah I see... I was wondering where this could come from if the user wasn't supplying it. That makes sense 👍🏻 |
From the AssemblyInformationalVersionAttribute docs:
Build timeAt build time we create releases when uploading symbols etc. during builds. We resolve the release version from:
So I think we're covered at build time. RuntimeAt runtime we're currently getting the version from the InformationalVersion attribute and then fall back to the assembly version: sentry-dotnet/src/Sentry/Reflection/AssemblyExtensions.cs Lines 27 to 44 in 27ede88
We don't yet have any fallback to a commit hash, although as noted above, we get this for free in the Potential gapsIf people are building their .NET apps using the .NET SDK v7 or earlier and they haven't set any version information manually, currently the version information that gets sent in Sentry envelopes won't be very useful. We could potentially try to discover some kind of commit hash in these scenarios (e.g. using the technique Bruno described above). |
I'm adding this back to the 5.0 milestone. Either to have it closed or the gaps filled. |
sentry-dotnet/src/Sentry/Reflection/AssemblyExtensions.cs
Lines 44 to 48 in e75d537
The text was updated successfully, but these errors were encountered: