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

Is it possible the DLL is only for 32 bit, and you are using it in a AnyCPU or 64 bit app?

Thanks @JRys, it seems coherent with what I observed, and I'm ok with this. Have a good day!

The documentation for UL on .NET indicates that if we want to make sure our application will work with future releases. It indicates that "This method must be the first Universal Library method to be called by the program." https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm#Function_Reference/Revision_Control_Functions_for_NET/DeclareRevision.htm However, I don't seem to find any guidance in the docs or the forum on what value to pass. I tried debugging to get some values, and got: MccDaq.GlobalConfig.Version is 5 (an int) MccDaq.MccService.GetRevision( out float revNum, out float vxdRevNum ); gives revNum = 5 (float), and vxdRevNum = 5 (float). MccDaq.MccService.CurrentRevNum gives 5.5 (float). Since I freshly installed the library, I expected it to match the version 6.73 I saw from the download page, or maybe 2.9.0.0, one of the versions I saw in the MccDaq.dll file. I wouldn't have been surprised if it was something greater than 5.20, since a page (About this document) of the help mentioned that the ULHelp considers product version of 5.20 or later. It could have been also the versions of the cbw32.dll or cbw64.dll which both have 1.93.0.0.

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

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.