This is probably something trivial but it’s weird.
And before you mention it, neither running Rhino as Administrator nor the unblock of the rhp file does the trick.
What I do is simply building the visual studio project and try to load the plugin.
Another thing:
There’s no way to clean these plugins apparently they leave entries in Windows registry and I have to clean it up manually.
Is there a more convenient, safer way?
here’s the system info
Can’t say I have seen this before with plug-ins built by myself (including the developer samples). I’d venture to guess this has to do with windows settings. Have you tried asking the internet elsewhere?
No, there is no tool for cleaning up the registry other than regedit. There is an old feature request here: https://mcneel.myjetbrains.com/youtrack/issue/RH-1468
I’ve added this thread to the issue.
I haven’t change any windows settings, I update windows every now and then but not since the last time I tried building rhino plungins. Back then they worked. As a matter of fact the only significant change would be the two Rhino 6.15RC updates that I installed.
With 6.13 and 6.14 everything worked
I’m also on the latest RC for 6SR15, I have today been compiling and testing custom plug-ins several times. AFAIK there hasn’t been any extra code testing for plug-in origin - @brian?
FWIW, the few times that I have seen that on my system, a reboot of the PC did the trick.
Yes, that is definitely something I will try 
my pc runs 24/7 so… that is the only thing I haven’t yet tried.
The next step would be complete clean up of everything McNeel I see on my PC. Registry, files, folders, appdata, programdata… Perhaps a tool would be nice. I saw when peaking at regedit that I still have Rhino 5 stuff there.
@brian is it possible to make the installer clean/uninstall the previous version (without the configs of course) before installing the update?
Also clean the registry upon uninstall of removed plugins.
No, that’s not possible. If you want clean, you’ll have to manually take steps to make your computer clean. Most of my customers would be very disappointed to have all their settings destroyed and third party plug-ins unloaded every time it updated.
Not updated, uninstalled. Like I said, I still have Rhino5 plugin information on my PC and I have uninstalled R5 about the same time R6 was released.
I hear you. Sadly, Windows doesn’t make this very easy. Presumably you’ve seen this article? https://wiki.mcneel.com/rhino/5/uninstall
I haven’t read this
I know about a utility I have used in the past when I was having issues with software installed using Windows Installer.
The Windows Installer Cleanup utility ( MSICUU2 .exe)
But I think they have retired this tool.
I used NSIS (Nullsoft Scriptable Install System) a while ago to ease my colleagues in installing an old software that was delivered as a zip with huge documentation where each file must go and what you have to add to the registry.
Isn’t this an option? It is highly customizable (open source).
Is there a way we can get Rhino as a zip then we can make our own installer, this way we can control what’s installed and where.
e.g. I will not allow RhinoSplash.dll to be installed. I can automate what shortcuts are created and with what arguments, change the icons. Respectively, what is deleted upon uninstall.
Installation on Windows is complex. Because you’re asking for details, prepare for details…
The Rhino 6 installer includes 4 (minimum) and 12 (maximum) separate MSI files that get executed, in the proper order, after making sure that 3 different C-runtime libraries are installed, as well as a proper version of the .NET 4 framework. All of this is orchestrated using a bootstrapper generated using a tool called Burn, developed by the WiX development team (an open-source language for authoring Windows Installer installers).
We chose this mechanism because, under the hood, it uses Windows Installer. Windows Installer is the recommended, best practice, for installation on … Windows. Not only does it work for individual users to install the product on their computer, but it includes provisions for creating deployments for an entire enterprise. We need to support not only one-off installations, but corporate installations of hundreds of computers distributed throughout the world.
And, because of the way Windows works, a clean uninstall is nearly impossible for us to do. Here’s why:
First, when Rhino installs, it installs for all users. It runs under elevated account credentials, using an account that may or may not be the end user account. Often, especially in corporate environments, a system administrator account is used to do the installation. The installer creates files in the Program Files folder, the ProgramData folder, and registry keys in the HKEY_LOCAL_MACHINE registry. It also creates registry keys in HKEY_CLASSES_ROOT. When Rhino uninstalls, it removes all these things.
But wait, you also get your local settings. When Rhino starts, it extracts toolbars, settings files, and resources localized into the language you’re running Rhino in. It puts these in your roaming profile, which is both C:\Users<you> and HKEY_CURRENT_USER. If you download and install other plug-ins, they sometimes install in your roaming profile, sometimes for all users. Rhino also keeps track of your last-opened files and the settings you’ve changed - all in your roaming profile. (The roaming profile can be configured by sys admins to be stored on a server, and to follow the user from computer to computer - so they can get back to exactly what they had set up regardless of the computer they log into – provided Rhino is installed everywhere).
Now, when a second user logs in to the system, all of what you described above happens for that user, in their own set of registry keys and roaming profile folders.
But you asked about uninstall… during uninstall, the installer can remove all the things that it knows about. Here is one important thing it doesn’t know: what users have started Rhino? And even if it did know, it likely doesn’t have permission to delete things from the user’s personal space. And even if it could, it might be a really bad idea.
And, there’s this tricky bit about upgrades. They’re technically part uninstall, and part install. And it turns out getting things right just for the shared resources on the machine can be technically tricky. Doing it for all the per-user resource would be really hard.
All of this results in Microsofts recommendation to not delete user-specific information during uninstall. This brings the added benefit of letting users uninstall and reinstall, yet maintain their settings - sometimes that’s necessary for a number of different reasons.
That said, you can clean up most of what Rhino installs by:
I’ve shied away from writing an application do clean up the local computer because I’m concerned it might delete too much and cause other problems for you.
The following statement is sarcastic, and also contains truth: If cleanliness of your systems if utmost importance, I recommend never installing or running software - it just adds clutter.
This isn’t a Windows Installer problem, after all. It’s a Windows problem. NSIS isn’t going to help.
It does look time-consuming to set up the installer, but not that complex. As far as I remember NSIS also can run other installers, even download the installers in runtime. It can check registries, users, permissions.
What I don’t know is if it can create a user-group/user for itself to run with.
What is the difference in single-user vs. corporate installations?
Is it just the user permissions?
Honestly, I personally don’t see any point in placing files in any of the above folders. User should be given the freedom to install Rhino in any folder and contain all of its files there, except for the TEMP folder and the .net framework libraries of course.
What if all user-settings are stored in one place. Some single-file-database in ProgramFiles or under C:\Users\All Users then Rhino will have permission to read/write/remove them. It is a database so, you don’t even need to delete the file, just clean up entries. And upon uninstall the user/admin can confirm a full cleanup or just uninstall, leaving user settings intact.
That’s why I use a lot of portable applications, or make them portable if it is possible. 
There’s no difference. Rhino installs the same for both.
You’re welcome to that opinion.
That would break roaming profiles for educational and corporate users.
Maybe someday Rhino will be portable. It’s currently not a priority, and it’s a lot of work.
Why is that?
Because roaming profiles are in C:\Users\<user>\AppData\Roaming and HKEY_CURRENT_USER. If we move user settings to C:\Users\All Users they won’t roam.
Anyway, this isn’t going to change anytime soon, and I’m tired of justifying it to you.
Did I cover it all?
Seems pretty complete.
Hi @brian, when you mentioned installing the plugins for all users, are there any documents about how to do this with Rhino?
Because for educational and corporate users, it is basically IT gets controls of what can be installed. We are still looking for a solution for this case when IT installs our plugins (rhp, gha and ghuser), We would like to enable all users on that machine to have access to our plugins.
All I could find from Rhino’s documents/discourse, they are all suggesting to install plugins to following user specific locations:
C:\Users\Name\AppData\Roaming\McNeel\Rhinoceros\packages\
C:\Users\Name\AppData\Roaming\Grasshopper\UserObjects
C:\Users\Name\AppData\Roaming\Grasshopper\Libraries
What’s the best practice to install plugins for all users? or something that makes Rhino-aware about that there is a new plugin installed by IT when users log in with their own account, and they can complete setup with any user-specific configurations?
Thanks in advance.
Mingbo
@will - is this something you can help with?
