Publish MccDaq UL on nuget for .NET projects

[echoix]

It would be super practical and would simplify the documentation for every new project in a dotnet environment if at least the minimal libraries required to build a program would be published on NuGet. This would allow to, at least, be able to compile the project on another computer, or in CI, by referencing that package, and not be required to go set a reference to a specific file set at one location during the installation of "mccdaq.exe". NuGet packages have been standard at least for .NET projects for a while.

Furthermore, if it was possible, it would be even better if the package could target any modern supported dotnet versions, like .Net 6 or 7. Even if nothing is ported at all for newer .NET version, having it published on NuGet would help a lot with project compatibility with newer .NET versions.

.NET Framework 2.0 has been out of support since 2011, almost 12 years ago. However, if I understand the ULHelp.chm document correctly, if the UL for .NET is essentially a wrapper for the C library (without uncommon .net APIs that could be missing in .NET core or later .NET 5, 6, r 7), multitargeting that project to additionally include one of the .NET standard TFMs should be possible easily, and be able to release soon.

 

[echoix]

I saw that multiple people are also having some hard time integrating the library in regard to its particular install/usage requirements.

 

https://forum.red-gate.com/discussion/79097/vs-msbuild-compile-error-but-project-works-in-sa

https://stackoverflow.com/questions/72033167/is-there-a-way-to-use-reflection-to-load-a-net-framework-dll-to-load-in-a-net

https://learn.microsoft.com/en-us/answers/questions/1181408/how-can-i-dynamically-load-net-core-library-with-n

https://stackoverflow.com/questions/75465012/dynamically-loaded-net-core-library-with-net-framework-dependencies-doesnt-lo

https://stackoverflow.com/questions/56434174/how-can-i-allow-a-newer-net-assembly-to-load-without-manual-reconfiguration

 

Multiple tries to get the library wrapped in order to make it used in their projects:

https://github.com/tsimeris/MccdaqDigitalToAnalog

https://github.com/avishayp/MccDAQSampler

https://github.com/pauldeboer1987/MCCDAQ_Wrapper

https://github.com/avishayp/MccDAQCounter

https://github.com/bonsai-rx/mccdaq

[Mike Bouck]

We're one of your old customers who is seriously considering jumping ship especially considering the lack of ongoing support for MCCDAQ and .NET.  None of our new hardware development is taking continued dependencies on your products for this very reason.  The existing .NET MCCDAQ assembly appears to simply be a wrapper around your cbw32.dll (32-bit) and cbw64.dll (64-bit) C drivers.  It's a relatively simple (though tedious) exercise to rebuild the existing wrapper and target netstandard2.0 instead.  If you did that it would be consumable by both .NET Framework and .NET Core customers.

[echoix]

At that time, it was super easy to make a proof of concept by decompiling the existing .net framework MCCDaq library to a C# project with a csproj, then adjusting the settings of that project to include .net standard and even .net 7, and it worked well on an test application. I was waiting for the support team to first answer, and if their answer was negative (ie, it can't be done), I'd answer back showing them how, or asking if it would be allowed to publish such bindings if they don't want to do it themselves. I haven't gotten an answer in 9 months. I didn't go any further as it wasn't obvious if that was the essence of their license conditions. At least they are a bit more open with their Linux UL. I don't understand why a .NET binding that doesn't really have any logic, would be more sensitive than what they published here https://github.com/mccdaq/uldaq. If they had their wrapper (not the cbw32 and cbw64 sources) published on GitHub too, we could offer them our suggestion

Edited January 4 by echoix
missing sentence

[Mike Bouck]

22 hours ago, echoix said:

At that time, it was super easy to make a proof of concept by decompiling the existing .net framework MCCDaq library to a C# project with a csproj, then adjusting the settings of that project to include .net standard and even .net 7, and it worked well on an test application. I was waiting for the support team to first answer, and if their answer was negative (ie, it can't be done), I'd answer back showing them how, or asking if it would be allowed to publish such bindings if they don't want to do it themselves. I haven't gotten an answer in 9 months. I didn't go any further as it wasn't obvious if that was the essence of their license conditions. At least they are a bit more open with their Linux UL. I don't understand why a .NET binding that doesn't really have any logic, would be more sensitive than what they published here https://github.com/mccdaq/uldaq. If they had their wrapper (not the cbw32 and cbw64 sources) published on GitHub too, we could offer them our suggestion

I like it.  We're talking about using this approach and disassembling MccDaq.dll to a .csproj (using ILSpy) and then re-compiling targeting netstandard2.0/net48.  I'd go one further and pack it into a NuGet package along with the cbw32.dll/cbw64.dll C libraries.  Then we can reference MccDaq as a NuGet package (private feed) from .NET Core/Framework projects like any other package.  I don't think this is much work at all and I'm pretty confident it will work.  But of course this will all be unsupported as it will be closed source in our org.  But at least it allows our legacy hardware to not be held hostage by Digilent abandonware.