![]() What’s odd is that it is not happening on other input types e.g.This series of videos will show you how to create a wall from a curve created in Revit and how to import it in the Grasshopper environment through plugin.ġ. GH_InputParamManager.AddPlaneParameter(string,string,string,_ParamAccess,)Īt _Component.PostConstructor () in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/Grasshopper_osx/Grasshopper/Kernel/GH_Component.vb:161Īt _Component.ctor (System.String name, System.String nickname, System.String description, System.String category, System.String subCategory) in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/Grasshopper_osx/Grasshopper/Kernel/GH_Component.vb:148Īt () in /Users/filipe/10_VSProjects/RoomSurveyor/RoomSurveyor/RoomSurvey4.cs:43 PManager.AddPlaneParameter("Plane", "Pl", "The plane the polygon is on", GH_em, Plane.WorldXY) Īfter updating to V7 I’m getting this error while loading the plugin on Grasshopper: System.MissingMethodException: Method not found: int. Previously I was able to provide a default value for plane inputs. I’m getting an unexpect runtime error with the RegisterInputParams method. After updating the extension and de-referencing nuget v6 libraries. ![]() The project was originally built with a V6 template on Visual Studio Mac 2019. I’m having issues updating a plugin project to Rhino v7. (I’ve got that stored in my Applications folder for the time being.)įinally, VS, Rhino or both seem to be creating some dll files in my Bin/Debug/net45 directory that I haven’t seen before. As you can see from the csproj file though, RhinoCommon only appears to be loading once.Īlso, whenever I exit and re-start VS, it loses the RhinoCommon.dll file. I can’t get rid of the one that seems to be in a subdirectory of Grasshopper. When I screen copied the error message above, I included something funny looking on the left. The component isn’t showing any errors, but no output either.Ī few more things to note that may or may not help. The programme is a copy of a previous one that was running but there might have been some errors introduced in my copy. After that, if I click on Run/Continue Debugging in VS, Grasshopper will finish loading but the component is, in effect, dead. The program hasn’t started yet, Grasshopper is still initialising. For the rest of you, if you’re interested in geometry, architecture, AI or anything else but vagaries of computer threading science, I’d advise to avoid an upgrade to Rhino 7 like the plague! So, to the very good people at Rhino – and I do think you’ve done wonderful work – please, please PULEEEASE (!) come up with a Rhino 7 Plug-in Wizard soon. I really, really, really don’t want to be an expert on these things!! But, given the current state of the release, I’ve got no choice. I’ve probably done all kinds of things wrong in these fixes. Right now I’m thinking of abandoning Rhino 7 completely. Which I was doing anyways but it makes de-bugging very difficult and has a habit of hanging up. Right now the only way I can detect Breakpoints is if I run the component on a Timer. Why, if I’ve upgraded to Rhino 7, got the most recent updates for everything RhinoCommon, why does my RhinoCommon.dll file have a date of 24 June 2020 on it?!) So I re-installed the RhinoCommon.dll and still VS wasn’t finding the Breakpoints. Fortunately, I had another copy elsewhere on my machine. It could only have been VS or Rhino because I wasn’t working with anything else on my computer at the time. It turned out that something deleted my RhinoCommon.dll file from the location I had set. ![]() Then for no apparent reason the debugger stopped finding Breakpoints. After about a five hour search, where I found other things that may or may not have been awry, updating the Dependencies finally got things to work.Īt least for a day or so. In your Solutions panel in VS go to the ProjectName subdirectory and make sure your Dependencies include Grasshopper and RhinoCommon in the NuGet subdirectories, as shown in the image. I’m sure it will help with other problems. Which I don’t really need to get into, but here’s the fix. ![]() It didn’t matter where I tried to do the declarations in my code. And immediately I ran into a problem initiating Surfaces or NurbSurfaces. So, that got the de-bugger to recognise Breakpoints. That is to say, the version number must not be something like 6.x, as would be generated for Rhino 6. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |