@kike I’m getting inconsistent results launching RiR v1.12 programmatically with R2022 + R2023, where an license not obtained exception is thrown.
Context:
A Revit addin written in C#.
The app has dependencies on RhinoCommon and requires RiR to access the API.
Hence, RiR must be running for the app to work.
I’m using the Rhino.Inside v7.0 NuGet and calling Resolver.Initialize() method to launch programmatically. This was working fine, but broke when it failed to acquire a license. I tried logging out of my Rhino account and Revit, acquiring a new license (from manual login) but to no avail.
The problem seemed to trigger after using a second laptop, almost like the license is machine locked to the first caller to Resolver.Initialize(). Nothing I do will acquires the license on a different laptop, even though we have ample licenses and RiR launches fine on both machines when done manually (if I launch RiR manually, the app works so its not something obvious, i.e. is the other laptop logged in with a checked out license - the answer is yes). Are you aware of any limitations or the cause of this problem?
Worth mentioning I’ve not checked the license on the first laptop back in, but do I really need to do this?
Rhino.Inside Nuget package is meant to be used when you are doing a new Rhino.Inside implementation.
Since Revit has it’s own Rhino.Inside implementation you don’t need to manage all those issues as long as Rhino.Inside Revit is installed.
The first call you make to RhinoCommon will grab a license and start Rhino for you.
If you start RhinoCommon by yourself like you are describing the user will not be able to use Rhino.Inside Revit on the same Revit instance. So I highly discourage you of doing it.
Thanks for the reply - if I simply let the Revit app run, the first call throws an exception as RiR / RhinoCommon isn’t loaded. Even if I take the sledgehammer approach and distribute RhinoCommon with our app an exception is thrown (but at a different location in our app - see snippet below).
Can you explain the implementation details (we’re still having to use the PostableCommand approach which is pretty horrendous for the end-user)? Our app is async and we force startup in a new STA thread, so not sure if that might make any difference?
Unable to load DLL 'rhcommon_c': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at UnsafeNativeMethods.ON_Brep_New(IntPtr pOther)
at Rhino.Geometry.Brep..ctor()
Revit loads AddIns in the alphabetical order of the .addin files.
So Bimorph.addin is loaded before RhinoInside.Revit.addin.
This means we have Bimorph.OnStartUp called before RhinoInside.OnStartUp. During this time RiR is not initialized and can not solve RhinoCommon for you.
But there is an event on Autodesk.Revit.ApplicationServices.ControlledApplication called ApplicationInitialized.
This signals when Revit and the AddIns are fully load.
After you receive this event you should be able to call RhinoCommon.
Thanks @kike but that isn’t the issue here; Revit is fully initialized. We have an RVT project file open and simply click our app button to launch the add-in (we need the RVT file open for our app to run) with the expectation that the first call to RhinoCommon will initialize it, but it doesn’t, we just see the exceptions posted above?
Edit: When I mentioned ‘forcing startup in a new STA thread’, I meant to say when the app is launched each time the user clicks the app button in the ribbon, not in the IExternalApplication.OnStartup(), i.e. the Revit app is fully initialized and any third-party apps are already registered.
That runs with a but: you’ll see the same exception we’re seeing if you instantiate a Brep (see below). I discovered rhcommon_c is a dll in the root install of Rhino, so I tried copying that to our app install location to try and resolve the issue but it doesn’t work, I’m guessing because it has dependencies on other Rhino dlls. What else can we try? What is rhcommon_c?
Also, isn’t distributing RhinoCommon or any RiR assemblies going to conflict with RiR if the user was to run it manually after running our app?
I made a change in v1.14 that will be in 1.13 next Tuesday.
This works on my side now.
Please test with the 1.14 available and tell me.
You should not distribute any McNeel assembly but require the user to install Rhino and RhinoInside.Revit. I was asking about CopyLocal to be sure that is set to False in your project.
And thanks for reaffirming the point I was making re distribution of host application dll’s - we never deploy them with our apps for obvious reasons, which is why I wanted to question if this really was part of the solution for programmatic launching of RiR!
