0

Microsoft (R) Visual C# Interactive Compiler version 2.9.0.63208

Windows 7 64 bit

NBitcoin 4.1.1.68

====

System.Security.Cryptography.Algorithms version 4.3.0.0 has an SHA256Managed class that I want to use in C# Interactive (csi.exe).

I added that assembly to the GAC with the gacutil -i [path_to_dll] command. I launched csi with an /r:[path_to_dll_dir]/System.Security.Cryptography.Algorithms.dll command line option.

On top of that, after csi started, I also did an #r "[path_to_dll]" reference. Belt and suspenders type stuff. I know. But I guess I was hoping the overkill would force it to do the right thing.

My application uses a class from a third-party library. The following code was copied pretty much verbatim from the third-party method my app calls. If I run the following code in csi, it works fine...

using System;
using System.Security.Cryptography;

byte[] b = Guid.NewGuid().ToByteArray();

var sha = new SHA256Managed(); 

byte[] c = sha.ComputeHash(b, 0, 15);

Now, here's the thing. That third-party class defines a method that calls SHA256Managed.ComputeHash(byte[], int, int) exactly like the code above.

For the sake of discussion, let's refer to the third party class and method as Foo.m().

The problem is, when I call the third party Foo.m() from csi, csi balks with...

Could not load type 'System.Security.Cryptography.SHA256Managed' from assembly 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
  + Third.Party.Foo.m(byte[], int, int)

Remember I explicitly added the version 4.3.0.0 crypto algorithm assembly into the GAC. Plus I explictly referenced the dll with both #r and /r:. So what gives?

I can see in the FusLogVw binding logs that csi is loading the version 4.0.0.0 assembly; in spite of me explicitly insisting on using version 4.3.0.0. System.Security.Cryptography.Algorithms version 4.0.0.0 does not have an SHA256Managed class.

Please help me figure out how to make csi use the assembly I tell it to use? Bear in mind, that it uses the right version for code written directly in csi. So why is it not using the correct assembly version for the exact same code in a third-party library?

deduper
  • 1,944
  • 9
  • 22
  • What version of assembly referenced by library? – user4003407 Nov 11 '18 at 23:57
  • Version 4.3.0, @PetSerAl—as far as I can tell by traversing the link I provided above: [_a third-party library_](https://www.nuget.org/packages/NBitcoin) -> [_System.Net.Http -Version 4.3.3_](https://www.nuget.org/packages/System.Net.Http/4.3.3) -> [_System.Security.Cryptography.X509Certificates -Version 4.3.0_](https://www.nuget.org/packages/System.Security.Cryptography.X509Certificates/4.3.0) -> [_System.Security.Cryptography.Algorithms -Version 4.3.0_](https://www.nuget.org/packages/System.Security.Cryptography.Algorithms/4.3.0) – deduper Nov 12 '18 at 00:14
  • ... Also, calling the third-party library in VS 2017's C# Interactive window works as expected. And I have confirmed that that one uses v4.3.0.0 of the assembly. – deduper Nov 12 '18 at 00:18
  • Are you sure that you are referencing .NET Framework version of `NBitcoin` assembly and not .NET Core one? – user4003407 Nov 12 '18 at 00:24
  • No actually, @PetSerAl. I am not 100% sure. I'm new to .NET. Too new to know what the difference between the two are, I'm afraid. So I only assumed _`csi`_ was using .NET framework. What steps do I take to determine for sure which one is being referenced? – deduper Nov 12 '18 at 00:29
  • How you specify `NBitcoin` assembly location to `csi`? Suppose you download `.nupkg` file. Rename it to `.zip`, and unpack `lib` directory. It should have multiple subdirectories. Use `net461` or `netstandard2.0` but not `netcoreapp2.1`. – user4003407 Nov 12 '18 at 00:43
  • _`/r:[path_to_vs_2017_project_dir]\bin\Release\net461\NBitcoin.dll`_. Again, I have confirmed that my app/code works with NBitcoin, because I setup, built and ran it in VS 2017 and in VS 2017's C# Interactive window. So, I'm remembering now that I configured my project to target .NET Framework 4.6.1. _`Shift F6`_ puts all the NBitcoin dependencies (_dlls_) in the _`bin\Release`_ dir of the project. I point _`csi`_ at those same dlls. I will try your _`nupkg`_ suggestion in a moment. But I'm reasonably sure nuget already downloaded a bunch of net461 stuff. But I will check and get back to you. – deduper Nov 12 '18 at 00:53
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/183468/discussion-between-deduper-and-petseral). – deduper Nov 12 '18 at 01:06

1 Answers1

0

TL;DR: The csi newb that I am, after installing the third-party lib for the first time two days ago, I copied its dll plus all its dependencies into a subdirectory of csi's bin directory to get csi to find and load it.

Long Answer: After bouncing some ideas off of the knowledgeable and helpful C# expert @PetSerAl, I eventually figured out what the answer to my original question was.

A FusLogVw Assembly Binding Log Entry that I encountered very soon after installing the third-party lib, lead to me putting the third-party dll into a sub directory of csi's bin dir. That appears to have inadvertently thwarted csi's assembly lookup mechanism from doing a complete probe of all the locations it should have looked for assemblies. As a result, csi was finding and referencing its own preinstalled older version of System.Security.Cryptography.Algorithms which is distributed with csi as part of the original VS 2017 installation.

Consequently, that made csi ignore both the subsequent /r: and #r references to the Algorithm dll that I was passing it. So it wasn't finding the non-existent SHA256Managed type in its own, older 4.0.0.0 version of the assembly it had in its bin dir. That's what caused the assembly binder error reported in the original post.

Removing the third-party assembly and co from csi's bin subdir did the trick. From there, getting csi to work correctly with the third-party library was just a matter of launching csi with the right assembly references...

C:\>csi /u:NBitcoin /u:NBitcoin.Crypto /u:System.Security.Cryptography /lib:[my_vs_2017_project_dir]\bin\Release\net461;[my_vs_2017_home_dir]\2017\Community\MSBuild\15.0\bin\Roslyn\ /r:System.Data.dll /r:System.Drawing.dll /r:System.IO.Compression.FileSystem.dll /r:System.Numerics.dll /r:System.Runtime.Serialization.dll /r:System.Xml.dll /r:System.Xml.Linq.dll /r:Microsoft.Extensions.Logging.Abstractions.dll /r:[my_vs_2017_project_dir]\bin\Release\net461\Microsoft.Extensions.Logging.Abstractions.dll /r:[my_vs_2017_project_dir]\bin\Release\net461\Newtonsoft.Json.dll /r:[my_vs_2017_project_dir]\bin\Release\net461\System.Buffers.dll /r:[my_nuget_repo_pkgs_dir]\system.net.http\4.3.4\lib\net46\System.Net.Http.dll /r:[my_vs_2017_project_dir]\bin\Release\net461\System.Net.Requests.dll /r:[my_nuget_repo_pkgs_dir]\nbitcoin\4.1.1.68\lib\net461\NBitcoin.dll /r:[my_nuget_repo_pkgs_dir]\system.security.cryptography.algorithms\4.3.0\lib\net461\System.Security.Cryptography.Algorithms.dll /r:[my_nuget_repo_pkgs_dir]\system.security.cryptography.csp\4.3.0\lib\net46\System.Security.Cryptography.Csp.dll /r:[my_nuget_repo_pkgs_dir]\system.security.cryptography.encoding\4.3.0\lib\net46\System.Security.Cryptography.Encoding.dll /r:[my_nuget_repo_pkgs_dir]\system.security.cryptography.primitives\4.3.0\lib\net46\System.Security.Cryptography.Primitives.dll /r:[my_nuget_repo_pkgs_dir]\system.security.cryptography.x509certificates\4.3.0\lib\net461\System.Security.Cryptography.X509Certificates.dll 
Microsoft (R) Visual C# Interactive Compiler version 2.9.0.63208
Copyright (C) Microsoft Corporation. All rights reserved.

Type "#help" for more information.
>
> Console.WriteLine("Hello World! " + new Key().GetWif(Network.Main));
Hello World! L2emt8acTdsGMXzJfAMSARUvKvP8xUCULcQbpiY76EpeyvKyrir2
>

I'm pretty sure there's a less verbose way to pass all those /r: and /u: options on csi startup. But just getting it to find and load the correct assemblies is the main thing.

deduper
  • 1,944
  • 9
  • 22