Speckle for Revit plugin assembly/version conflicts

Hi Speckle,
We are working on a plugin for Revit that basically get the streams from speckle and change some data and post it back to Speckle. We use the NuGet packages Speckle.Core and Speckle.Objects to do that.
Because the Revit application can only load and use one assembly/version during its session we encounter clashes with the speckle Revit-addin itself. This is because the Speckle Revit Addin also loads these assemblies but with a slightly different version (especially after an update from Speckle). We need the user to be able to use our Addin and after that the Speckle-addin to receive the streams changes.

I was wondering if you know of a solution for that. One thing we thought of was if there would be additional NuGet packages for Speckle.Core/Speckle.Objects that have a different assembly name so they can’t conflict with the assemblies the Speckle Addin is using. Or have the Speckle-addin use differently named assemblies.




Hey @PhuongNguyen !

What you’re building sounds really cool, would love to learn more if you can share :slight_smile:

There are a few options on the top of my head:

  • the safest is to (as you suggest) load in your addin a renamed version of our dlls, you would also have to change the namespaces to make sure there are no conflicts (that’s what we did with Newtonsoft.Json). This would work if you are not planning on updating our refs often
  • I have also had mixed success in the past using an alias in VS
  • last option, if you know that the Revit connector will always be installed together with your addin, is to actually use its dependencies instead and to not bundle any Speckle dllin your addin.

Dependency management in .NET is a pain, but hopefully, you can find something that works!

Hi Matteo,

thank you for the quick reply.
About the first option, I didn’t know we had to change the namespaces as well. Wouldn’t that than mean that we will end up with different namespaces for speckle objects like “Objects.BuiltElements.Beam” => “OurAddin.Objects.BuiltElements.Beam” etc and that would mean serialization won’t be compatible with the streams created by the Speckle Addin because it depends on these type names?

Hey @PhuongNguyen, sorry for the late reply - missed your message!
I don’t think you need to modify to Objects namespace as the conflicts seems to come mostly from Speckle.Core, also Core, or any Connector don’t have any dependency on Objects, it gets dynamically loaded.

Hi Matteo,

I’m working on the same plugin as Phuong and I was trying to implement the first solution. Now I’m facing the issue that while I changed the namespaces and added my own, I’ve got another issue with the Speckle Objects reference which has a dependency on the SpeckleCore Base class, this one still needs the Speckle Core with the original namespace.

I’m wondering if you could see, from this information, if this is technically possible? Would it be working to also change the SpeckleObjects?

Hey @dirksliepenbeek , if you plugin has a direct reference to Objects then unfortunately yes - you’d need to apply the same changes there…

To be honest, this sounds like a lot of work! It might be easier trying to keep the versions of Core used by your plugin aligned with the version of Core in our connectors. If it helps, we’re considering reducing the frequency with which we release new versions of our connectors.

Hi @teocomi,

Apologies for getting back to you this late, but we are picking up this development again as the UI is now excluded (almost, but now more easy to just delete the DLL’s in the output folder). See this thread.

I’m using the latest nuget packages of the speckle core and speckle objects in my projects. It seems like the speckle objects are still the source of the conflict.

I’ve been testing our plugin together with the Speckle plugin extensively and I have a few findings:

When running our tool through the addinmanager the only situation which works is:

  1. Delete MaterialDesign.dll’s in Speckle output folder
  2. Replace object.dll + revit.converter2021.dll (version from the \AppData\Roaming\Speckle\Kits\Objects folder with our own object.dll + revit.converter2021.dll (version 2.5.2)
  3. Run Speckle first, receive objects from an existing stream
  4. Then run our own app and map / load families See post for workflow object types and update stream.
  5. New stream with mapped types can be received in Speckle plugin

Other then this one I found some situations which gave other issues:

  • While receiving objects, progress bar stops running (seems like objects are received), but no objects are received. Log says: “Skipped object of type System.String, not supported.” Same stream would not give any issues when restarting Revit without our plugin ran first.
  • Progress bar keeps on running for a long time (maybe even forever :stuck_out_tongue_winking_eye: ).

Also, these issues only occur when running our plugin through the AddInManger, if we would install it in the ribbon Speckle is not able to start. See screenshot of error:

I have created a debugging file which gives insights in the findings
debugging.xlsx (11.3 KB)

I’m curious if you/anyone else experiences similar issues and how to overcome this?

Thanks for reading it and hope to hear from you!

Cheers :smiley:

Alright, this issue is solved!

I had to reference the Objects.dll from \AppData\Roaming\Speckle\Kits\Objects in my own project and also needed to make sure that these files are not copied to my output folder.

Then there was still an issue because my plugin couldn’t find the right .dll if the Objects.dll was not loaded already by the Speckle Revit plugin. So then I used the Assembly.LoadFrom Method in my code to make sure it does the job.


Nice! Thanks for coming back with the solution!

We’ve bumped into this issue a couple times recently, so we’ll be writing a guide with some “best practices” when developing things with Speckle, to try and minimise this issues.

1 Like