Nuget distribution. x64 x86 native code library

Developer
Jun 8, 2011 at 9:33 PM
Edited Jun 8, 2011 at 10:05 PM

 I would like to make the libraries available via nuget (a packaging system, striving to be the maven of the .net ecosystem). This would let users use dotspatial as libraries, and would update the libraries from a central repository. It also may help the need to tie a plug in to a specific version of dotspatial.

Some questions

  1. Do we need (or want) to distribute all the DotSpatial Dll's as a single set of libraries?
  2. Native code libraries. Not handled well but Nuget.
  3. How do we test to see if a plug-ins can be used in different versions of DLL's
  4. Using Nuget ourselves to get .net dependencies.

1)  Do you need all the code, or is there some core set. This would also let a project use one or two DLL's outside of dotspatial.

If packaged using Nuget, then dependencies will be retrieved, including non-dotspatial dependencies.

2) Native DLL Dynamic Loading

Rather than having x64 and x86 builds, can we begin to isolate the libraries that access the native code? Aka make separate nuget packages for each native, then there can be scripts to do some of the native code. Other option is to dynamically load native assemblies.

Dynamic Loading Native DLLs in .NET http://archive.msdn.microsoft.com/DynamicDllLoading

http://docs.mosek.com/kb/Multi-architecture_NET_programs.html

If we do this, the we can build the the core of dotspatial in AnyCPU, and the Native library wrappers would be responsible for finding correct native library.

I think for sqllite data access, we would need to just have a package that is smart enough to rename the Dll.

3) it would be good if plug-ins are not built to a specific version of the libraries (not sure if this is still a problem).

4) Nuget has many libraries, it would be good advertising to get the DotSpatial into the nuget repository and to use the repository to get our dependencies.