I would say this is a different query as I am not asking for help/support in Dynamo. I am just asking for advice to the experts on the best way of debugging + deploying a long and heavy Dynamo script based on their experience.
You´ll probably know that when you deploy a Dynamo script in a company for everyone, it is very easy that people might come up with errors when running the scrips because of the data formatting within an Excel file, how they set the inputs, and so on…
My question is, how would you debug + deploy a huge Dynamo script where an issue can appear in many different parts of the script when running through Dynamo player? so anyone can be aware of the mistake he made.
TaskDialog?
CTypes?
Try/Except with Python and setting output text messages?
Build your stuff using reliable code with error handling.
Test in every environment you’re deploying (Revit version, Revit add-ins, Package library)
Simplify environments to all data on the local disc instead of networks (Dynamo graphs are code, and running code off a network is a bad idea).
Deploy separately for each environment - no Revit 2023 and 2022 shouldn’t have the same package directory.
Users who just want to push play should leverage Dynamo Player exclusively; organize the library and provide properties and help documentation for them that works in this context.
Clear input names with notes for detailed instructions.
Provide a watch node consisting of any unexpected results at key points, and an indication of where that is.
Provide a watch node for major results.
Don’t build graphs which do everything at once; let the users run things in sequence instead.
Build your graphs off your office standard, and inform users “if you deviate it won’t work, so get onboard with the rest of the team.”
Keep in mind your code will be more stable the more standardized it is. It’s better to have stricter requirements that work than to be flexible and have to deal with error reports. Standards and explicit requirements will also make documentation and training much easier. If you can define all your requirements in the documentation then you shouldn’t have to deal with troubleshooting those errors. (They’re still going to happen, but that becomes a user error rather than a tool error.) Be as proactive as possible so that you have fewer instances of troubleshooting to begin with.