The problem with "DNP3CLRAdapter.dll"

[Anh Lê]

Hi guys, I have a problem with 'DNP3CLRAdapter.dll'. I use opendnp3.2.2.0 (NUGGET) to build my project (C#), but when I built my solution in Visual Studio 2017 It displayed "Could not load file or assembly 'DNP3CLRAdapter.dll' or one of its dependencies. The specified module could not be found". I have installed OpenSSL but it still has the error. I hope everyone can guide me in handling this problem. Sincerely thanks.  

[Michael LeTan]

Just to help out...
1. Why are you not using 3.1.1?

2. Did you set your project to Build Platform target: x64?

[Jim Scavuzzo]

We struggled with this same error. Make sure OpenSSL 32bit vs. 64bit matches the platform of the Opendnp3 dlls. FYI: We found the x86 version of the Opendnp3 DLLs were looking for the following 32bit OpenSSL dlls in the Path: SSLeay32.dll and LIBeay32.dll. For the 64bit, we ran the "full" installers from Shining Light at https://slproweb.com/products/Win32OpenSSL.html. 

[Adam Crain]

Thanks for the answer Jim. It's either openssl the Visual C++ runtime. Windows really stinks compared to Linux at telling you *what* is missing.

One way to resolve all of these issues is to use dependency walker:

https://www.dependencywalker.com/

or it's modern successor:

https://github.com/lucasg/Dependencies

[Jim Scavuzzo]

We ran into some additional trouble with deploying the OpenDnp3 64bit on a fresh MS Windows 10 x64 OS. We DID find a solution but had some follow-up questions.

We built a .Net application (.Net Framework 4.7.2) from VS2019 and referenced Opendnp3 v3.1.1 from NuGet. This was deployed on the fresh install of Win10 with the following dependencies:

·         Download the "Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019" for x64.

·         OpenSSL 64bit

The application did not run due to more missing DNP3CLRAdapter.dll dependencies. A dependency walker showed the 4 files below missing so we got them off another local computer. But the weird thing is, only the 32bit version would work and we’re running the 64bit version of the DNP3 dlls. Also, it looks like these are "debug versions" (denoted by the ‘D’ in the name) of C++ libraries (v2015 we think), which we didn’t understand either. These “debug versions” are not readily available in the Visual C++ Redistributables (we tried many versions.)

                MSVCP140D.dll

                VCRUNTIME140D.dll

                VCRUNTIME140_1D.dll

                ucrtbased.dll

Any idea why the DNP3CLRAdapter.dll is referencing what appears to be 32bit non-redistributables ("debug versions") of the of C++ libraries?

Additional Notes:

·         The Win10 OS did happen have the “release versions” (same file name minus the ending “D”) installed.

·         Fairly certain the "Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019" are required to run opendnp3 on a fresh Win OS.

·         We interrogated a set of opendnp3 .net dlls compiled from Github using CMake, etc. and found it depended on the same files.

[Émile Grégoire]

Hi Jim,

I've just checked the published binaries on NuGet for 3.1.1, and dependency walker says that both the x64 and x86 versions depend on the release versions of the MSVC redistributables, not the debug version. Perhaps the debug dependency comes from your OpenSSL installation, or another external dependency? If you could screenshot of dependency walker on your program, we might be able to help.

Also, what do you mean by "only the 32bit version would work"? Does it refuse to build, or crash on startup, or report a missing DLL, etc?

Best regards,

Émile Grégoire, P. Eng.

Step Function I/O

[Jim Scavuzzo]

What did I mean by "Only the 32bit version would work"... For example, I copied the 64bit versions of these 4 files to the app "bin folder" and the app threw errors. It ran successfully when I copied the 32bit versions of these 4 files to bin folder.

Here's the screenshot (when the files were missing)...

[Jim Scavuzzo]

Sorry for the confusion, but we solved this issue. We referenced the opendnp3 NuGet package, but the VS solution was still pulling from a pair of .net dlls we compiled from Github using CMake. Once we got this cleaned-up the NuGet opendnp3 dlls  are now depending on the release versions of the MSVC redistributables.