I am now a proud owner of Rhino 7. But I need some help. When I use debug mode in Visual Studio 2017 to debug my Rhino/C++ script, it starts up Rhino 6 rather than Rhino 7. What do I change in Visual Studio in order to get it to use my new Rhino 7?
In Visual Studio Solution Explorer I see that the stadfx.h file mentions Rhino 6 near its start:
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
#pragma once
#ifndef VC_EXTRALEAN
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#endif
// This plug-in is Rhino 6 ready
#define RHINO_V6_READY
I changed #define RHINO_V6_READY to #define RHINO_V7_READY but that caused an error.
for a c# the approach is to open the .csproj in a text editor and search / edit for <StartProgram>c:\Program Files (x86)\Rhinoceros 5\System\Rhino4.exe</StartProgram>
i would imagine that it is similar to c++ projects.
Some VS-Versions allow to edit the debug-Target in the properties of your project.
You found the page for changing this as that was the image in your last post. You need to find where Rhino 7 is installed on your computer and hard code a path to rhino.exe instead of using $(RhinoExeDir)
Rhino is installed as a subdirectory of your “C:\Program Files” directory
That’s your Rhino 7 installation directory since you took part in the WIP process. If you uninstall Rhino 7 and then reinstall, it would land in a Rhino7 directory
That worked. Now Rhino 7 is installed in its own Rhino 7 folder and I used that path in the Local Windows Debugger entries.
Too bad the original install of Rhino 7 did not already take care of this. Seems dumb for it to put Rhino 7 in the WIP directory.
The Visual Studio debugger issue is a bit more esoteric, but if it were my code, I would include a popup to ask if you want this done. I used to get beat up by my 400+ Intel users when I did not do this kind of thing for QDD (Quick Device Design app). With over 43,000 Rhino users I think it would be an even more compelling case. But given limited horsepower, I agree it is better to work on making SubD better rather than fixing a debugger nuance.