You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
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.
The text was updated successfully, but these errors were encountered: