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
Hello,
The original intent for DeclareRevision was so that we could make changes or fix bugs and not have to worry that we broke your program. However, we stopped managing it quite some time ago because no matter what you set it to, it returns 5.5, and GetRevision returns 5. One indication that this is true is the GetRevision function. It has a parameter for a VXD library, which was old Visual Basic 6 technology. I think you should use MccService.DeclareRevision(out revNum) where revNum = 6.73. It may not do anything, but later when someone reads your code, they'll know you had InstaCal 6.73.
Best regards,
John
echoix got a reaction from Ron Byron in What value to use for MccService.DeclareRevision
echoix got a reaction from Mike Bouck in Publish MccDaq UL on nuget for .NET projects