Repository navigation
Creating a release through Sentry in MSBuild results in incorrect release name #4005
Description
Package
Sentry
.NET Flavor
Other
.NET Version
UWP
OS
Windows
SDK Version
5.1.1
Self-Hosted Sentry Version
25.1.0
Steps to Reproduce
Build an application with MSBuild with SENTRY_RELEASE=screenbox@0.15.0 and -p:SentryCreateRelease=true. I build and release my app in GitHub Actions. The full step can be found here: https://github.com/huynhsontung/Screenbox/blob/3b1d40519a1215d63cc97d3fa7ac0b8ea8ca449a/.github/workflows/main.yml#L75
Expected Result
For the package name and version to not have extra quotes. In my case package should be screenbox and version should be 0.15.0
Actual Result
The new version has a single quote ' suffix, and the package name has a single quote ' prefix. Package is 'screenbox and version is 0.15.0'.
Activity
huynhsontung commentedon Feb 27, 2025
I suspect this is because of the single quote in the
Exectask.sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets
Line 336 in e25f0f7
From the msbuild docs, exec relies on Command Prompt to invoke the command. Command prompt doesn't remove quotes from variables by default. Maybe it's related?
bruno-garcia commentedon Feb 27, 2025
Thanks for raising this. Seems like you're right.
Is this something you could put up a PR to help fix?
huynhsontung commentedon Feb 28, 2025
Absolutely! After looking at how Command Prompt deals with quotes, I think the easiest solution is to just remove the quotes in question. A release name shouldn't have spaces or special characters anyway. Do you have any concerns with this approach?
bruno-garcia commentedon Feb 28, 2025
thanks! no concerns. I mean it's a good point that we should check if all valid characters defined in release (https://docs.sentry.io/cli/releases/ ) will work in linux mac and windows when running the cli via msbuild. But we have CI already set up in all of these OSs so should be OK.
We had tests for symbol upload I think so we could check if the right release string is sent, in our "fake server".
@vaind do we have that stuff set up on this repo? any pointers if so?
vaind commentedon Feb 28, 2025
We do have a set of Pester-based integration tests: https://github.com/getsentry/sentry-dotnet/tree/main/integration-test
They import a common sentry-CLI integration-test module from https://github.com/getsentry/github-workflows/tree/main/sentry-cli/integration-test but the server there currently doesn't do anything for releases: https://github.com/getsentry/github-workflows/blob/main/sentry-cli/integration-test/sentry-server.py#L79 because it was originally aimed at verifying we upload debug symbols correctly, nothing else. It's possible to extend tests to verify this too - whether it's worth it in this case (i.e. the chance of this regressing is high enough), I don't know.