Netstandard1.3 DLL from the latest nuget is not correctly SNK signed

Platform

What platform is your issue or question related to? (Delete other platforms).

• .NET HTML
• .NET WPF
• UWP

Author or host

Host

Version of SDK

Nuget 1.2.1

Issue

I spent all day today struggling with an issue when loading the AdaptiveCards netstandard1.3 library into my project (indirectly, via a bunch of complicated Assembly.Load() / AppDomain stuff that is only semi-relevant). Every time, my program would fail at startup with the exception:

FileLoadException: Could not load file or assembly 'AdaptiveCards, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

After much frustration I discovered that the netstandard1.3 dll was different from the other two in terms of strong name signing, in that it was only delay-signed but not “fully” validated. This is what was causing my runtime to fail to load them. Validating them manually with Sn.exe shows this:

C:\WINDOWS\system32>Sn -v "C:\Users\lostromb\Desktop\adaptivecards\net452\AdaptiveCards.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\Users\lostromb\Desktop\adaptivecards\net452\AdaptiveCards.dll' is valid

C:\WINDOWS\system32>Sn -v "C:\Users\lostromb\Desktop\adaptivecards\netstandard2.0\AdaptiveCards.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\Users\lostromb\Desktop\adaptivecards\netstandard2.0\AdaptiveCards.dll' is valid

C:\WINDOWS\system32>Sn -v "C:\Users\lostromb\Desktop\adaptivecards\netstandard1.3\AdaptiveCards.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

C:\Users\lostromb\Desktop\adaptivecards\netstandard1.3\AdaptiveCards.dll is a delay-signed or test-signed assembly

Of course one option is to upgrade my project to one of the other runtimes, but my project is plugin-based and I’m trying to maintain the broadest level of compatability which is why I’d prefer to target the lower version. Would it be possible to fix this simple issue in the next release?

[paulcam206]

just a heads up – this fix should be shipping in 1.2.2 either today or Monday 😃

[shalinijoshi19]

@paulcam206 does this mean we’ll need to issue a patch to fix the signing for 1.2.1 binaries? Now that we have the new certs as well, let’s target sometime today to republish?