Thanks for the reply @awilliams.
I would first look to see if you have two versions of Dynamo installed based on the solution of this thread here: How to fix Dynamo Notifications about System.IO.FileLoadException?
The two test machines in question are confirmed to only have one version of Dynamo Core and Dynamo Revit installed, so that unfortunately doesn’t resolve the issue.
If the potential solution I provided doesn’t solve the System.IO.FileLoadException errors, and you really want to keep the DynoBrowser package, maybe you could utilize this code from @Andreas_Dieckmann to find out which nodes within DynoBrowser are dependent on Prorubim Nodes: Package dependency and from there you could either edit the .dyfs to replace the Prorubim nodes with a different workflow that achieves the same thing, or delete those .dyfs from the DynoBrowser package folder itself.
In this case, the DynoBrowser itself isn’t a package, but an add-in that provides a similar function as the Dynamo Player. We have several projects that are long-duration and will be locked into Revit 2016 for their duration. We also have two dozen in-house users that are end-users, not coders. We build our Dynamo scripts for most tasks to function with minimal user input and the “double-click to run” interface we get from this browser (and subsequently the Dynamo player if its functionality truly compares - we have not really tested it much) is perfect for this group of users.
In either case, I’m not really sure what to do with the output of this particular script, the issue I am having is with a package loading (which I haven’t chosen to download or use any nodes from) that is claiming dependency issues. The output from the script, if I do place this node in a standalone dyf file, lists a pile of parents and children, but doesn’t really help me find the source of these errors…at least not from my limited experience dealing with these issues.
Thank you @Aleksey_Lobanov as well for your reply.
Dyno installs package called “Prorubim Dyno” and its part of Dyno (Its not placed in online package repository). It contains one node “ShowDialog” for showing user custom UI.
Yes, I can see that this package is installed into my “Program Files” directory and is persistently linked, via Dyno I assume, to my installed packages (i.e. I cannot remove the path to it from my Dynamo installation without forcefully deleting the actual package directory). Up through version 0.6.2, this did not occur. I guess more than anything, I’m caught off-guard at having to suddenly chase dependency issues in one program caused by the installation of a (somewhat) unrelated add-in that I’ve not had this issue with in all prior releases. And not having documentation that is really current to have something tell me that I will be seeing a new package suddenly show up with this latest version only adds to that frustration.
Many native packages use Revit and Dynamo dlls. So package dll try to load Dynamo dll with some build number (this dll with this build number was be used by developer). If Dynamo or Revit use same dll with different build number then package will use it too. There is no problem.
So i don`t know why Dynamo shows these messages as warnings because obviously, no one will make packages for all possible combinations of revit and dynamo versions
For example you could install Bimorph package and in the revit 2017 Dynamo will show warning about it (Bimorph uses RevitAPI.dll v2018).
If I am to understand this correctly, are you saying that the dependency issues I am seeing related to this particular package “Prorubim Nodes” can simply be ignored and everything will work just fine? If that’s the case great…except I still have to deal with people asking about the errors. For what it’s worth, the exact same errors are showing in Revit 2016, 2017, and 2018 for us (all using the exact same version of Dynamo).
For a little more background - We are a self-perform trade construction contractor. We have approx 20 detailers that are all “users” - not coders or “tinkerers”. Their work duties are to create and coordinate LOD400 models to support our MEP fabrication and installation, not to theorize and understand the inner workings of creating code and scripting. We have two administrators that handle the development and creation of scripts (among many other duties), as well as the installation and maintenance of software across all machines, projects and versions of Revit. I often use the analogy that our detailers are race-car drivers…they are paid to drive fast (but accurate) and win races. They don’t need to know (or usually care) how exactly the car works - only that it works the way they expect it to when they perform an input. The administrators are our pit crew - they don’t need to know how to race the car - only that they make sure the car is ready to perform exactly how the driver needs it to.
To do the best we can to assist with support and troubleshooting, we want to make sure everyone is using the same set of tools in the same ways. To achieve that, we deploy packages and settings for many things (Dynamo included) using a variety of deployment installations, force-pushed xml files (overwriting anything that may live locally), and common package locations. When things like this pop up, it makes our entire process of trying to keep things current very difficult, because we aren’t potentially affecting one person, but instead the production and output of out entire group (which directly impacts the entire company).
Package dependencies seem to be one of the biggest headaches for us in the whole Dynamo process - especially while trying to support multiple versions of Revit and maintain current STABLE releases of Dynamo. Between the apparent reliance on the “order of installation” and the possibility of an updated version of one package breaking the entire structure elsewhere, it is frustrating to try to keep straight. It seems to me the entire process could somehow be streamlined - but I’m probably the least qualified person to suggest how.
Sorry for the sideline rant on this post…I’ll push forward with ignoring this dependency error for the time being and see if anything breaks. If it does, I guess we’ll investigate (and report back). If nothing breaks, then we’ll deal with the warnings and continue.
I haven’t found it problematic or cause for issue in any case. It just means that within the custom nodes, there are custom nodes from other packages within them. This shouldn’t be a cause of distress - it just means the package creater felt they didn’t need to reproduce a workflow that already existed efficiently (just my opinion).