Source Generators not working

[jamescrosswell]

Description

As far as I can tell, the Sentry.SourceGenerators aren't working at all.

Steps to reproduce

1. dotnet new console -f net9.0
2. dotnet add package Sentry --version 5.11.2
3. Copy/paste the following into program.cs
4. dotnet run -c Debug

using Sentry.CompilerServices;

SentrySdk.Init();

string? buildConfig = null;
BuildProperties.Values?.TryGetValue("Configuration", out buildConfig);
if (buildConfig is null)
{
    Console.WriteLine("Source generators not working...");
}
else if (buildConfig == "Debug")
{
    Console.WriteLine("You're in Debug Mode");
}
else
{
    Console.WriteLine("You ain't in Debug Mode anymore Toto!");
}

Expected result

The application should output You're in Debug Mode.

Actual result

The application outputs Source generators not working...

[Flash0ver]

Great catch, @jamescrosswell!
In a chat, we figured out that

• the [Generator] is correctly loaded by the consuming project
• the [Generator] is even run
• but, the .props/.targets that we supply where missing <CompilerVisibleProperty Include="OutputType" />, which is needed to determine whether the consuming project is an Exe
  • this prevents the [Generator] from ever hitting GeneratorExecutionContext.AddSource
  • and therefore is never emitting any sources

[Flash0ver]

Will fix that by

• either adding <CompilerVisibleProperty Include="OutputType" /> to the packed Sentry.targets
• or utilizing Compilation.Options.OutputKind instead

Additionally, since MSBuild is case-insensitive, we should make the emitted Dictionary`2 also case-insensitive:

<PropertyGroup>
  <MyProperty>one</MyProperty>
  <MyProperty>$(myproperty);two</MyProperty>
  <myproperty>$(myproperty);three</myproperty>
</PropertyGroup>
<ItemGroup>
  <MyItem Include="first" />
  <myitem Include="second" />
  <MYITEM Include="third" />
</ItemGroup>
<Target Name="CustomAfterBuildTarget" AfterTargets="Build">
  <Message Text="MyProperty: $(mYpROPERTY)" Importance="high" />
  <Message Text="MyItem: @(mYiTEM)" Importance="high" />
</Target>

MyProperty: one;two;three
MyItem: first;second;third

---

Also - since the [Generator] effectively never emitted any sources - I'd like to take this unique opportunity to suggest some other changes of technically breaking nature ... but non-impacting since nothing was ever emitted to any user code so far:

• change the emitted types and members from public to internal
  • a [ModuleInitializer] must be accessible from the containing module
    • therefore it can be either public or internal
    • see https://learn.microsoft.com/dotnet/csharp/language-reference/proposals/csharp-9.0/module-initializers
• change namespace of emitted type
  • e.g. ASP.NET Core's RequestDelegateGenerator, used to enable MinimalAPIs for NativeAOT emits
    • namespace Microsoft.AspNetCore.Http.Generated;
  • so I suggest changing from Sentry to Sentry.Generated
• change the HintName of the Generated Source
  • e.g. .NET's RegexGenerator does not use any "_" in the name
    • I prefer {Namespace}.{TypeName}.g.cs
    • so Sentry.Generated.BuildVariableInitializer.g.cs
• change the emitted source from C# 10 to less than or equal to C# 9.0
  • the emitted source uses file-scoped namespace declaration, which require C# 10
  • the emitted code requires the ModuleInitializerAttribute which requires .NET 5
    • .NET 5 has the default language version of C# 9.0

[aritchie]

Sorry guys. That was my bad. It's why I like to soft launch as a nuget because targets does weird things or things are forgotten. Indeed, I missed bringing over OutputType in the compilervisible stuff. It was in the poc I did here (https://github.com/aritchie/BuildPropertyCapture/blob/main/BuildPropertyCapture/buildTransitive/BuildPropertyCapture.targets), but not in my sentry commit. I have never been able to find a way to unit test the execution properly e2e and with samples, you're forced to explicitly bring over the prop/targets. If you have problems with stuff again, please don't hesitate to ping me. I'm happy to fix my junk.

Also, I ended up expanding this technique https://github.com/shinyorg/reflector?tab=readme-ov-file#assembly-info-generation that could allow users to push their own build vars into Sentry metrics.

[Flash0ver]

Hey @aritchie, thanks for checking back!
No worries, one never gets it right the first time 😉.

To be fair, we're lacking test coverage for this scenario.
Well ... we do have AOT-related Integration Tests ... but they were passing because - so I believe - our Runtime-Fallback kicked in that evaluted NativeAOT correctly for OutputKind.ConsoleApplication. Once the Source-Generator actually did kick in, these Integration Tests were failing, since we evaluated <PublishTrimmed> and <PublishAot> unconditionally, regardless of whether the Application was actually published (and not just launched from source via dotnet run) ... see <_IsPublishing>.

Long story short ... lots of lessons learned when transferring build-time information to run-time.

Oh ... your Assembly Info Generation does look quite intriguing!
I actually had a similar idea the other day. Not about AssemblyInfo-related properties, but values that Roslyn evaluated through Microsoft.CodeAnalysis.ParseOptions and Microsoft.CodeAnalysis.CompilationOptions.

Anyway, thanks for the offer. We shall ping you when we can use a hand with Roslyn and SourceGen.