I have just installed Dynamo 2.0 on my workstation - one that currently runs Revit 2016, 2017 & 2018.
When opening Dynamo 2.0, I get 5 very similar warnings, each identifying a different CefSharp component:
While loading assembly CefSharp.Wpf, Version=57.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138, Dynamo detected that the dependency CefSharp.Core, Version=57.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138 was already loaded with an incompatiable version. It is likely that another Revit Addin has loaded this assembly, please try uninstalling other Addins, and starting Dynamo again. Dynamo may be unstable in this state.
It is likely one of the following assemblies loaded the incompatible version:
RevitPlugin, BusinessLogic, BusinessLogic, BusinessLogic, CefSharp.Core, Revit2017, Revit2017, CefSharp.WinForms, CefSharp.WinForms
It does open but I donāt have access to the library to the left hand side (itās there but empty).
CefSharp and BusinessLogic come with the NBS plugin (a UK specification tool). Uninstalling that plugin does work but itās not something I can do - itās required for use on live projects.
Just flagging here as there is a solution ā¦ just not one I can implement.
Plugins utilizing libraries which conflict with updated versions of AutoDesk products is a common issue. Please contact the plugin manufacturer and let them know that it is broken and needs an update.
Iām not sure ābrokenā is the right term for the NBS Plugin in the sense that it still operates itself with its own library. Nonetheless, I think I understand what you mean and Iāll certainly report the conflict to them.
@jacob.small donāt you think itās an āAutodeskā issue, not EVERY person/company that ever wrote a plugin for Revit? Autodesk allowing 3rd party plug-ins should consider the possibility that there might be more than one plug-in out there that will use the same library, and it just might happen that they might use different versions of it. They should consider methods for isolating the scopes of these 3rd party applications, rather than forcing tens, or hundreds of developers to all of a sudden magically coordinate between each other, Autodesk should provide mechanism for Revit to manage these scopes automatically. Telling people that their plug-in is the issue is the kind of cop out move that one can expect from Autodesk, but please at least donāt try to make people falsely believe that itās their fault.
there are indeed technologies in .net for this type of isolation. The overhead is large for both the host and the addin developer (usually) Though In the case of cefSharp it has unmanaged dependencies that no .net system will help isolate.
I do not know of a mechanism to avoid conflicts between various versions of unmanaged cefSharp dependencies besides loading this type of dependency in a separate process.
also note that revit started bundling cefSharp as a shared component for this reason so various addin developers can count on it being present and use that version.
So it seems that, unless/until NBS re-issue their Plugin using newer versions of these libraries, Iāll continue to experience this conflict?
As a hacky solution ā¦ do you think itās possible that dragging the CefSharp dll files from the Dynamo\Dynamo Core\2 folder into the location the NBS plugin uses would resolve the issue? I prefer not to mess around with this but I also canāt do without the Plugin.
(Needless to say, Iām not asking you to tell me there definitely wonāt be a problem, only if you know that there definitely will be ā¦)
@Konrad_K_Sobon I do agree that itās an āAutodeskā issue in the larger context that itās a problem for our customers and therefor us. However, the short term the fix will have to come from the plugin developer. This is a fact of life for anyone who builds on top of existing software. Itās even worse for people who have to deal with importing and the like.
For the unaware, a library of functions can be open in one version (see Avalon edit issues circa 2017 launch). Autodesk (and the specifically the Dynamo team) does a better job than most at informing add in developers to coming changes via the Beta program, ADN and the GitHub. And while we really do our best to try and communicate these types of issues, sometimes things get missed. This is a fact of life on any type of project(otherwise there would never be an RFI or change order on a construction project).
This is why I advised @des.hourihane to pass this issue onto the plug-in developer, itās the fastest way to resolution (and will likely be required for the plugin to work long term).
@des.hourihane, can you temporarily disable the plugin to utilize Dynamo scripts in short bursts, or will that never be an option here? Admittedly Iām unaware of what itās intended use is and why it would need to run constantly.
Sure, but at the same time they are forcing everyone to use the bundled version of the library, risk conflicts, or manage assembly conflicts ourselves. Since Revit comes out with an update like twice a year, sometimes 3 times, while the libraries might be getting updates on daily basis. I have seen Xceed library that comes with Revit and itās from 2013.
I will make a wager with you, that itās not been updated for 2019 release. Xceed has moved quite a bit beyond this version since.
I have no idea what it would take to fix this, but at the same time, it would be nice if Autodesk came out and said, yes, this is an issue, we looked into it, it can/cannot be done for this/that reason. Instead people just push the blame onto 3rd party developers.
Iām not sure. At the same time, I donāt believe the Plugin can be ādisabledā short of uninstalling it ā¦ which is hassle to say the least. Is there another way to individually disable Plugins that I should be aware of?
@Konrad_K_Sobon - totally not trying to āblameā the 3rd party here. Broken was clearly a poor choice of words - āinforming them of the library conflictā would have been more accurate.
I believe this can be done by editing your .ini file (which can be automated with Dynamo by launching either Core or Studio). Let me look into the ramifications of this on this end and get back to you.
Itās actually as simple as moving or renaming the .addin file itself. I can give better directions later tonight (I have a few calls I have to be in).
I am aware that removing the Addin solves the problem. At the same time, itās not a very satisfactory solution given that the offending Addin is the NBS Create Plugin. Iāve notified NBS and Iāve had a certain amount of discussion with Jacob outside of the forum in an effort to get a solution that allows me to continue using both.
Not sure there is a āworkaroundā yet. Jacob has suggested a bat file or script that will rename the dll in the NBS package thatās causing the problem. Heās trialled running a Dynamo script outside Revit to disable another Addin. Itās really just automating a renaming/deleting process and I think still requires the user to repair the fix before they engage the NBS Plugin. Not ideal to say the least.
For the time being, my own NBS work is on a 2016 project - where I couldnāt use 2.0 in any case so the conflict doesnāt arise. It has stopped me experimenting with 2.0 elsewhere which is frustrating.
May I suggest you use the NBS Plugin feedback button to send a comment about this yourself? I donāt think itāll do any harm to have them aware that numerous users consider this to be an issue.
