Hi guys,
I did a clean install on my computer and am now having trouble with working on a plugin. I feel like it’s just a simple setting or something I need to change but cannot figure it out. I cannot seem to debug at a breakpoint and noticed this in visual studio:
I don’t know how come but the plugin doesn’t want to update if I make changes, nor go into debugging mode using a breakpoint.
I did notice there’s dll’s in the folder where I’m running the plugin from and every time I press build in Visual studio it copies all dll’s to the folder.
I tried restarting Rhino, reinstalling the plugin from the bin folder, making sure there’s only 1 instance of Rhino running, restarting my computer but cannot figure it out.
Any help?
Hard to tell. You cannot attach to a process and jump through the code, if sources do not match to the binaries loaded. Are you sure you reference the correct dll/gha in Rhino? You can also use DNSpy for debugging any desired dll. You can use that to see if your gha equal to your sources.
It’s not a grasshopper plugin but a Rhino plug-in. With another plugin I don’t have any issues after clean install so don’t really understand what went different.
I’ll double check the referenced dll’s and perhaps compare them between the 2 plugins.
I was gonna say yes but now I’m not sure. I don’t have my own .dll for this project. Only a .rhp, unless that’s the same? There’s a bunch of dll’s being added to my folder but that’s just the dll’s it’s copying
Yes an .rhp file is just a renamed .dll. Unfortunately I don’t write plugins in C# so I’ve quickly reached the extent of my knowledge (I just happen to be updating an old C# console utility at the moment: the code change took minutes, getting to grips with a Visual Studio several generations newer has taken days, so I feel for you!).
Hopefully someone closer to the coal face will soon be along to solve your problem.
It could also be, that you already have a different copy of your rhp inside another folder which is loaded from Rhino. If that is loaded first, then it could also explain the issue. As I said, if you use dnspy you drop your rhp inside and attach to the Rhino process. If it can load its the one you are using. If not, then the dll is not considered on Rhino Startup. But basically all hints indicate that Rhino does not know your binaries…
I’m sorry @TomTom . I appreciate your help but am a bit lost. I downloaded dnspy but am not sure what it’s for or what to do with it. I can open the rhp but then what?
I’ve been comparing settings from one plugin (that does work) with this one and the references are pointing to the same location. Every reference has the same properties as well. These references are also just standard references I believe and I cannot remember changing or adding anything so don’t understand why it adds those dll’s to the folder when I press build.
make sure “module load messages” is enabled in your output window, so you can see the path from where rhino is loading your plugin, as it starts up under the debugger
for references, right-click > properties and make sure they have “copy local” set to false, for ones provided by the rhino installation (and also of course for .net framework ones)
Ok, I have no idea what has changed since the last time I was trying earlier but suddenly it starts working. I’m happy it works again but hate the fact that I don’t know what changed and solved it.
Anyway, thanks everybody for trying to help out! @TomTom@jdhill@jeremy5
It still creates those .dll’s though, which I don’t like since I imagine this is gonna cause issues when I try to send over the plugin to somebody else.
@jdhill I checked under properties and all of them are have “copy local” set to false.
that seems strange; I guess I would double check that all have copy local set to false, save the solution, close visual studio, delete the ./obj and ./bin dirs, and the hidden .vs directory, and then try again
also check what may be in post-build for all projects & confgurations
I thought I already double checked but since you mentioned it I was going over them again and it turns out I had RhinoWindows set to true.
Thanks a lot @jdhill
sure thing, but we still have to see if you can get debugging working, and here I’ll just say what I generally do is to have a post-build script that copies the output to a staging dir, so that a) there is one path from which rhino loads the plugin, whether debug or release, and b) even if unnecessary libs were being copied it wouldn’t matter, because I wouldn’t copy those to the staging dir (but I will copy things like toolbar files, etc, which are part of the final installation)
in my case I actually have separate staging dirs for each configuration, and a further clean & copy from those to the plugin’s natural installation directory under appdata/roaming, so that when I run during development, as much as possible is the same as it will be on the user’s machine; I also then build my installers from the intermediate release staging dir, further reducing any uncertainty about what will end up on the user’s machine
It’s working again though I don’t know why or how it does now :
Nonetheless, interesting approach you have with the post-build steps. Might need to implement a similar system at some point, but for now I need to get the stuff done I was trying to do hours ago.
I’m happy it works again but hate the fact that I don’t know what changed and solved it.
: