search

XAMLMarkupExtensions / WPFLocalizeExtension

LocalizationExtension is a the easy way to localize any type of DependencyProperties or native Properties on DependencyObjects
Microsoft Public License
633 stars 130 forks source link

Problem with strong name in version 3.5.0 #225

Closed Karnah closed 4 years ago

Karnah commented 4 years ago

In some cases when call Assembly.GetTypes(), it throw exception:

Could not load file or assembly 'WPFLocalizeExtension, Version=3.5.0.0, Culture=neutral, PublicKeyToken=c726e0262981a1eb' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

I check new version with sn.exe:

Failed to verify assembly -- Strong name validation failed.

Old version have no strong name and all work fine:

.nuget\packages\wpflocalizeextension\3.3.1\lib\net452\WPFLocalizeExtension.dll does not represent a strongly named assembly

Karnah commented 4 years ago

We have this problem using xUnit. There is fix for it by disabling shadawCoping in settings. Documentation of it here: https://xunit.net/docs/configuration-files Now we are searching another cases where it can affect.

eriove commented 4 years ago

We have this problem using xUnit. There is fix for it by disabling shadawCoping in settings. Documentation of it here: https://xunit.net/docs/configuration-files Now we are searching another cases where it can affect.

Thanks for the solution, it worked for us as well. We have the same problem with xUnit when we target .NET 4.8, no problems targeting .NET Core 3.1 though. This makes sense since the appDomain feature is only supported in .NET Framework.

Haven't seen the same problem when actually running the application (executing the same code as the tests).

benjaminrupp commented 4 years ago

Hi,

we have the same problem with our click-once-project.

"strong name signature not valid for this assembly 'WPFLocalizeExtension.dll' "

Version 3.3.1 worked fine.

What is the reason for the change in the csproj-file?

Best regards

Benjamin

konne commented 4 years ago

@benjaminrupp We had still strong request for signed assemblies, and the issue as an OSS Project is that opening up the private key into the repo is not a good approach. MS introduced the public sign option to solve that issue. It seems that this is not working every case. Can this help: https://github.com/brutaldev/StrongNameSigner so that you just add an 

<Target Name="BeforeBuild">
  <Exec ContinueOnError="false"
        Command="&quot;..\packages\Brutal.Dev.StrongNameSigner.2.7.1\build\StrongNameSigner.Console.exe&quot; -in &quot;..\packages&quot;" />
</Target>