chore: Fix reference to Sentry.SourceGenerators

[jamescrosswell]

The current reference is very brittle:

• It assumes the Sentry.SourceGenerators project has already been built
• It assumes a release build
• It will break if the TFM ever changes or in a multi-targeting scenario

This breaks integration tests when these are run locally (since not all of the above assumptions hold up when running these locally).

#skip-changelog

[Flash0ver]

I have a feeling that this won't work as expected.
I don't think we are packing Sentry.SourceGenerators.dll to the expected PackagePath.

Unfortunately, the NuGetPackageExplorer is Windows-only.
So I can't test it right away.

We need either

• both items, where we use a proper $(OutputPath)-based path rather than hard-coding it
• or something with the TfmSpecificPackageFile-item in a target instead, because Sentry is multi-targeted, but Roslyn-Compiler-Extensions should be netstandard2.0

Also OutputItemType="Analyzer" seems wrong in this context as we don't want to consume the Generator in Sentry, but pack it in the same package alongside the Sentry lib/.

Let me get back to that when I'm on a Windows machine.

[jamescrosswell]

I think you're right... this would work if we only wanted to use the analyzer when building the SentrySDK:

• https://www.meziantou.net/referencing-an-analyzer-from-a-project.htm

But we want to package it and have it run when building projects that are using the Sentry SDK.

When I built a source generator myself, I simply put this in the csproj file for the analyzer itself:
https://github.com/mentaldesk/ducktype/blob/d06ab90bc698a30e33911b19901eb6833891eed9/MentalDesk.DuckType/MentalDesk.DuckType.csproj#L48-L52

Then other projects that wanted to use that source generator added a PackageReference to the analyzer.

If we published Sentry.SourcfeGenerators as a NuGet, would it be enough to add a package reference from Sentry to Sentry.SourceGenerators? Would that then ensure that anyone who added Sentry also got Sentry.SourceGenerators?

[Flash0ver]

Yes ... this should work ... this is what xunit does.
But ... I don't think we necessarily want this: Our SourceGen emits code that is depending on Sentry. The SourceGen does not make sense without Sentry. And also, I think it may be "dangerous" - to some degree" - to use different versions of the SourceGen-Package and the Sentry package.
I prefer to have the SourceGen within the Sentry package, similar to Microsoft.Extensions.Logging.Abstractions.

[Flash0ver]

change:

• ProjectReference to reliably build the project as a dependency in the correct order
  • with ReferenceOutputAssembly to include in $(OutputPath)
  • but with PrivateAssets="all" so that Sentry does not have a dependency on Sentry.SourceGenerators
• utilize TargetsForTfmSpecificContentInPackage
  • with a custom Target that packs Sentry.SourceGenerators in the expected PackagePath for Analyzer
    • via PackagePath="analyzers/dotnet/cs"

dotnet pack (Release) and check via NuGet Package Explorer on Windows:

No package dependency to Sentry.SourceGenerators

---

Does not reference the assembly Sentry.SourceGenerators

---

PackagePath="analyzers/dotnet/cs"

---

[Flash0ver]

Build fails on CI though ... need to reiterate 🤔

[Flash0ver]

From failing on all Platforms now only failing on macOS ... I'm getting there 😉

[jamescrosswell]

@Flash0ver it looks like you finally got this working. Since it's all your work, maybe you want to delete this PR and push up a new one (put your name on it)? I don't feel like I contributed much here (except the initial complaint).

btw: Can you now run the integration tests locally with this change? That was probably the main motivation for the fix.

[Flash0ver]

superseded by #4307