[Publish MccDaq UL on nuget for .NET projects]

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.

 

[Publish MccDaq UL on nuget for .NET projects]

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.

[The Universal Library seems very outdated]

On 8/8/2023 at 9:43 AM, Fausto said:

Hello @Claus Andersen.

The MCC Universal Library is not supported under Microsoft .NET Core or .NET 7.  The installed MCC DAQ examples have not changed.  The C header file (cbw.h) and libraries (cbw32.dll and cbw64.dll) are located in the 'C:\Users\Public\Documents\Measurement Computing\DAQ\C' folder.

Regards,

Fausto

That's too bad.  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.

[Plans to Update SDK to .NET Core for MCC Daq (1208, 1808, etc)?]

On 8/28/2023 at 10:10 AM, JRys said:

Surprisingly, the number of requests for .Net Core support has been low. I'm confident that it will become more of a priority when the demands increase.

 

That's too bad.  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.