Closed surban closed 6 years ago
I'm currently busy with the new Cuda 9 version... I'll look at it asap I'll find some spare time :)
Looking forward to it.
In the meantime I have published the resulting NuGet packages on a private feed at https://www.myget.org/feed/Packages/coreports
+1 to porting to .NET Standard 2.0! This would be very helpful.
While you are busy reviewing the changes, would it be okay if I publish the .NET Standard port on NuGet using a different package name? For example ManagedCUDA.NETStandard?
I am asking because I want to put a library I am developing on NuGet, but for that I need ManagedCUDA with .NET Standard support on NuGet.
Yes please go on, I have no problems with that
I have published the .NET Standard port at https://surban.github.io/managedCuda.
NuGet packages have the suffix NETStandard and can be found at https://www.nuget.org/packages?q=managedcuda+netstandard.
This is a port of the library to .NET Standard 2.0.
The main issue (aside from adjusting the project files) was to deal with mapping DLL names from Windows to Linux, e.g. nvcuda.dll becomes libcuda.so.1. The DllMap mechanism Mono used for that purpose is not available on .NET Core. Currently the DllImport native loader takes the specified library name and transforms it to lib*.so on Linux. No alternative name specification is possible, but alternatives are discussed at dotnet/coreclr#930.
To workaround this issue and keep a single cross-platform package, I generated stub shared objects (see
StubsForLinux/generate.sh
on how this is done) that are named like the Windows DLL and contain a reference to the correct library name for Linux. This allows the Linux dynamic linker to correctly resolve the native libraries. The stubs are distributed inside the NuGet package, but since each is only 8 KB in size, the overhead is marginal.To build all NuGet packages, make sure that .NET Core 2.0 is installed and then run
dotnet pack -c Release
from the root directory. Generated packages are placed into thePackages/Release
directory.I tested consuming the built packages from .NET 4.6.1 using Visual Studio 2017.3 on Windows and .NET Core 2.0 on Linux. Both work fine. Mono 5.2 does not work currently, because .NET Standard support will only arrive in Mono 5.4.