A short explanation of why I want to do this:
I am busy writing a plugin for Autodesk Revit Architecture 2010. Testing my plugin code is extremly cumbersome, as I have to restart Autodesk for each debug session, manually load a Revit project, click on the Add-Ins tab and then start my plugin. This is just taking too long.
I have written a second plugin that hosts an IronPython interpreter. This way, I can play around with the API provided by Revit. But eventually, the code has to be rewritten in C# - and debugged.
Easy, I thought: Just load the plugins DLL from the IronPython script and exercise it. This does work, but once loaded, I cannot recompile in Visual Studio, as the DLL is now loaded in Revits AppDomain.
Easy, I thought (with a little help from StackOverflow): Just load the DLL in a new AppDomain. Alas, the RevitAPI objects can't be marshaled to another AppDomain, as they don't extend MarshalByRefObject
.
I think I might be onto something with shadow copies. ASP.NET seems to be doing this. But reading the documentation on MSDN, it seems I can only specify this when creating an AppDomain.
Can I change this for the current (default) AppDomain? Can I force it to use shadow copies of DLLs from a specific directory?
I don't know what you are trying to do but there are some deprecated methods to turn on ShadowCopy on the current AppDomain.
There is now a Revit plugin for dynamically loading/unloading other Revit plugins so that you can change, recompile, and test without having to reopen the Revit Project. I found it on the Building Coder blog. It comes with the Revit SDK.
Sometimes it's not possible to modify the Main() method code because, for example, you're writing a plug-in and it's instantiated by a manager.
In that case i suggest you copy the assembly and pdb (and dependent ones in AssemblyResolve event) to a temp location and load them from there with Assembly.LoadFile() (not LoadFrom()).
Pros: - no dll locking. - every time the target assembly is recompiled you get access to the new version (that's why .LoadFile()). - the whole assembly is fully available in AppDomain.CurrentDomain.
Cons: - file copying is necessary. - assemblys can't be unloaded and that could be inconvenient because resources are no freed.
Regards,
PD: This code does the work.