Creating a release through Sentry in MSBuild results in incorrect release name

[huynhsontung]

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'.

[huynhsontung]

I suspect this is because of the single quote in the Exec task.

sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets

Line 336 in e25f0f7

Command="$(SentryCLIBaseCommand) releases new '$(_SentryRelease)' $(SentryReleaseOptions)"

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]

Thanks for raising this. Seems like you're right.

Is this something you could put up a PR to help fix?

[huynhsontung]

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]

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]

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.