Hi @brian,
Regarding this:
https://wiki.mcneel.com/rhino/installingrhino/6
Is there a way, without launching Rhino to:
apparently (4) is there, (3) could probably be done using variety of tools and scripting languages, but (1) and (2) ?
The automatic update system does the first three for you; turn it on.
Or, if you want to rewrite that system, you can:
Hope that helps.
Yes, I think it does. Thanks.
Hello, did you manage to work out a solution for this?
I’m sorry, but after 4 years I don’t even remember why I asked that question. 
Anyways, by the looks of it this cannot be done by single/simple batch file. Perhaps that was why I didn’t see it through.
I remember only creating a clean-up batch, to remove all previously installed plugins and version of Rhino.
@echo off
cd %HOMEPATH%\Downloads\
rem 0. uninstall plugins
msiexec.exe /x Bongo_30_Release_x64_English_20210830_3_0_49391.msi
echo Bongo uninstalled.
rem 1. Uninstall Rhino start
echo Uninstalling...
rhino_en-us_7.10.21256.17001.exe -uninstall -quiet -norestart
cls
echo Uninstall completed. Press any key to continue.
pause > nul
cls
echo Cleaning the registry...
rem 3. remove registry entries
reg delete HKEY_LOCAL_MACHINE\Software\McNeel\ /f
reg delete HKEY_CURENT_USER\Software\McNeel\ /f
echo Registry cleaned.
pause > nul
rem 4. removing related folders
cls
echo Cleaning all McNeel folders...
rmdir /s /q "C:\ProgramData\McNeel\"
echo C:\ProgramData\McNeel - deleted
rmdir /s /q %HOMEPATH%\AppData\Roaming\McNeel
echo C:\Users\username\AppData\Roaming\McNeel - deleted
rmdir /s /q %HOMEPATH%\AppData\Local\McNeel
echo C:\Users\username\AppData\Local\McNeel - deleted
rmdir /s /q "C:\Program Files\Common Files\McNeel"
echo C:\Program Files\Common Files\McNeel - deleted
rmdir /s /q "C:\Program Files\Rhino 6"
echo C:\Program Files\Rhino 6 - deleted
rmdir /s /q "C:\Program Files\Rhino 7"
echo C:\Program Files\Rhino 7 - deleted
rmdir /s /q "C:\Program Files\Rhino 7 WIP"
echo C:\Program Files\Rhino WIP - deleted
echo Done!
pause
Hi @brian ,
Just to revive this: I’d love to have an easy CLI command that can be run on my current Rhino version (while rhino is closed) and have it automatically update if needed. Like a silent version of what happens when you close the app.
Is this currently possible?
Good seeing you in Barcelona!
Mathias Sønderskov
Hi @sonderskovmathias, why do you want this? What does having a CLI command do for you that opening and closing Rhino does not?
It was good to see you, too!
I see lots of benefits in having a system in place that would automatically keep Rhino up-to-date. There can be hundreds of users most of which don’t work with Rhino on a regular basis. But if every now and then they use some tools or scripts developed internally, it would be nice to have their Rhino installations up-to-date without opening and closing and making sure they update first.
So anything that helps towards this, I concur.
Sorry if this is already known, but Rhino can already run, Rhino commands from the OS command line shell, e.g.
"C:\Program Files\Rhino 7\System\Rhino.exe" /nosplash /runscript="_OptionsPage UpdatesAndStatistics _enterend"
So if Rhino doesn’t already automatically install an automatically downloaded update when run in this way (and if there isn’t another way already, e.g. using RhinoPython or RhinoScript - I couldn’t find one with a brief search) then it only requires update installation to be triggerable by a new Rhino Command, not a CLI.
So we’re doing a lot of effort to update our inhouse scripts and plugins. Some of the plugins are only visible in yak if you have an updated rhino since they were compiled towards version xxx.
I’m setting up a few automated workflows for updating rhino and running a few yak commands every let’s say 2 months. If rhino installation exe was always available at the same url without login, I could automate a download and silent install, alternatively if I could force trigger the already built-in feature via CLI that would be easy to setup.
So yes, I think a lot of larger firms with IT departments in charge of installations and updates could benefit from this. Ideally something that also didn’t require administrator login ;-).
Most of the large firms I work with use SCCM to deploy Rhino in their enterprise. They push deployments when users login, or at scheduled times. Because the domain admin is pushing the installation, local admin passwords aren’t required.
Have you looked into existing deployment solutions for your company? This is a common problem that has had many solutions for decades.
Most IT people at big companies don’t want software auto-updating, because workstations get out of sync and people can find themselves with incompatible software installed.
But this isn’t really the problem you’re trying to solve - I assume you have a relatively small team and you want full automation - but you still don’t want users to have admin rights on their computers?
I’m trying to prepare a package for our IT people including a way to update Rhino, packagemanager, etc.
The whole SCCM thing is new to be (not being an IT guy at all).
Which method would you propose if I(our out IT) were to push a Rhino update to everyone in the company?
The solution I see is, IT will have to create a rhino user, download the newest exe installation and then push it to everyone, every time there’s an update? That’s not an easy solution imo.
There are two pieces to this puzzle. One, which seems to be your primary concern, is actually getting the installer.
The second is pushing the installer to users. SCCM (and many other tools, which I encourage you to explore, rather than inventing your own) can work for that. The reason I recommend doing the deployment using a deployment tool rather than a script is for error handling. Installation always seems easy, and it is, when things go well. But believe me when I say things don’t always go well.
Rhino can fail to install; fail to uninstall; may require a reboot after installation to finish replacing files. Sometimes something bizzare is wrong with permissions on the system. Is your script logging the installation so that you can revisit the problems when things do go wrong? How do you know that something did go wrong? Do you have a system for auditing your network to ensure that everyone is actually running the correct version (if, in fact, that’s important to you).
All I’m saying is that what you describe feels easy to start… but I predict it will be marginally effective, and time consuming to debug when you roll your own.
Now back to the first problem - getting the update. We currently don’t have an easy way to get the installer without logging in. We had one for a while, but it broke with a recent update.
Thanks for the reply. I agree a lot with you and share your concerns.
But how would anyone be able to do any automatic implementation systems with or without logging/debugging etc if there’s no way to get the actual installer automatically?
That’s why I would suggest a local callable updater/installer that didn’t need a rhino acc on the website in the first place.
I mean if you have rhino installed you most likely have a username.
That installer could be explicit, could have flags for silent mode. Or pipe errors to an external file. And any of the other features some IT guy would prefer in his deployment system.
The reason we don’t have a tool for this is for all the reasons I described - there is probably 100x more error handling code for failed installation than for when it works.
I understand that starting and closing Rhino isn’t automatic, but aside from the user needing to click “install now” it does everything you’re asking.
Finding the installer download from your code is certainly possible; I’ll add a YouTrack issue to make it more obvious for you.
If you click Install Now, you will need administrator rights, which is not friendly for employees to automatically get software updates, so you want to update RHINO without getting administrator rights
That part is clear. What I don’t understand is why, in a corporate environment, you’d want to set up a system which just automatically finds and downloads the latest version from McNeel and force-installs it.
Don’t most corporate environments which auto-install do at least some basic install checks and cross-compatibility tests before force-installing everything for all of their users and then run installs from an internally hosted install package?
I agree Nathan, but let me clarify:
A group of expert users test a version for lets say a week or month. Then they call IT and ask them to force install for everyone, as perhaps inhouse development or external plugins depend on the newest version.
The IT system should not blindly force install for everyone 2 seconds after a release, but we need the ability to force-install.
Yes, my comment was based on the inclusion of the detect-new-version-do-install step in previous comments of this thread.
I agree that this is a very important feature for business clients with either of the following situations:
While I sympathize with Brian’s comments about the difficulty of handling errors reasonably in a headless install, I can easily see the lack of this feature being a serious obstacle for a Rhino advocate trying to get it adopted in a team within a large org that has formal IT+security groups.
Large formal IT+security groups have never requested this feature. They want full, manual control of every step of the process. Their job security relies on having helpless users that must request their assistance, and doing processes by hand increase job security. They don’t like walking around to install on each user’s computer, so they’re happy to offload that deployment to something like SCCM. But if I get close to automating their jobs, they get grumpy.