dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

ResolveComReference task should support PublicSign #4317

Open KirillOsenkov opened 5 years ago

KirillOsenkov commented 5 years ago

Currently ResolveComReference accepts KeyFile and DelaySign parameters: https://github.com/Microsoft/msbuild/blob/518c2fb4bd8621fe0d97e8a233f9ae9599d4b8d4/src/Tasks/Microsoft.Common.CurrentVersion.targets#L2734

However if a project specifies DelaySign=false and PublicSign=true then the project that has a ComReference such as:

  <ItemGroup>
    <COMReference Include="SHDocVw">
      <Guid>{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>1</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
      <EmbedInteropTypes>True</EmbedInteropTypes>
    </COMReference>
  </ItemGroup>

Fails the build with:

SHDocVw error MSB3299: The key file 'f:\agent\FinalPublicKey.snk' does not contain a public/private key pair.[f:\agent\Test.csproj]

because the .snk only contains the public key.

rainersigwald commented 5 years ago

I'd love to hear thoughts on this from @AaronRobinsonMSFT.

AaronRobinsonMSFT commented 5 years ago

@KirillOsenkov I am interested in the root problem here. Is this an issue purely because of the <EmbedInteropTypes>True</EmbedInteropTypes>? I don't fully understand how the signing of a project that references a COM library is impacted by that reference. Perhaps this is an issue with the generation of the PIA via tlbimp?

KirillOsenkov commented 5 years ago

Caveat: I don't know anything about ResolveComReference. Background: I was switching DelaySign to PublicSign on a large solution, and it is done in one shared location (Directory.Build.props). When I did that, the project that contained the COM reference started failing to build (the ResolveComReference task logged an error):

image

I have worked around it by switching that particular project back to DelaySign. However I've decided to file a bug just in case because it felt like switching to PublicSign shouldn't break that way.

Adding @nguerrera to see if he has any insights.

KirillOsenkov commented 3 years ago

Ran into this again. Every time I try to eliminate DelaySign from a solution (so it doesn't require StrongNameHijack on the machine to build it), and replace with PublicSign, if the solution uses ResolveComReference we hit this.