Visual Studio Grasshopper Debugger


Hi all,
I have started writing custom components for Grasshopper in Visual Studio 2012 in VB.Net.
Until now, I couldn’t figure out, how to use the Debug mode in Visual Studio to test my scripts. I just copy the .gha into the custom-components folder of Grasshopper and then test ist.
However, it is very difficult to find errors and bugs this way.

Is it possible to use the live-debug mode in Visual Studio at all? If not, what is the best way to debug?

Thanks a lot in advance for any help!
Kind regards,

(David Rutten) #2

It should be possible and when you create the GHA project using the wizard, it should work out of the box. But here’s how to set it up manually:

  1. Set up Visual Studio so that it runs Rhino.exe when debugging starts.
  2. Set up your build flavours so that both Debug and Release end up in the same folder. By default VS will put debug builds in \bin\debug and release builds in \bin\release. I recommend using \bin for both.
  3. Start Rhino and run the GrasshopperDeveloperSettings command. Make sure that COFF loading is disabled (should be the default) and add your \bin folder to the list of folders where Grasshopper looks for GHA files.
  4. Set a breakpoint and press play.

If all goes correctly the debugger now works.

Do note that some of the above options are not available through the UI of Visual Studio Express (that’s why the wizard is so useful). You can still change build folders and debug startup objects, but you have to do so by manually editing the project xml files.


Wonderful. I feel like a new person.
Thanks a lot for the fast response!


I have copied my VS project to another computer. Now, it gives me following error message:

Visual Studio cannot start debugging because the debug target ‘C:\Program Files\Rhinoceros 5.0\System\Rhino.exe’ is missing. Please build the project and retry, or set the OuputPath and AssemblyName properties approipriately to point at the correct location for the target assembly.

I’m using VS Express 2012 on both computers. If I open a new Grasshopper project with the wizard, then it’s working. However, I can’t figure out fixing the paths of the copied project.

Thanks a lot

Visual Studio debug C#
(Giulio Piacentino) #5

Hi Christoph,

You can change the path (it is probably slightly different on the other computer) by using the user interface in any non-express VS. In the project option, you will find the Start external program field:

If your VS does not have that user interface (Express Editions did not have it), the path is stored inside the project .csproj XML file, inside a <StartProgram> tag.
Please let me know if this was helpful.


Giulio Piacentino
for Robert McNeel & Associates


Hi Guilio,
thanks for your answer.
I am using Express, so I don’t have the options shown in your image.
Where exactly is this XML, and where do I need to edit the text? I am using Visual Basic, by the way, not csharp.
So I looked at the \bin folder and found a xml, but I didn’t find any “rhino” in this file. Also in \obj\Debug64 there is a XML, but again without any “rhino”,which I could edit.


(Giulio Piacentino) #7

In that case, inside the .vbproj file. You can just open it with Notepad. It is usually inside the main dir, i.e., not inside \obj\ or anything.


Giulio Piacentino
for Robert McNeel & Associates


That was the right hint. But I had to modify quite some lines in that file, and also rebuild the solution, before it worked.

Thanks Giulio!



Sorry to bother again @piac

sometimes it is working and suddenly it’s not working anymore. Also the projects, which I have created entirely on this computer with the wizard suddenly have this problem. I’m using Windows 8.1 Pro.
I get following message, when I start Grasshopper (Rhino is starting without problem):

Managed Debugging Assistant ‘DisconnectedContext’ has detected a problem in ‘c:\Program Files\Rhino\64-bit\System\Rhino.exe’.

Additional Information: Folgender Fehler beim Übergang in den COM-Kontext 0xaa4678 für diesen RuntimeCallableWrapper: Das aufgerufene Objekt wurde von den Clients getrennt. (Ausnahme von HRESULT: 0x80010108 (RPC_E_DISCONNECTED)). Dieser tritt in der Regel auf, da der COM-Kontext 0xaa4678, in dem dieser RuntimeCallableWrapper erstellt wurde, getrennt wurde oder aufgrund eines anderen Vorgangs ausgelastet ist. Die Schnittstellen werden aus dem aktuellen COM-Kontext (COM-Kontext 0xaa4550) freigegeben. Dies kann Datenbeschädigung oder -verlust zur Folge haben. Um dieses Problem zu vermeiden, müssen Sie sicherstellen, dass alle COM-Kontexte/Apartments/Threads so lange beibehalten werden und für den Kontextübergang verfügbar sind, bis die Anwendung alle RuntimeCallableWrappers, die in ihnen enthaltene COM-Komponenten darstellen, vollständig verarbeitet hat.

If there is a handler for this exception, the program may be safely continued.

Sorry for the German text but I hope the keywords are enough to identify the problem. If you require, I can translate it?

(Thomas Wortmann) #10

Hi @DavidRutten,

Here’s a follow-up question on this undeniably old topic :wink::

What’s the best way to get debug information out of Grasshopper?
(Debug.WriteLine doesn’t work.) Write to the Rhino Command line?
Or should I throw exceptions?

Currently, my component just does nothing when things go wrong, even though I would expect an exception from Visual Studio. In other words, it’s not clear to me how errors are being handled when debugging something in Grasshopper from Visual Studio.


(David Rutten) #11

If you’re using a C# component (which you’re not) then either use RhinoApp.WriteLine or throw exceptions. The benefit of writeline is that your code doesn’t stop running after calling it, whereas exceptions will immediately yield back to Grasshopper.

If you’re using VS then you’d ideally run the debugger. You set your project to start Rhino.exe, you make sure that Grasshopper loads your gha from the bin\Debug folder, and you set a breakpoint.

If that is something you can’t or do not want to do, then RhinoApp.Writeline would be my next preferred method. You probably want to wrap your debug writeline calls into some #if Debug regions, so you don’t have to worry about all that information going to the command line when you distribute release builds.

(Thomas Wortmann) #12


As far as I can see, I’m following the steps outlined above.
Starting Debug in VS indeed starts Rhino.

But I’ve set a breakpoint and the code goes right past it.
(I’ve made sure that COFF loading is disabled.)

I also don’t see any output of my Debug.Writelines.
(Should I? They are greyed out and VS says that method invocation will be skipped.)

The only thing I’m doing different is that I’m not building into bin\Debug, but a custom folder because I have some dependencies. It loads alright, though, I just don’t get the debug functionality.
I’m also not deleting the *.dll that’s created, but copy and rename to *.gha instead.

Btw, right now I’m debugging with MessageBox.Show(), which works but is kinda tedious.

(David Rutten) #13

That probably means you’re not compiling a debug build, but a release build.

By hand? Or using post-build commands?

(Thomas Wortmann) #14

I’ve set the solution configuration (the box left of the start arrow in VS) to Debug, as well as the “configurations” for “build” and “debug” in the project “properties”. Still no breakpoints and debug output though.

With post-build commands.

Also, in properties, the “Enable the Visual Studio hosting process” checkbox is grayed out. I wonder if that has anything to do with it.

(Thomas Wortmann) #15

I found that I can get Output with Trace.WriteLine().
Seems to me that Debug.WriteLine() doesn’t work when running external applications(?).
Still no breakpoints, but the trace helps quite a bit.