Description
With SENTRY_DSN set, the first build of a fresh checkout fails in every sample that reads the DSN from the generated EnvironmentVariables class. Building again succeeds.
rm -f samples/EnvironmentVariables.g.cs
SENTRY_DSN=https://key@sentry.invalid/1 dotnet build samples/Sentry.Samples.AspNetCore.Serilog
# error CS0103: The name 'EnvironmentVariables' does not exist in the current context
SENTRY_DSN=https://key@sentry.invalid/1 dotnet build samples/Sentry.Samples.AspNetCore.Serilog
# Build succeeded
The affected samples are Android, Blazor WebAssembly, ASP.NET Core Serilog, iOS, Mac Catalyst and MAUI. A full dotnet build Sentry-CI-Build-macOS.slnf in a new worktree fails on all of them.
Cause
samples/Directory.Build.targets writes samples/EnvironmentVariables.g.cs in the GenerateSharedDsnConstant target (BeforeTargets="BeforeCompile"), but compiles it through a static item:
<Compile Include="$(MSBuildThisFileDirectory)EnvironmentVariables.g.cs" Condition="Exists('$(MSBuildThisFileDirectory)EnvironmentVariables.g.cs')" />MSBuild evaluates static items before any target runs, so the build that creates the file doesn't compile it. The file is gitignored, so this happens once in every new clone or worktree, and after every git clean -fdx. CI doesn't set SENTRY_DSN, so it isn't affected.
Suggested fix
Add the Compile item from inside GenerateSharedDsnConstant, so the build that writes the file also compiles it. Builds without SENTRY_DSN should behave as they do now.
Several sample projects write the same shared file during a parallel build, so the fix shouldn't introduce a race. For example, use WriteOnlyWhenDifferent="true", or write the file per project under $(IntermediateOutputPath).
A fix should mean that the first build after deleting samples/EnvironmentVariables.g.cs succeeds with SENTRY_DSN set.
In a worktree, building any sample also hits #5655. Pass -p:CI=true after building src/Sentry/Sentry.csproj once to avoid it.
Description
With
SENTRY_DSNset, the first build of a fresh checkout fails in every sample that reads the DSN from the generatedEnvironmentVariablesclass. Building again succeeds.The affected samples are Android, Blazor WebAssembly, ASP.NET Core Serilog, iOS, Mac Catalyst and MAUI. A full
dotnet build Sentry-CI-Build-macOS.slnfin a new worktree fails on all of them.Cause
samples/Directory.Build.targetswritessamples/EnvironmentVariables.g.csin theGenerateSharedDsnConstanttarget (BeforeTargets="BeforeCompile"), but compiles it through a static item:MSBuild evaluates static items before any target runs, so the build that creates the file doesn't compile it. The file is gitignored, so this happens once in every new clone or worktree, and after every
git clean -fdx. CI doesn't setSENTRY_DSN, so it isn't affected.Suggested fix
Add the
Compileitem from insideGenerateSharedDsnConstant, so the build that writes the file also compiles it. Builds withoutSENTRY_DSNshould behave as they do now.Several sample projects write the same shared file during a parallel build, so the fix shouldn't introduce a race. For example, use
WriteOnlyWhenDifferent="true", or write the file per project under$(IntermediateOutputPath).A fix should mean that the first build after deleting
samples/EnvironmentVariables.g.cssucceeds withSENTRY_DSNset.In a worktree, building any sample also hits #5655. Pass
-p:CI=trueafter buildingsrc/Sentry/Sentry.csprojonce to avoid it.