@mike.olearyZ8X6J wrote:I don't know what do you mean by hot reload.Introducing the .NET Hot Reload experience for editing code at runtime - .NET Blog
By hot reload I am referring to the ability to make changes to code when debugging and have them immediately apply, this is much more preferable than unloading and reloading dlls. I posted an issue on IL-Repack github with a simple console app in which hot reload fails to work once packed. Because these developers are just starting out (background is drafting), I feel that hot reload functionality is a must have.
Never manage to make the Hot Reload to work well inside Revit, I use the unloading and reloading dll approach using my AppLoader plugin. I only use IL-Repack when releasing the package/plugin, for developing is kinda overkill, and depending of the project IL-Repack take some time to finish.
@mike.olearyZ8X6J wrote:Oh also I saw a video you posted on youtube with an AssemblyLoadContext example. Just FYI it wasn't quite right, in your example you shouldn't be loading many contexts for accessing commands which resulted in odd behaviour like static variables not maintaining state. The code I wrote to do this loading all types upfront in the same context, so all commands etc that were resolved are in the same context. It meant that a single context was created on app startup. Imo I still way more prefer this than ILRepack as ILRepack won't always place nice depending on how you set it up. If you pack the whole addin I don't think there will be any issues, but if you pack say a core library to be consumed by the addin project you do need to be careful with framework references and matching versions of these, otherwise the framework reference may get pack in the core library and won't match the type in the addin library.
I don't know what video you saw, but I pretty sure I create a single AssemblyLoadContext for the plugin. And all the IExternalCommand need to find this AssemblyLoadContext to execute the command inside that context to use the same dll reference.
I prefer IL-Repack that does not introduce any code complexity inside the plugin, especially because I can apply IL-Repack in a nuget package (.nupkg) to remove the third party dependencies and make a single dll to work inside Revit, and as a .nupkg the compiler only gonna allow the correct target framework.
And eventually Autodesk will release some kind of isolation, probably using AssemblyLoadContext natively inside Revit loading addin process. I would not bother to use AssemblyLoadContext inside a Revit addin if IL-Repack in most case works.