Sign assemblies and publish in build pipeline

Using .NET Core SDK 3.1.

We’re trying to publish our client application with strong-named assemblies, as a single-file application.

So we setup an Azure Build Pipeline with the following outline:

• dotnet build to produce output assemblies
• fetch certificate from Azure Keyvault
• use Set-AuthenticodeSignature to sign output assemblies with certificate (note: we could also re-sign a partially signed assembly using ‘sn.exe’, but the idea is the same)
• dotnet publish --no-build to produce a self-contained, single-file application

The --no-build is causing issues:

C:\Program Files\dotnet\sdk\3.1.200\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(154,5): error MSB3030: Could not copy the file “(…)MyApp\bin\Debug\netcoreapp3.1\win-x64\MyApp.deps.json” because it was not found. [MyApp.csproj]

If we omit the --no-build flag everything succeeds, but it also rebuilds a fresh dll which is not signed.

You might suggest that we should first publish, and then apply the strong-name signing on the published output. But since the publish step produces a single-file application, we must sign our assemblies before they are wrapped into that single-file container… so how is this supposed to work? And why is --no-build behaving so weirdly?

[dasMulli]

You could also trigger signing from within the build process itself.

E.g. create a file named Directory.Build.props in your project root directory (e.g. next to the .sln file) containing:

<Project>
  <PropertyGroup>
    <TargetsTriggeredByCompilation>$(SignIntermediateAssembly);SignIntermediateAssembly</TargetsTriggeredByCompilation>
  </PropertyGroup>

  <Target Name="SignIntermediateAssembly">
    <Exec Command="signtool.exe ... %(IntermediateAssembly.FullPath)" />
  </Target>

  <Target Name="SignPublishedSingleFileBundle" AfterTargets="BundlePublishDirectory">
    <Exec Command="signtool.exe ... $(PublishedSingleFilePath)" />
  </Target>
</Project>

[dasMulli]

The plural RuntimeIdentifiers in the cspros is mostly a no-op - it tells nuget to prepare assets for the RIDs (e.g. before we had implicit restore in 2.0+). It is not needed any more. And it does not affect any build or publish behaviour on its own. The singular RuntimeIdentifier is the same as passing -r to the CLI.

The assembly published will be the one in obj/[Configuration]/[TargetFramework]/[RuntimeIdentifier] for the project being published and in bin/… of the respective library folders.