Open KirillOsenkov opened 5 years ago
I'd love to hear thoughts on this from @AaronRobinsonMSFT.
@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
?
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):
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.
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.
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:
Fails the build with:
because the .snk only contains the public key.