Using Nuget for our .NET References

[stevebaer]

@will, @brian, @DavidRutten, @curtisw, @dan, @dale, @JohnM

I’m beginning to wonder if it makes sense to make our .NET SDK references available as nuget packages. I still haven’t thought the whole thing through so please bear with me.

The issue that I’m trying to solve is to make it easy for developers to get the appropriate DLLs in their plug-in projects for building plug-ins and GH components. This includes allowing developers to use older versions of DLLs than the current shipping Rhino for whatever reason they want an older version.

Another issue I’m trying to solve is to make the plug-in project more ‘portable’. Currently, the project references to DLLs like RhinoCommon or Grasshopper are possibly different on each machine since they are direct paths to the installed DLLs. This problem get compounded because the path to RhinoCommon on OS X is guaranteed to be different than the path on Windows. Currently this problem exists for RhinoCommon and Grasshoppper, but it is going to start happening for Eto and Rhino.UI as we move forward.

The RhinoCommon DLLs are going to be slightly different on Windows and Mac which I think nuget can solve too.

Any of you guys know enough about nuget to weigh in on this idea? Does this make our developers lives better or worse?

[brian (Brian Gillespie)]

I’ve loved using Nuget compared to other ways of referencing third party
libs - I think this is a great idea.

[menno (Menno Deij - van Rijswijk)]

We have a corporate nuget server (ProGet) that we use to distribute reusable components, for example to use in our continuous integration build servers. We have packaged the complete rhino 5 sdk into a nuget package, supporting both c++ and .net development.

I can send you the package if you’re interested.

[will (Will Pearson)]

Yes. A hundred times yes!

I wrote pyget so I could host my own gh and rhinocommon libs and do CI on Plankton (and to learn about package managers).

[stevebaer]

@menno

We have a corporate nuget server (ProGet)

Is there any benefit to using ProGet over just hosting our own nuget server (or directly publishing to the main nuget)?

@menno

I can send you the package if you’re interested.

Thanks, I may take you up on that but not just yet. This would definitely be something we would place in our build process.

@will

I wrote pyget so I could host my own gh and rhinocommon libs and do CI on Plankton (and to learn about package managers).

Would this be a better route than nuget? I kind of doubt it but feel I need to ask

[will (Will Pearson)]

@stevebaer pyget is just a cross-platform nuget server you might as well use nuget.org.

[will (Will Pearson)]

Adding an extra feed for a private server creates an unnecessary barrier to developers.

[stevebaer]

How would you suggest we set up packages?

[menno (Menno Deij - van Rijswijk)]

Is there any benefit to using ProGet over just hosting our own nuget server (or directly publishing to the main nuget)?

We use a corporate server to host packages that are not for public consumption. The advantage of ProGet is that it merges the official nuget stream with the local packages, making its use transparent to the user.

Also, we found that the vanilla nuget server quickly became bogged down when large packages were used, probably related to indexing. Therefore we switched to ProGet.

[menno (Menno Deij - van Rijswijk)]

One thing to maybe take into account is the new developments around .NET, specifically the direction .NET Core is going (which also gets distributed at nupkg!). It seems to align with using RhinoCommon in a cross-platform way.

[fraguada (Luis Fraguada)]

Rhino3dmIO is already available as a nuget package which is great!

@stevebaer

The issue that I’m trying to solve is to make it easy for developers to get the appropriate DLLs in their plug-in projects for building plug-ins and GH components. This includes allowing developers to use older versions of DLLs than the current shipping Rhino for whatever reason they want an older version.

This alone would make the effort into doing this worth it!

@stevebaer

This problem get compounded because the path to RhinoCommon on OS X is guaranteed to be different than the path on Windows. Currently this problem exists for RhinoCommon and Grasshoppper, but it is going to start happening for Eto and Rhino.UI as we move forward.

I have a cross-platform project that I build one at a time depending on the platform I am on, even though it shares the same code base. If I could build and push the .dlls out in the same process, I could build all of the dlls in one go which would be very nice.

[stevebaer]

@menno

One thing to maybe take into account is the new developments around .NET, specifically the direction .NET Core is going (which also gets distributed at nupkg!). It seems to align with using RhinoCommon in a cross-platform way.

Yep, we may be able to get there for V6 code for both Windows and Mac, but definitely can’t for V5 Mac Rhino. There are differences between these two versions of RhinoCommon that we just can’t overcome. Even though RhinoCommon was initially intended to be “common” between platforms, some platform specific code crept in (WinForms) and some of the SDK just doesn’t exist on Mac Rhino yet (some RDK classes.)

It is definitely something I’m keeping an eye on and trying to learn more about as we move forward.

@fraguada

If I could build and push the .dlls out in the same process, I could build all of the dlls in one go which would be very nice.

It would be, but I doubt we’ll be able to get that far in the near future. I’m looking at the distribution issue first. The cross-compile issue is even harder.