Microsoft-identity-web: [Bug] Reference Assembly does not have a strong name

[cloudsere]

Which version of Microsoft Identity Web are you using?
1.1.0

Where is the issue?
Referenced assembly 'Microsoft.Identity.Web.UI, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

• Web app
  
  
  
  • [x] Sign-in users
  
  
  • [ ] Sign-in users and call web APIs
  
  
• Web API
  
  
  
  • [ ] Protected web APIs (validating tokens)
  
  
  • [ ] Protected web APIs (validating scopes)
  
  
  • [ ] Protected web APIs call downstream web APIs
  
  
• Token cache serialization
  
  
  
  • [ ] In-memory caches
  
  
  • [ ] Session caches
  
  
  • [ ] Distributed caches
  
  
• Other (please describe)

Is this a new or an existing app?
This is a new app

Repro
Choose signing in solution properties

[jmprieur]

@cloudsere where did you get the assembly from?

Did you build it yourself?
You probably did not get it from Nuget.org?
Our process imposes that the DLLs be signed by the release build, and I double-checked they were (but we verify at each release)

[jmprieur]

Oh I see, sorry the strong name. I get it.
Microsoft.Identity.Web.UI does not have the <AssemblyOriginatorKeyFile>../../build/MSAL.snk</AssemblyOriginatorKeyFile> build property contrary to the other 3 assemblies

Thanks for the heads-up @cloudsere

[cloudsere]

Very happy to see this is fixed, you guys are great! Just wondering when the 1.2.0 version will be released, will there be any preview version~? @jmprieur

[jmprieur]

@cloudsere : we intend to release at the end of this week.
Do you have an urgent need?

[cloudsere]

I'm now working on the authentication part of my Web App, it is the basic of the whole app, so if there could be a preview version would be very helpful :) @jmprieur

[bgavrilMS]

@cloudsere - as a workaround you could disable strong name validation on your dev box:

sn.exe -Vr *
from a Developer Command Prompt for VS201* (probably with Admin rights).

Note that strong naming is not a security feature, doesn't protect against code tampering, and many .NET projects don't even bother anymore. Code signing is the security feature.

[jmprieur]

Or just sn.exe -Vr for the DLL?

[bgavrilMS]

Another workaround is to add a refrence to https://www.nuget.org/packages/StrongNamer/. We do this in unit tests, to overcome the fact that many .NET DLLs are not strong named.

[cloudsere]

Will try both methods, thanks you guys @bgavrilMS @jmprieur ! Looking forward to 1.2.0 this week :)

[jennyf19]

@cloudsere Included in 1.2.0 release.