views:

455

answers:

1

I have an app that uses some code scripts to generate dll's at run-time and invoke them as needed and have run into some questions before i go ahead and code it !

Is it possible to unload them from memory when not needed ? If not - what would be the performance impact of loading them into separate appdomains and invoking the calls using some ipc etc. - btw, this needs to be highly performant/real-time

Alternatively, how about loading multiple instances of the generated assembly ( with different version #'s of course ) ? I'd assume if you release all references not being used, it might be unloaded by the gc/framework ?

Also a Q - would there be any "collisions" ( not sure if this is the right word ? ) in this scenario ?

+4  A: 

Assemblies can only be unloaded with the entire AppDomain. Depending on how many of the dynamic assemblies you need to load, it may be OK to load them in the default AppDomain and let them stay in memory until the application is closed. However, if you think you will have too many and the memory consumption will become a problem, you will need to load them in a separate AppDomain, use AppDomain.DoCallBack to marshall calls accross AppDomain boundaries and unload the AppDomain periodically. For example, T4 host in Visual Studio loads compiled assemblies in a separate AppDomain for up to 25 code generation sessions and then unloads the AppDomain to recycle memory.

Performance impact of additional marshalling that needs to occur with a separate AppDomain will be insignificant compared to the impact of compiling and generating an assembly on the fly. It will only become an issue if the number of cross-domain calls is large. You will probably need to test performance of AppDomain.DoCallBack to determine if performance will be acceptable for your scenario.

Oleg Sych