As far as I know when you use a common name for the native DLL, then it is found via adding the native file extension automatically (e.g. .dll for Windows, .so for Linux)
[DllImport("Dicom.Native")]
So if you use these names for the native DLLs
Dicom.Native.so
Dicom.Native.dylib
Dicom.Native.dll
Then the above DllImport will automatically work for all. Reference
If you are worried about users confusing the native files, first they are already in specific runtime subfolder, and also you can always embed platform description in PE metadata, e.g. description can be "Dicom.Native (win-x64)"
So you wouldn't need to have 4 different imports for a single function, as long as all functions have same name in all native files (I noticed it is so) and you wouldn't need to have if/switch statements for all 4 platforms? This could make maintenance and adding new platforms easier?
Thanks for the library, it works good.
I have a suggestion/question. I noticed you are using boiler plate code everywhere like this:
As far as I know when you use a common name for the native DLL, then it is found via adding the native file extension automatically (e.g. .dll for Windows, .so for Linux)
So if you use these names for the native DLLs Dicom.Native.so Dicom.Native.dylib Dicom.Native.dll
Then the above DllImport will automatically work for all. Reference
If you are worried about users confusing the native files, first they are already in specific runtime subfolder, and also you can always embed platform description in PE metadata, e.g. description can be "Dicom.Native (win-x64)"
So you wouldn't need to have 4 different imports for a single function, as long as all functions have same name in all native files (I noticed it is so) and you wouldn't need to have if/switch statements for all 4 platforms? This could make maintenance and adding new platforms easier?