AppDomains allow you load/unload assemblies at will. The .NET runtime tends to exhibit some odd/unpredictable behaviour as you load assemblies with the same name, especially if they don't have strong names. You can end up with types no longer resolving as expected. By loading assemblies in the separate AppDomain, you side-step all of these issues.
Ivan Tarasov wrote:
Hello Matthew,
oh, it's quite an ugly way. I was considering this but I rejected Hashtable because it smells like it is a hack :)
Could you please explain the need of separate AppDomain? Is it because of some sequrity reason (loaded assembly can execute some nant internal code or its own code with nant's privelegies)?
MM> System.Collections.Hashtable is your friend here. :)
MM> Sounds good - just make sure you use a separate AppDomain while checking
MM> for assembly references. I would also recommend caching lists of MM> dependent assemblies based on filename to save time.
why do I need separate AppDomain?
I wanted to do some caching (I needed something like "std::set" in
C++), but I couldn't find something similar in framework, I'd
apreciate if you point me the right way to do it
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
