Notifications System.IO.FileLoadException

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?

2 Likes

Hi Konrad, Mike’s on sabbatical right now :slight_smile: But @Aparajit_Pratap or @Qilong_Tang may have 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.

:roll_eyes:

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.

1 Like

@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

3 Likes

Awesome, thanks @Konrad_K_Sobon. I have added your comments to the task :slight_smile: