Runtime: Could not load file or assembly 'System.Security.Cryptography.Algorithms/Primitives

[tofutim]

When calling encryption functions (such as Aes) from a .NET 4.6 test library, there are no problems. However, if the encryption calls happen inside of a netstandard13 which is then referenced by .NET 4.6 test library or .NET 4.6 console, I get:

Net 4.6 library calling netstandard13 function calling Aes (NUnit 3.6 in NCrunch)

System.BadImageFormatException : Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)
----> System.BadImageFormatException : Could not load file or assembly 'file:///C:\Userstim\AppData\Local\NCrunch6380\36_ncrunchreferences\System.Security.Cryptography.Algorithms.dll' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)
----> System.BadImageFormatException : Cannot load a reference assembly for execution.
at cryptPcl.fromPcl.Test()

Net 4.6 library calling netstandard13 function calling Aes (nunit3-console)

Errors, Failures and Warnings

1) Error : cryptTest.Class1.anotherTest
System.IO.FileNotFoundException : Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.0.
0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file speci
fied.
at cryptPcl.fromPcl.Test()
at cryptTest.Class1.anotherTest() in C:\Userstim\Documents\Visual Studio 2015\Projects\cryptTest\cryptTest\Class1.cs
:line 56

Net 4.6 Console app calling netstandard13 function calling Aes

An unhandled exception of type 'System.IO.FileNotFoundException' occurred in ConsoleApplication1.exe

Additional information: Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Interesting, direct calls to Aes from the same test project work just fine. Somehow the call from the netstandard13 doesn't know that the real non reference System.Security.Cryptography.Algorithms is already available.

---

Test project here: https://github.com/tofutim/cryptTest

---

Update. If I add the System.Security.Cryptography.Algorithms (which also brings in .Primitives), NCrunch successfully runs the test. However, both the nunit3-console and the Console app give a new but similar error:

An unhandled exception of type 'System.IO.FileLoadException' occurred in ConsoleApplication1.exe

Additional information: Could not load file or assembly 'System.Security.Cryptography.Primitives, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

When I try to add the System.Security.Cryptography.Primitives nuget (4.3), I cannot, as it is already installed. Help! I'm out of things to try. :(

---

Egads! I was able to get my .NET 4.6 console and .NET 4.6 test library to work by downgrading to 4.2.0 for System.Security.Cryptography.Algorithms and 4.0.0 for System.Security.Cryptography.Primitives. But it still does require the nuget packages even though the compiler seems to think otherwise.

(I tried adding 4.3.0 .Algorithms nuget to the netstandard13 lib, and updating the console to app to 4.3.0 but it still complained about not finding the 4.0.0 .Primitives lib)

[karelz]

cc: @ericstj if he has ideas ...

[ericstj]

It sounds like you are using packages.config in the NET46 project. In that case, as is always the case with packages.config, you must install all packages in referenced projects to the referencing project. If you're having issues adding the packages to the net46 project please share more specific details.

[tofutim]

Dear Eric,

There is something specifically wrong with 4.3.0. If I install .Algorithms
4.2.0 and .Primitives 4.0.0 I have no problems. This is whether I install
4.3 into my netstandard13 library or not. Please see github sample repo.

Thanks so much!

Respectfully,
Tim

On Sat, Jan 28, 2017 at 8:26 AM, Eric StJohn [e-mail]
wrote:

It sounds like you are using packages.config in the NET46 project. In that
case, as is always the case with packages.config, you must install all
packages in referenced projects to the referencing project. If you're
having issues adding the packages to the net46 project please share more
specific details.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/15570#issuecomment-275857766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJoRh72fD8kbEkkCSvnDDiTifvhyiboks5rW2wwgaJpZM4LwYBL
.

[tofutim]

Expected

Since both netstandard13 and .NET 4.6 have
System.Security.Cryptography.Algorithms, I expect to be able to

1. Write a function F in a netstandard13 library that calls Aes
2. Reference the netstandard13 library in a .NET 4.6 project
3. Call function F from .NET 4.6 project

Actual

In fact, the code compiles, but when you run the program it throws an
exception saying that .Algorithms 4.0.0 is missing.

Working workaround

Install .Algorithms 4.2.0 from nuget into .NET 4.6 project, which installs
.Primitives 4.0.0. Everything works.

Surprising non-working workaround

Install latest .Algorithms (4.3.0) from nuget into .NET 4.6 project, which
installs .Primitives 4.3.0. Compiles but when run, exception says that
.Primitives 4.0.0 is missing. Somehow it does not recognize .Primitives
4.3.0.

On Sat, Jan 28, 2017 at 10:20 AM, Tim Uy [e-mail] wrote:

Dear Eric,

There is something specifically wrong with 4.3.0. If I install .Algorithms
4.2.0 and .Primitives 4.0.0 I have no problems. This is whether I install
4.3 into my netstandard13 library or not. Please see github sample repo.

Thanks so much!

Respectfully,
Tim

On Sat, Jan 28, 2017 at 8:26 AM, Eric StJohn [e-mail]
wrote:

It sounds like you are using packages.config in the NET46 project. In
that case, as is always the case with packages.config, you must install all
packages in referenced projects to the referencing project. If you're
having issues adding the packages to the net46 project please share more
specific details.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/15570#issuecomment-275857766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJoRh72fD8kbEkkCSvnDDiTifvhyiboks5rW2wwgaJpZM4LwYBL
.

[mattman624]

I have this exact same issue. Glad to finally see it is not just me.

[karelz]

@ianhays can you please help?

[ianhays]

There is something specifically wrong with 4.3.0. If I install .Algorithms
4.2.0 and .Primitives 4.0.0 I have no problems. This is whether I install
4.3 into my netstandard13 library or not. Please see github sample repo.

This is because the 4.2.0 version of Algorithms depends on the 4.0.0 version of Primitives, whereas the 4.3 version of algorithms depends on the 4.3 version of primitives.

Did you install the 4.3 versions of Algorithms as well as Primitives to your net46 project that is using packages.config as @ericstj mentioned?

Can you confirm what the version of the Primitives dll being restored to your bin dir actually is?

I have this exact same issue. Glad to finally see it is not just me.

To be clear, your issue is specifically that when you use the 4.3.0 version of System.Security.Algorithms in a netstandard project referenced from a net46 project you get an exception message that the 4.0.0 version of Primitives is missing, correct?

[mattman624]

Yes, correct. And I cannot use the workaround because that causes another issue between different versions of System.Net.Http, because that library uses cryptography.

[ianhays]

Alright, lets see if we can figure out the problem then. Some thoughts/questions/ideas:

• Did you install the 4.3 versions of Algorithms as well as Primitives to your net46 project that is using packages.config as @ericstj mentioned?
• Can you confirm what the version of the Primitives dll being restored to your bin dir actually is?
• Can you link me your project.json and project.lock.json? It would be helpful to see where the 4.0.0 dependency is coming from.

[mattman624]

1. Yes I did, and I made a solution that has some tests in a net46 project that references a cryptographical class from a standard13 project. The net46 referenced 4.3 and it did not work, using the work around it then did work. I changed it back to 4.3 to answer question two.

2. using dotPeek I see: System.Security.Cryptography.Algorithms (4.0.0.0, msil, .Net Framework v4.0, Debug) and
   System.Security.Cryptography.Primitives (4.0.1.0, msil, .NetFramework v4.0, Debug)

3. project.zip

[ianhays]

Sorry, for the project.json could you share the one that uses 4.3.0?

[mattman624]

That is the project.json from the standard13 project. I do not see any project.json in my net46 project.
It is my understanding that NuGet installs all of the dependencies behind the scenes and project.json only contains the highest level dependencies

[mattman624]

project.zip

Here is the project.json from my actual project, not the demonstration project and it shows references to 4.3.0.

[ianhays]

To be clear, your issue is specifically that when you use the 4.3.0 version of System.Security.Algorithms in a netstandard project

Yes, correct.

But your project.lock.json shows the netstandard project using 4.2.0, not 4.3.0. That's where the old 4.0.0 dependency is coming from.

NuGet installs all of the dependencies behind the scenes and project.json only contains the highest level dependencies

That's mostly true, yeah. The actual resolved dependencies are in the project.lock.json file.

In the original post it's stated that both the netstandard and net46 projects are referencing the 4.3 version of Algorithms which raises the interesting question of where the 4.0.0 Primitives package is coming from. In your project.lock.json it's using 4.2 algo which requires 4.0.0 primitives which conflicts with the 4.3 import in your net46 project, yes? In that case you can make your net46 project use 4.2/4.0 to match the netstandard reqs and that's the workaround the OP mentions.

In theory you should be able to instead upgrade your netstandard Algo/Primitives versions to 4.3.0/4.3.0 and it's that scenario that I'm worried is broken by the OP. That's what I want the project.lock.json for.

[mattman624]

Yes, my first project.json was from my demo project. The second zipped file I uploaded is from my current project I am developing and it displays 4.3.0 for both of those dependencies.

The workaround works in the demo project, however in the main project it introduces many many other dependency problems.

I apologize for the mistake on my part.

Edit-----

I edited my third post so now both of those linked files are the proper ones.

[ianhays]

Thanks @mattman624, I got it reproduced.

The error might be that the dll being produced in the netstandard1.3 classlibrary project has the 4.0.0 versions of both Algorithms and Primitives in the manifest:

regardless of the version listed in the *deps file alongside the dll, the project.json, and the project.lock.json:

      "System.Security.Cryptography.Algorithms/4.3.0": {
        "dependencies": {
          "System.IO": "4.3.0",
          "System.Runtime": "4.3.0",
          "System.Security.Cryptography.Primitives": "4.3.0"
        }
      },

[mattman624]

@ianhays Is there a way to solve this issue?

[tofutim]

Hi, I need help resolving this issue. Is there any kind of workaround? Previously I downgraded to Cryptography 4.2 and 4.0, but with Net.Http, it really gets hosed. To replicate

1. Install System.Net.Http 4.3.0 into a netstandard13 lib, then ref from .NET 4.6 app
2. Try to use it

Could not load file or assembly 'System.Security.Cryptography.Primitives, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

If I downgrade Primitives to 4.0.0.0 it takes Algorithms to 4.2 and Net.Http to 4.1.1. However then I get

09:57:12.537 [Worker#STA_NP] ERROR TranslatorTests - Could not load file or assembly 'System.Net.Http, Version=4.1.1.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definitio
n does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I checked, and I actually have copy local set to true on System.Net.Http, and it copies over

But I think even though it comes from the 4.1.1 nuget, it is labeled internally as 4.1.0.1 instead of 4.1.1.0.

Maybe related somehow to this? https://github.com/dotnet/corefx/issues/9846

Update. I tried System.Net.Http 4.0.0 and 4.1.0 from nuget to no avail. I'm stuck.

1. If I upgrade everything to 4.3.0, I will get a complaint about Cryptography.Primitives wanting to be at 4.0.0
2. If I set Cryptography.Primitives to 4.0.0, it will bring System.Net.Http 4.3.0 to 4.1.1, which will bring up the error where the actual dll is 4.1.0.1 but 4.1.1.0 is called for. Help @ianhays

[tofutim]

I was able to make progress using binding redirects:

      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.Serialization.Xml" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.2.0" />
      </dependentAssembly>
    </assemblyBinding>

and adding System.XML 4.3. But it feels... sketchy.

Update. Works for targeting 4.6.1, with 4.6, the version number for Algorithms is 4.0.0.0 and the binding redirect can be removed. Not sure why this doesn't get installed with the nuget package. Maybe that is the oversight?

[karelz]

@ianhays can you please comment or route it?
@tofutim it would help me if you can summarize the problem into simple description ...

[cunnpole]

Having the same problem here for a 4.6.1 asp.net project trying to share a netstandard 1.3 dll (using the netstandard 1.6.1 nuget) with a pcl project. works fine from the pcl end, but i get runtime errors from the asp.net project when i try to call the code in the library:

Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

[tofutim]

@cunnpole @karelz I suspect the issue is that the netstandard13 dll is asking specifically for 4.0.0.0 (regardless of whatever is installed or declared by nuget/project.json). As a workaround, you need to add the binding redirect to the 4.6.1. project.

      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.1.0" />
      </dependentAssembly>

Note, that the "version" is the version you see in Properties when you go to the dependencies in the 4.6.1 project. It is not the nuget version. I ended up adding the 4.3.0 nuget libs and looking up the version number using .NET Reactor - but it is the same as the one in VS.

This could be resolved if adding the 'System.Security.Cryptography.Algorithms' 4.3.0 nuget automatically added a binding re-direct to dll version 4.1.0.0. But somehow even when auto-redirect is on, it does not pick up that detail.

[ianhays]

@weshaggard @ericstj @mellinoe I'm not too familiar with how the dll imports are determined and what role the manifest plays in the above issues, but having them fixed at 4.0.0.0 seems to be causing issues for several people looking to use them as netstandard libraries. Could be related to dotnet/runtime#17770 but not quite the same since crypto algorithms isn't an OOB like net.http.

[cunnpole]

The bindingredirect workaround solves the problem. @tofutim Thanks for the note about the versions, I did get in a bit of a muddle using the wrong numbers. An exact copy and paste of above worked perfectly.

[jairbubbles]

I have the same issues when using package Microsoft.CodeAnalysis.Csharp 2.0.0 which only targets .NET Standard 1.3. It has an indirect dependency to Crypto 4.0.3 through common package

The issue is in the NUnit tests, the application runs fine. I tried to add a binding redirect in the test assembly but the test won't launch at all.

[weshaggard]

@karelz @ianhays @ericstj this sounds more like a tooling limitation where the correct set of dependencies are not seen by ResolveAssemblyReferences task which is the one in charge of generating the auto-binding redirects. If it doesn't see the conflicts then it will not generate the binding redirects and thus you hit this runtime issue. I don't know enough about the feature and how everything flows to suggest a real fix but the workaround of manually creating the binding redirects as @tofutim (nice investigation by the way) is probably the best solution we have for this.

@karelz @ericstj We probably need to do some work on the auto-binding redirect feature should that request go to the sdk repo?

[ericstj]

That issue is already opened: https://github.com/Microsoft/msbuild/issues/1346.

[daveaglick]

I have the same issues when using package Microsoft.CodeAnalysis.Csharp 2.0.0 which only targets .NET Standard 1.3. It has an indirect dependency to Crypto 4.0.3 through common package

The issue is in the NUnit tests, the application runs fine. I tried to add a binding redirect in the test assembly but the test won't launch at all.

I am having this exact same set of symptoms. Updated Roslyn to 2.0.0 and everything works until I try and run unit tests from the NUnit console runner at which point I get:

Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Verified package versions are all lined up and binding redirects are in place for both .Algorithms and .Primitives. My project targets 4.6.2.

[jairbubbles]

@daveaglick I guess for now you just have to copy the binding redirects generated automatically for your application (look for the .config next to your output executable) and copy the content to app.config of your test assemblies.

I created an issue on Roslyn depot (https://github.com/dotnet/roslyn/issues/17778)

[petertiedemann]

I am also seeing this issue. In this case with a netstandard 1.4 assembly being used in a 4.6.1 nunit test assembly.

[danmosemsft]

@ericstj @bartonjs is there any work in corefx here? if not we should close -- we don't have tracking issues, too much noise in the repo.

[bartonjs]

@ericstj / @ianhays: Is there anything we can be doing here? It seems like a tooling problem (like the bug Eric opened for msbuild) and that the user action is to use binding redirects. If there's no action for us, we should just close the issue...

[ianhays]

Is there anything we can be doing here?

No, this can be closed. This is a tooling issue that we already have an issue for in msbuild linked above.

[oliverjanik]

Anyway anyone can put a high priority on that msbuild issue? There is zero response to that issue. Thanks.

[fasetto]

I have the same issue. ):

[JoseFMP]

+1, happening over here also, crappy

[spelltwister]

Installing 4.3 of algorithms into my 4.6.2 asp.net web app had the problem until I added binding redirects. I have a standard 1.3 lib that implements some hashing that the asp.net web app uses.

  <dependentAssembly>
    <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Security.Cryptography.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.0.2.0" />
  </dependentAssembly>

If I install 4.2.0 algorithms into my web app, the bin ends up having the 4.3.0 anyway even though I have copy local set to true for the 4.2.0 package that is installed. Only way I was able to see what was happening was using dotpeek to inspect the version number that ended up in my bin. 4.2.0 is 39KB on disk, 4.3.0 is 41KB on disk.

[tofutim]

How funny, it has been a year and I just now ran into exactly the same issue. Maybe 4.3.2 can be released that solves this issue?

Algorithms 4.3.1 goes back in time and the bindingRedirect version is now 4.0.0.0

Previously I used

  <dependentAssembly>
    <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
  </dependentAssembly>

for Algorithms 4.3.0. But now that we are at 4.3.1, I must use

  <dependentAssembly>
    <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

[Ben-Pattinson]

I can confirm that the Algorithms version has now mysteriously changed to 4.0.0.0, this is even though I have 4.3.0.0 referenced .... which is hilarious. Might I suggest that the pranksters responsible change the public key token next, everyone loved it when log4net did that!
The changes suggested by tofutim above work around the issue, but there's no way we should be battling this!

[tofutim]

Don't give them any ideas!

I wonder if this is related at all to Versions, AssemblyVersions and
FileVersions, and msbuild issues. I recently ran into this using
VS2017-style netstandard projects. If you 'msbuild /t:build /p:Version=...'
it changes the nuget package version but not the AssemblyVersion or
FileVersion. You have to 'msbuild /t:restore,build /p:Version' to get it to
actually change the AssemblyVersion and FileVersion before packaging.

On Tue, Jan 2, 2018 at 8:14 AM, Ben-Pattinson [e-mail]
wrote:

I can confirm that the Algorithms version has now mysteriously changed to
4.0.0.0, this is even though I have 4.3.0.0 referenced .... which is
hilarious. Might I suggest that the pranksters responsible change the
public key token next, everyone loved it when log4net did that!
The changes suggested by tofutim above work around the issue, but there's
no way we should be battling this!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/15570#issuecomment-354803274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJoRgNjSG18_S-HF_A6yt14myULN1Bzks5tGlYCgaJpZM4LwYBL
.

[Paul-Schroeder]

What worked for me seems to be:

1. Upgrading the Algorithms version to 4.3.1:
   NuGet package.config file:
   
   

2. Provide assembly binding redirects:
   <dependentAssembly> <assemblyIdentity name="System.Security.Cryptography.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.0.2.0" /> </dependentAssembly>
<dependentAssembly> <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" /> </dependentAssembly>