[BUG] Prism.Container.Abstractions, Version=9.0.107.57918, Culture=neutral, PublicKeyToken=40ee6c3a2184dc59 Or one of its dependencies. Strong name verification failed

[weiwei11245]

Description

When I upgraded from Prism 8 to 9, this error occurred

An unprocessed exception of type 'System. IO. FileLoadException' is in an unknown module. Occurred in the middle
Failed to load file or assembly 'Prism. Container. Abstracts, Version=9.0.107.57918, Culture=neutral, PublicKeyToken=40ee6c3a2184dc59' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

Steps to Reproduce

What happens during program startup

Platform with bug

WPF

Affected platforms

Windows

Did you find any workaround?

No response

Relevant log output

No response

[volvo245r]

I have exactly the same issue,
Exception thrown: 'System.IO.FileLoadException' in PresentationFramework.dll
An unhandled exception of type 'System.IO.FileLoadException' occurred in PresentationFramework.dll
Could not load file or assembly 'Prism.Container.Abstractions, Version=9.0.107.57918, Culture=neutral, PublicKeyToken=40ee6c3a2184dc59' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

bin\Release>sn -v Prism.Container.Abstractions.dll

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

Prism.Container.Abstractions.dll is a delay-signed or test-signed assembly

[qtbui159]

same error

[dansiegel]

Yes we're aware of the issue though I'm not sure why this broke. We've been using the same logic to strong name the assemblies since the beginning of Prism.

[letscodewithkalyan]

@dansiegel
in release mode Similar error with the
Prism.DryIoc.Maui package with latest Version=9.0.537 In Android.

Error (10255) / AndroidRuntime: android.runtime.JavaProxyThrowable: [System.TypeLoadException]: Could not resolve type with token 01000061 from typeref (expected class 'System.ExceptionHelper' in assembly 'Prism.Container.Abstractions, Version=9.0.106.9543, Culture=neutral, PublicKeyToken=40ee6c3a2184dc59')

[tkcecek]

registry trick from https://stackoverflow.com/questions/403731/strong-name-validation-failed worked for me

[Mr-Cat-r]

As of today, this BUG still exists. I have no choice but to roll back to version 8.1.97, and then it can run normally. I have tried various methods. 【强名称验证失败】

[dansiegel]

Correct it still exists. And we're working on some back channels to fix this with Microsoft because there is no reason for this to have broken. We haven't changed anything.

[smsaleem]

Using ClickOnce, for .Net Framework 4.8, latest deployment of Prism works like a charm, however, when prism version 8.x is updated to version 9.x, this error is raised.

When a [signed] assembly is deployed using ClickOnce, its updates are also hash-checked by ClickOnce security with the previous updates. In its subsequent version if the assembly is signed with different certificate, although it compiles successfully, assembly signing error is raised by ClickOnce when updates are deployed on client machine.

Please check if it helps.

[AbraxasCSharp]

Same problem here, we have to downgrade to 8.1 too.

[nvonada]

We have two Prism exes building in the same solution. Once we updated to 9 one had this problem and the other did not. It turns out that while both had a platform target of "Any CPU" the one that failed had the "Prefer 32-bit" checkbox selected. I cleared that checkbox and the problem went away. YMMV!

Addendum: Once the apps built and ran (no detected problems BTW!) I ran unit tests. Three unit test assemblies also threw strong name errors, all were compiled x86. Switching to AnyCPU fixed them. Something 32/64 bit going on here?

[toumir]

I'm still encountering the error described in the issue, any additional advice or workarounds would be greatly appreciated

[dansiegel]

Unfortunately I haven't been able to resolve this with Microsoft yet so there isn't an update to give. All I can tell you is that the process we use for the strong naming hasn't changed in years so we're not sure why the tooling isn't doing what it's supposed to.

[Bodewes]

I've the same issue after updating from 8.1.97 to 9.0.537.

WPF application
Sdk="Microsoft.NET.Sdk"
TargetFramework=net472
Win11
VisualStudio 17.10.3

[nvonada]

We have two Prism exes building in the same solution. Once we updated to 9 one had this problem and the other did not. It turns out that while both had a platform target of "Any CPU" the one that failed had the "Prefer 32-bit" checkbox selected. I cleared that checkbox and the problem went away. YMMV!

Addendum: Once the apps built and ran (no detected problems BTW!) I ran unit tests. Three unit test assemblies also threw strong name errors, all were compiled x86. Switching to AnyCPU fixed them. Something 32/64 bit going on here?

OK, I thought I had this beat but my PR build is blowing up on Azure DevOps. 2/3 of my unit tests will not run on the build server due to this error. I am going to try a couple of things but I might be defeated here.

[brianlagunas]

Is everyone here reporting this issue using WPF?

What if we just removed strong name signing. Strong-names are left over from previous eras of .NET where needed to differentiate between code that was trusted, versus code that was untrusted.

Strong naming is about identity not security.

Thoughts?

[AbraxasCSharp]

Yes I'm reporting it for WPF. Removing the strong name signing would help a lot.
I can only support that Strong naming is about identity.

[smsaleem]

ClickOnce needs strong naming. Is there anyway to bypass it ?

[brianlagunas]

You can temporarily disable strong name validation for the delay-signed assembly using the sn.exe tool.

sn -Vr Prism.Container.Abstractions,40ee6c3a2184dc59

After disabling strong name validation, rebuild your project and run it again. This should bypass the strong name validation failure and allow the assembly to load properly.

[Bodewes]

You can temporarily disable strong name validation for the delay-signed assembly using the sn.exe tool.

sn -Vr Prism.Container.Abstractions,40ee6c3a2184dc59

After disabling strong name validation, rebuild your project and run it again. This should bypass the strong name validation failure and allow the assembly to load properly.

If I go this route, I have to do this on every PC runnning the WPF application? I don't think Corparate(tm) will like that.

[toumir]

Hi @brianlagunas,

Thanks for the tip on disabling strong name validation. Unfortunately, I'm still encountering the System.IO.FileLoadException even after turning it off.

The issue seems to be related to using the latest versions of the Prism packages:

Prism.Container.Abstractions (version: 9.0.107)
Prism.Container.DryIoc (version: 9.0.107)
Prism.Core (version: 9.0.537)
Prism.DryIoc (version: 9.0.537)
Prism.Events (version: 9.0.537)
Prism.Wpf (version: 9.0.537)
When running the application, we get a strange exception indicating a dependency on an older version (9.0.106.9543) of Prism.Container.Abstractions.

Here's the exact error message:

System.IO.FileLoadException: 'Could not load file or assembly 'Prism.Container.Abstractions, Version=9.0.106.9543, Culture=neutral, PublicKeyToken=40ee6c3a2184dc59' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'  

Any ideas on how to resolve this version mismatch?

[chk040399]

Maybe if we have access to the Source code for these packages (Prism.Container.Abstractions and Prism.Container.DryIoc), we can build unsigned versions of these assemblies, as the source repository for these assemblies is not available (https://github.com/PrismLibrary/Prism.Containers).

[dansiegel]

@chk040399 I can sympathize with your frustration. The reality is that we actually haven't changed anything about the way that we handle package signing and strong naming, and it wasn't until we finally released the GA that this was reported. This should highlight to the community the importance of using preview packages so that we can catch issues like this sooner.

Something in the build system has caused the problem and we are still looking into this. While I cannot tell you exactly when we will be able to resolve it, we are continuing to look into this.

[DevMercenary]

registry trick from https://stackoverflow.com/questions/403731/strong-name-validation-failed worked for me

So far it looks like a great solution.

Open the command prompt as administrator and enter following commands:

reg DELETE "HKLM\Software\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Microsoft\StrongName\Verification\*,*" /f
reg DELETE "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,*" /f