Thanks for this repo, very handy.

I like the idea of putting the Microsoft.SourceLink.GitHub PackageReference in one central place (the Directory.Build.props) however Visual Studio IDE then shows an ugly warning.

I'm running VS 16.9.0 Preview 1.0, any idea how to get rid of the warning... or is this just affecting me?

Hi Claire,

Why can't you combine Directory.Build.targets into Directory.Build.props? There are no targets in the Directory.Build.targets folder? Is there some subtlety here I am missing with how MSBuild works?

I have a reproduction of this issue with a vanilla .NET 5.0 Razor Class Library, created from the CLI template and using the latest version of the .NET 5 CLI.

It has SourceLink added to the project.

It is embedding the PDBs because I use Azure DevOps Artifacts which doesn't support .snupkg

https://github.com/seangwright/razor-class-lib-deterministic-build

• Clone the repo
• Run the commands in the README
  • dotnet build /p:ContinuousIntegrationBuild=true -c Release
  • dotnet pack --no-restore -o ./temp --no-build -c Release

Here's what NuGet Package Explorer tells me:

I'm not sure how to get a RCL to meet any of the criteria for a 'healthy' package. Is it even possible?

I already asked this question on dotnet/sdk#10614 (comment) but did not get a response yet, so I'm trying here since it looks like a good place with Claire being very knowledgeable about deterministic builds.

Let's describe the problem with a concrete example. Here's how I'm packing https://github.com/0xced/DockerRunner, commit d6d8917e7f208dbaacd9dd6ff25a439031d5dfd1 (current master branch as of writing):

dotnet --version
3.1.300
dotnet pack -c Release /p:ContinuousIntegrationBuild=true
  Successfully created package '[...]DockerRunner\src\bin\Release\DockerRunner.0.9.0-alpha.0.21.nupkg'.

When I open the resulting DockerRunner.0.9.0-alpha.0.21.nupkg in NuGet Package Explorer, Source Link and Deterministic health items have a warning sign with this tooltip:

Contains untracked sources:
To Fix:
<EmbedUntrackedSources>true</EmbedUntrackedSources>

Also, use 3.1.300 SDK to build or
workaround in: dotnet/sourcelink#572
Assembly: lib\netstandard2.0\DockerRunner.dll
/_/src/obj/Release/netstandard2.0/.NETStandard,Version=v2.0.AssemblyAttributes.cs
/_/src/obj/Release/netstandard2.0/DockerRunner.AssemblyInfo.cs

Now, let's add the workaround described on dotnet/sourcelink#572 in DockerRunner.csproj:

<PropertyGroup>
  <TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>
<ItemGroup>
  <EmbeddedFiles Include="$(GeneratedAssemblyInfoFile)" />
</ItemGroup>

Then I try to pack again with dotnet pack -c Release /p:ContinuousIntegrationBuild=true and with this workaround, NuGet Package Explorer reports that Source Link and Determinisc are valid with a checkmark icon.

To me, it seems that the .NET Core SDK 3.1.300 does not actually solve the untracked sources issue. Am I missing something? (Note that I have <EmbedUntrackedSources> set to true in the csproj)

Move this to the templates command

e.g. dotnet net -i deterministic

https://github.com/dotnet/templating/wiki/Available-templates-for-dotnet-new

https://github.com/kzu/til/blob/master/msbuild/detect-ci-builds-for-every-ci-system.md

This is an awesome effort!

Would also be nice to add the next step demo: have two projects, one referencing the other, and have them set ProduceReferenceAssembly.

This way the referencing project will actually get the .dll from ref folder, which strips method bodies and is a reference assembly. This way you can make a whitespace change, or a method-body change or private API change in the first project, and the second project will not rebuild.