I am having the same issue as well. Mapping the networked shared package path worked in the past for users in our firm, but has stopped working (it crashes Revit+Dynamo 2018.3 when I add the path).
It is a feature that I love because anyone can create a script using non OOTB packages. Its really simple to tell users to make sure that they map this one shared location and then if any new packages are added, it automatically works (and we don’t have to get IT involved). Its a simple and streamlined process.This is even more useful when you think of less technical people using Dynamo Player.
It seems people have had success using workarounds by having IT push/robocopy packages to everyone, but that is a time intensive and not super flexible solution (If we add/update a package, IT would need to know to push out an update).
Is there any information I can share to help troubleshoot this issue?
Try removing all packages from the path - make I so there is nothing to load at all - and see if the issue persists.
If not, start adding a few back at a time, until you get the crash. Idea is to narrow down if it’s a particular package, any package, or the network path in general.
I tried to do that, that’s when I though I narrowed it down to the Bakery and Archi-Lab packages. But then Revit was crashing again, no matter what packages were installed. It all works fine if the packages are installed on a local drive.
Note - the app data folder is empty when trying with the packages in a network location.
@monica.greco
can you check what was the latest date the packages you have were updated, i once had a problem where i had a package that was very old in my package folder on the network.
I tested with all the latest versions of the packages
@monica.greco
the latest version of a package can be a 0.7 version
As the problem came back, I removed the packages from the network path one by one, as suggested by @jacob.small .
I managed to identify 4 packages causing a crash of revit.
Oddly, when I isolate these packages in a different folder (a shared one), and specify this folder path, it works.
I ran my tests on revit 2018.3 and dynamo 2.0.0.4655.
At this point, all I can guess is that there’s some kind of conflict between packages or that there’s an issue with the package manager.
Any thoughts on the origin of this behaviour ?
What packages are causing the issue?
Also can you confirm there are no packages on the default C drive location.
See the below picture for the packages I identified and their version.
I checked the default C drive location and there’s nothing in the 2.0 folder.
1 Like
Ok one more ask - can you get a list of packages which work? I may have narrowed it down some.
Also, what type of server are you running? Any odd cloud services involved?
Here the ones without any issue on my side.
We are not running on a cloud based service, it’s the company server managed by our internal IT Department.
Indeed, I didn’t think about an issue coming from the server. I will try a different location.
3 Likes
I know this question is already long ‘solved’ but I thought I’d share some insight about why Dynamo doesn’t play nicely with network shares.
In more recent versions of the .NET framework (on which the Revit API and addins are built) there is a new policy restriction whereby DLLs cannot be loaded from network locations. There is no option to ‘unblock’ the DLLs either (which in past versions that could be the cause but not any more).
When debugging Dynamo / Revit loading from a network path I see an exception message along the following lines:
An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.
So it’s no wonder that some packages fail while others work fine from a network share. Furthermore, if the machine happens to have the same DLL in it’s .NET cache, then the DLL will load successfully. This may explain why it works for some users and not others. It’s also possible that the version of .NET the DLL is built against determines whether this policy is applied.
We’ve ended up using the same solution mentioned earlier: having local copies for every user / machine. Only difference is that I’ve automated it so that they update asynchronously on Revit startup. This is because we were concerned about login startup times (with ~300mb of packages files!) The packages are zipped, downloaded and then unzipped to a new folder and then the new package path added to the Dynamo settings file(s) and the previous one removed.
Some testing revealed that Dynamo will only load the version of each package that it finds first, in the order that the custom package paths appear in the settings file. This behavior is handy because this means we can control whether or not user’s own package updates override the ‘standard’ deployment by switching the order of custom package paths.
Hope this info helps.
4 Likes
That sounds about right - but I believe you can also fully trust the network site and .net will then load the dlls:
you can change these via IE internet options - if the options are not available an admin may be able to change them.
Thank you for sharing this information. Indeed it explains a lot.
I’ll test and see if the solution exposed by @Michael_Kirschner2 works for us.