Go to Grasshopper Development Settings by typing GrasshopperDeveloperSettings in the Rhino Command, and Enable the option Memory load *.GHA assemblies using COFF byte arrays. That is, we need to allow Rhino to dynamically load plug-ins. Enable Memory Load Assembliesīefore we continue, there is a setting we will need to turn on. It takes a full restart of Rhino for the newly installed Grasshopper plug-in to take effect.Ĭlosing the Grasshopper window and re-open it will not help, since GH will still silently run in the background.Īgain, restarting Rhino will be the naive way to reload plug-in, but it soon becomes tedious once a lot of changes are made incrementally. Reload Grasshopper Plug-In in Rhino The ProblemĪnother problem still persists. We have now finished automating this deployment procedure. Make sure to save your commands by pressing CTRL S. It erases the plug-in binary that just got generated by Visual Studio, since it is not necessary to keep that file once we copied our plug-in to the correct location. We will be modifying the following scripts into the command box above.Ĭopy " $(TargetPath ) " "C: \U sers \Y OUR_USER_NAME \A ppData \R oaming \G rasshopper \L ibraries \M 圜omponent.gha" Now, let’s automate this copy and paste process. Then, go to Build Events, where we can set scripts to run after build in Post-build event command line, where I denoted as INPUT_COMMANDS. We can navigate to the solution’s properties by right clicking on the solution, and select Properties. Since we want this to happen after we finish building the plug-in, Visual Studio allows us to write scripts (In PowerShell on Windows, macOS unknown) to let VS do things after complete build. Let us automate this process, let’s sum up what we wish to do above: we want to build a file using Visual Studio, then copy that file to a new directory. Such procedure might sound plausible at first, but soon get tedious when a lot of small changes needs to be performed on the same plug-in for a lot of times. The naive way, then, for one who is developing their own plug-in for deploying it, is to manually copy the generated plug-in after building it to this location and restart Rhino. Rhino and Grasshopper (Which runs in the background even when one closes the Grasshopper window) will load the newly developed plug-in at the next restart of the main Rhino software. Such folder can be found by going to Grasshopper Window - File - Special Folders - Component Folders,Ĭ:\Users\YOUR_USER_NAME\AppData\Roaming\Grasshopper\Libraries However, in order for Rhino to correctly recognize the custom plug-in we wrote and load it so we can see it in Grasshopper shelf, the plug-in should be placed inside a special folder. Rhino’s Default Nature of Loading a GH Plug-In \M圜omponent\bin\M圜omponent.gha for older versions of Rhino. \M圜omponent\bin\Debug\net48\M圜omponent.gha, where the net48 can vary, and such file might exist in. The default nature of building a Grasshopper component using a solution (In this post, I will refer to this solution as M圜omponent.sln) in Visual Studio is that it generates a M圜omponent.gha file under the project local folder. Automating Grasshopper plugin deployment Visual Studio’s Default Nature of Building a GH Plug-In This post was written based on Visual Studio 2019, Windows 11, and Rhino 7, at the time of writing. This post is essentially some notes I jogged down from Long Nguyen’s C# Scripting and Plugin Development for Grasshopper,Īs it is very helpful when setting up build environment for Rhino using Visual Studio. Automatic plugin deployment for Rhino and Grasshopper using Visual Studio.
0 Comments
Leave a Reply. |