I have encountered System.IO.FileLoadException from these packages. I needed to report and I am choosing this post as the medium. Please pardon me for not knowing where to post these issues.
and so on. There are about 10 issues that happen every time I load Dynamo. Is there a way to resolve this? I mean without uninstalling these packages.
So the archi-lab.net is not that big of a deal. It’s telling you that you loaded a package that was built against Revit 2021 but you opened it in Revit 2020 or earlier. Whatever API is available in the current version you are in, will be used. Some functionality if it was only available in 2021 would not be available, but everything else will work fine. Revit doesn’t make that many changes between versions so 99% of that stuff is good to go.
The other StructuralDesign package has the same issue.
cc @Michael_Kirschner2 it would be nice to be able to dismiss them, or provide a clear set of instructions for developers on how to manage multiple versions of Revit API via a single package. I tried resolving this via DynamoExtension and ViewExtension, but it caused more issues. Thoughts?
I have been desperately trying to figure out a way to prevent these warnings as well. I receive a message just about every week asking what those warnings mean for Rhythm and Monocle.
The teams original guidance was to build a different version of your package and publish on the package manager for every Revit release.
Right now, I am thinking about wrapping DLLs for Revit versions in the bin folder and invoking those commands from another DLL that has no direct reliance on the Revit API (or any other DLLs really).
We have just put a Spike task into Jira that will look into this exact problem - we’ll try our best to figure out a good solution on how to either suppress or improve upon the warning messages.
If you have any thoughts on the kind of end-state that is preferable from a package authorship perspective please let us know @john_pierson @Konrad_K_Sobon.
@solamour from a developer’s point of view, logging these conflict messages to a console in Dynamo is just enough. There is no need to flash them at users all the time. Most users never looks at the console, nor do they know that it exists. Developers should be familiar with it.
From a user end point of view, unless there is a critical issue where a package failed to load because there was a conflict, there is no reason to print them up on the ribbon, and keep them up there for every session.
So in summary, keep these messages in the console for developers, only show them on the ribbon if they are CRITICAL and caused actual failures in package loading process, but remove all other warnings.
In regard to development process, a sample Dynamo Revit Package where multiple versions of Revit are supported, and no conflict messages appear at load time, would be awesome. Please post one to GitHub, and I will be happy to implement these changes into archi-lab.net. cc: @john_pierson
Add another one to the list of , “I would like to fix this to stop having people panic”.
We are gettin’ real close to it being easier/very desirable to not even maintain a Dynamo package…
side note: I honestly think it would be nice to ignore RevitAPI dlls right here, this would probably remedy 90% of those exception errors. If the package author uses newer API methods in the Revit API, leave it up to them to surface that to the user.
@john_pierson and @Konrad_K_Sobon We have filed a task and will be looking at this in the next sprint or two 
HECK.YES.
I look forward to everyone having this update in Revit in 2 years. 
But in all honesty, awesome stuff team!
Doing what we can man 
Sadly there is a delay on all content due to the nature of software, but such is life!
