Mike Bouck

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.

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.

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.

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.