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
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
@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:
@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.