Re[2]: [nant-dev] Re: project references problems in <solution> task

[Ivan T. <it...@st...>]

Hello Matthew,

I've implemented the proof-of-concept program, which creates AppDomain
and loads assemblies there, but I'm not sure if it works around the
problem you've described. Probably it would be good to set up some
security policy for the newly-created AppDomain, so that the loaded
assembly couldn't do any harm (AFAIR, static constructors are called
when assembly is being loaded). Also, in MSDN there is a clause that
it may take quite a time to Unload the AppDomain. An alternative way
is to call Abort on all threads of this domain which is a bit harsh.
I'm not sure which way to go, please tell your opinion if you find
some way to be the preferable one.

Program source is attached, it just prints the names of referenced
assemblies.
I'm also going to do some speedup by using Hashtable, so don't take
the current ArrayList implementation into account.

It would be great if somebody commented upon that code (style/bad
practices/etc.), so that I could change it now.

MM> AppDomains allow you load/unload assemblies at will.  The .NET runtime
MM> tends to exhibit some odd/unpredictable behaviour as you load assemblies 
MM> with the same name, especially if they don't have strong names.  You can 
MM> end up with types no longer resolving as expected.  By loading 
MM> assemblies in the separate AppDomain, you side-step all of these issues.

-- 
Best regards,
 Ivan                            mailto:it...@st...