Forums › General Discussions › dotnet Core and Linux
- This topic has 1 reply, 1 voice, and was last updated 5 years, 8 months ago by
kaiser.
- AuthorPosts
kaiserParticipantReally more of an FYI if anything.
I had a Windows C# application that we used for initial development of some algorithms and functionality for a customer. It worked quite well.
Then another customer required CentOS Linux. We re-wrote the application in C++, which was fine. It worked. We were sad to see many of the niceties of C# fade away, but there’s nothing wrong with C++, if you’re used to it.
We now had a need to harmonize code-bases, as we started implementing features moving forward.
Was playing with .Net Core 3.0 preview for Linux / Windows, and decided to try and get our C# code running on Linux. So we set up a CentOS 7 box, got everything installed nominally. Created a .Net Core 3.0 application, and then in the sm_api.cs (in the windows examples directory), merely replaced all “sm_api.dll” with “sm_api.so”, and it just worked.
So to anyone out there wondering if this is possible, or how well it works, or how to do it, or what they should do for cross-platform development, I’d heavily recommend .Net Core. VS Code can SSH into multiple remote computers either Linux or Windows, remote develop/build/debug and it works great. You can also deploy the same application via docker, and so on. In fact, the debugger works much better with respect to pausing the SM200’s queued captures and then re-starting than gdb ever did.
Enjoy all, and good job Signal Hound team!
kaiserParticipantUpon further investigation, you can change the sm_api.cs to just be like:
[DllImport("sm_api", CallingConvention = CallingConvention.Cdecl)] public static extern SmStatus smGetDeviceList(int[] serials, ref int deviceCount); [DllImport("sm_api", CallingConvention = CallingConvention.Cdecl)]
Then if you’re on Linux, it looks for sm_api.so, libsm_api.so and on windows it looks for sm_api.dll
Nice little benefit for interoperability. If you need to specify x64, x64 and other arch’s, you’ll probably need to SetDllDirectory or LoadLibrary with a dynamically added name, or a custom build step to rename the proper dll and put it with the assembly. DllImport only can do so much matching.
- AuthorPosts
You must be logged in to reply to this topic.