Unsync, is the keyword. An eco system of developer tools not in sync is bad. very bad. Hopefully I didn’t forget to point out that its bad.
This is bad. Due to hardware constraints I had to install VS on the metal (in addition to VM) and I can’t compile VS2015 projects in VS2017 (missing or invalid GrassHopper paths). Couldn’t even add the missing grssHopper (5) paths in the project created with the old VS2015.
I really think that the R5 templates and wizzards should be updated to install for VS2017.
Fig.1. The two R5 templates (screenshot from VS2015) are not available for install in VS2017 :
This is getting annoying. It is a simple matter of fact that R5 will be around for some time yet (due to some plugins running only for R5) even if developing for R6. Currently “everything” in the eco system around Rhino is going more and more into a state of “unsync”.
If you don’t fix the develoepr ecos system, why then not open source it so we can fix it ourselves? Development with tools that you cannot fix when the world moves on, is one of the critical factors when deciding whether to use or abandon certain tools chains.
Short version: Fix the templates and NuGet packages for VS2017.
This is how I set up a Grasshopper 0.9.0076 Add-On Project using the v6 template:
Start VS 2017 and start a new Grasshopper Project:
Change the debugging application in ‘Rhino.exe 6’ to point to Rhino.exe for Rhino 5 (this can also be changed later in the Properties>Debug page for the project). Assembly references can also be changed here, but I prefer to do it through the Solution Explorer once the project is set up.
Add the reference to Grasshopper.dll, GH_IO.dll, and RhinoCommon.dll either from disk, or from NuGet.
From Disk. Right click on References in the Solution Explorer or go to the Project menu and Add Reference. Browse to the Rhino 5 Instalation in Program Files. You’ll find RhinoCommon.dll in the System folder. Browse to the Grasshopper installation in %APPDATA%\McNeel\Rhinoceros\5.0\Plug-ins\Grasshopper (...)\0.9.76.0 Add GH_IO.dll and Grasshopper.dll:
From Nuget. Right click on References in the Solution Explorer or go to the Project menu and select Manage NuGet Packages. Browse for Grasshopper and choose the ‘Latest Stable 0.9.76.0’. Install. This will install all necessary dlls.
Test the add-on by starting a debug session and install the .gha in Grasshopper.
This is how I set up a Rhino 5 RhinoCommon Plugin Project using the v6 template:
Start VS 2017 and start a new RhinoCommon Project:
Change the debugging application in ‘Rhino.exe 6’ to point to Rhino.exe for Rhino 5 (this can also be changed later in the Properties>Debug page for the project). You could also modify the references here, but I choose to do it from the Solution Explorer once the project is set up.
Press Finish to complete the wizard.
In the Solution Explorer, remove the references to Eto.dll, Rhino.UI.dll, and RhinoCommon.dll:
Add the reference to RhinoCommon.dll either from disk, or from NuGet.
From disk: Right click on References in the Solution Explorer or go to the Project menu and Add Reference. Browse to the Rhino 5 Installation in Program Files. You’ll find RhinoCommon.dll in the System folder:
From Nuget. Right click on References in the Solution Explorer or go to the Project menu and select Manage NuGet Packages. Browse for RhinoCommon and choose the ‘Latest Stable 5.12.50…’. Install:
Thank you @fraguada for this detailed tutorial. Its very valuable, especially for very new users of this technology.
Of course I had to figure out how to get my “old” projects running also under VS2017, but it took a while to figure it out when new to VS and new to most technologies involved (wish I had this tutorial from start…).
But of course it would be even better if the templates and wizzards were fixed and in so doing signalling that developers are not left alone out in the wild.
I still hope to be able to use Rhino for a new application (not meant to be used as a “plug-in”, but as a separate application based on Rhino/GrassHopper), but it would feel safer if the dev tool chain was kept up to date. There’s an increasing feeling of being in limbo between Rhino5/WIP as it is now. having said that, I really do apprechiate all things that works so very well (which is most of it).
No problem!
While I think it is best to upgrade to VS 2017, you could continue to use VS 2015 and develop with the templates for WIP and 5 while in this limbo and get the average of all of the options. Is there a specific reason you need VS 2017? I switched over due to our internal tooling, but also because VS 2017 seems to handle better node.js / javascript based projects better than VS 2015 (where node.js tools for VS was introduced).
I just came to think of thet fact that some forum posts are so good that they could be split off and tagged as “Tutorials”. Intoa separate forum catagory for “Tutorials”. Your post is one of them that would qualify. I’ve seen several such posts by @piac as well. Very good.
I’m working on my own wiki collecting such info, but I think that the Rhino community should run one such wiki, with only users that have a personal page also here.
Hi again,
No other than I was encouraged here on the forum to use the “latest VS”. Now I reinstalled VS2015 alongside, so I kan start new Rhino5 projects there and then switch over to VS2017. Evil strategy but it simplifies a bit. The bad thing is that I’m now back on the metal from my VMs.
BTW, I just got the Alea gpu programming model to do what I tell it to do. Looks promising!
I’m sorry to see you afflicted by this. I’d like to give a little background. We (and especially I) are probably explaining things in a wrong way.
First of all, there is nothing we can do to make the existing V5 wizard work with VS 2017, as VS 2017 no longer support manifest types that were supported in VS 2010, VS 2013, VS 2015. The only possibility would be to write another wizard only for V5 and VS 2017. It takes significant resources to create and maintain such a wizard.
Given that we needed a new wizard for V6, I wrote it again from scratch so that it would work with VS 2017. There was a workaround available from Microsoft to have it work in VS 2015, too. So this is the situation.
If you feel to express a wish to have a third wizard, that is something we can keep into account. However, really, every legal developer targeting V5 can have access to WIP. You can set up the project in WIP/V6 and then use the result of the V6 wizard in V5 by just switching a few references. We kept RhinoCommon as much as possible forward-compatible between V5 and WIP. For this reason, there is little pressure to create and maintain a parallel project.
If you need any help, or would like to discuss this more, please let me know.
Much appreciated,
