dnp3_ffi.dll is not copied to .NET app bin folder when installing via NuGet

[db8dee6affba41dca99baae56cf31eec]

After installing the library via NuGet, the native dll is not copied to the bin folder where all of the other app binaries are written to when building.

[emgre]

It used to work, but I recently updated my Visual Studio installation and I can reproduce this. I will investigate when time permits.

In the meantime, you can extract the compiled DLL from the NuGet package (it's just a zip archive) and copy it manually to your build directory. The path within the package is runtimes/win-x64/native/dnp3_ffi.dll.

[jadamcrain]

I'm on VS 2019 16.8.4 and I have no trouble switching between various versions. What version are you 2 running?

[rdholmes]

I also have problems with the automatic copying of the dnp3_ffi.dll and rodbus_ffi.dll dependency files -- but ONLY to my downstream projects, not to my "main" project (which references these NuGet libraries). I'm using Visual Studio 16.11.7. My current workaround is to do a full clean of the solution after changing the library version (either upgrading or downgrading).

[jadamcrain]

Hmm, so only when the DNP3 assembly is a transitive dependency....

[emgre]

Upon further investigation, I think it might be related to the .NET project type, not the Visual Studio version. After the update, my default suggestion for creating new projects was .NET Framework instead of .NET Core.

On .NET Core and its successor .NET 5, it seems to properly copy the DLL under a runtimes folder and it runs with no problem. However, when I create a .NET Framework (e.g. .NET 4.7) project, then the copying doesn't happen and it fails at the first dnp3 symbol.

Looking at how other projects do it, I found that gRPC has two special target files only for .NET 4.X here and here. We might just have to integrate something similar to support .NET Framework.

@rdholmes and @db8dee6affba41dca99baae56cf31eec If you could tell me what edition (or whatever it's called) of .NET you are using, it could really help me.

[db8dee6affba41dca99baae56cf31eec]

@rdholmes and @db8dee6affba41dca99baae56cf31eec If you could tell me what edition (or whatever it's called) of .NET you are using, it could really help me.

Encountered this issue on .NET Framework 4.7.2, using Visual Studio 2022 (17.0.1).

[rdholmes]

We're also using .NET Framework 4.7.2, currently with the latest release of VS 2019, but probably upgrading to VS 2022 soon.

Just to clarify, we use Nuget "package referenences" (rather than the old "packages.config" file).

[emgre]

Hi @db8dee6affba41dca99baae56cf31eec and @rdholmes. I just published dnp3 0.10.0-alpha5 with some changes to automatically copy the DLL when using .NET Framework. Could you try it and report if it fixes the issue?

Since we only package x64 binaries, you will need to either set the platform target to x64 or use the "Any CPU" platform target and untick the "Prefer 32-bit" option (spoiler alert, it won't work on "any" cpu)

[rdholmes]

There's a typo in the new "C:\Users....nuget\packages\dnp3\0.10.0-alpha5\buildTransitive\net45\dnp3.targets" file.

The trailing slash (to end the XML element) is missing from line 3. It should say:
<Import Project="$(MSBuildThisFileDirectory)../../build/net45/dnp3.targets" />

Without this slash, Visual Studio will refuse to load any project that contains a reference to the dnp3 package:
Error: The imported project file "C:\Users....nuget\packages\dnp3\0.10.0-alpha5\buildTransitive\net45\dnp3.targets" could not be loaded. The 'Import' start tag on line 3 position 4 does not match the end tag of 'Project'. Line 4, position 3.

The only way to fix this error is to hand edit the buildTransitive targets file to add the missing slash.

[rdholmes]

The changes in the 0.10.0-alpha5 dnp3 package solved my problems with "transitive" projects.

The dnp3_ffi.dll file is now being automatically copied (along with dnp3.dll) to my "downstream" projects. Thanks!

P.S. Please make the equivalent change to the rodbus package so that the rodbus_ffi.dll file will be automatically copied to transitive projects.

[jadamcrain]

Great. We'll get that typo fixed and then do another release. This is all emitted in our code generator so Rodbus will get the change automatically on the the next release.

[emgre]

0.10.0-alpha6 is now available with the typo fixed.