Is there any update as to the repair of “libraryViewExtension.xml”? Removing it is the only way to get scripts NOT to crash Dynamo and Revit outright. Needless to say, the removal of this file makes Dynamo much more difficult to use.
Thanks,
Scott
1 Like
@srosenbloomNKA, to confirm, you’re only having this issue with Revit 2019.2, correct?
Nope, still on 2019.1, but running Dynamo 2.0.2.
That’s the same setup as me and I’m not having any issues… what is the error in the console when you leave it in place?
Is this the issue when loading a lot of packages all at once?
From my experience, it is definitely related to the size of the graph you’re trying to load (but this could be correlation and not causation). Once you go beyond a certain number of nodes in the graph itself, it instantly crashes. Opening a new graph or a small one prior to a graph that crashes, so that all the custom definitions get pre-loaded, doesn’t help at all.
This is also happening only under Revit. If you open a graph that crashes under sandbox, it loads just fine, albeit with all the Revit related nodes being left unrecognized as expected.
On a related note, when you try to debug the library view extension in chrome at the specified port, it works fine when launched from within dynamo sandbox, but fails to connect when started under Revit.
Heres an update:
- This is a bug in the library or a technology used by the library which causes a race condition where a collection is modified while packages are being loaded - causing the collection to be modified again.
- We have a fix in the 2.1 branch and master branch of dynamo. This fix - stops the crash, but the fix does not address the underlying cause.
- Even after lengthy investigation the underlying cause of the collection modification was not determined.
- We can reproduce this issue with a small number of packages (which contain lots of nodes) using Sandbox - of course it’s easier to reproduce in revit where more packages will load with more nodes. It also appears to be related to custom nodes in packages - not zt nodes.
1 Like
@Michael_Kirschner2 to clarify, zt nodes do not cause the issue but .dyf files do?
that is the hypothesis now - I think that issues like @Dimitar_Venkov is seeing might be because when dynamo loads a graph in the same directory as a bunch of .dyfs it also loads the .dyfs in that folder. I might try loading the .dyn from some other folder as a test.
1 Like