----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Jackfan" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Saturday, September 04, 2004 4:40 PM
Subject: Re: <solution> task GacCache / AppDomain construction (was : Re: Re: Re: [nant-dev] Bugs)
Matthew : the problem is that we use one GacCache for the complete run of
the solution, so any assembly that is loaded will be locked for the entire
run. That's why I initially created a new gaccache wherever we needed one,
but you changed that for performance reasons ... I definitely have no
problem with that, however I think its more important to have a functional
<solution> task than to have slightly improved performance. There's
definitely more performance to gain by optimizing the resource compilation
(as mentioned in my email to the dev list a few days ago)
The big reason I changed it was that if all references are set correctly, loading DLLs via the GacCache should work fine. Since we build a reference before we use it, this shouldn't be a problem.
If I'm not mistaken, VS.NET won't let you build multiple projects to the same directory. It ends up keeping a lock on the referenced files, much as we do.
Ideally, I would like to rebuild the GacCache only if absolutely necessary. It would be nice to test to see if the reference is already up-to-date in the target directory and, if so, forget about the copying step altogether. If the file has to be copied and the GacCache has it locked, we could then tear down and recreate the GacCache. The teardown step would probably not happen that often, since the same references would be copied over and over to the target output directory.
I suppose an alternate method might be for us to enumerate the GAC assemblies via the appropriate Fusion API instead of doing a test load each time. Another method might be to recreate the GacCache each time, but copy the HashTable that determines whether the assembly is in the cache.
This second alternate method sounds like it might be the best tradeoff for us. I suppose we could keep a single GacCache around, but recreate the AppDomain behind the scenes (being careful to maintain the cache itself). How does this sound?
If you recreate the GacCache for each and every project, compilation for big projects slows down by a factor of 2x or 3x. This is unbelievably painful for 100+ project solutions.
For now, we'll hold off on any changes I guess. "Jackfan"'s problem might actually have been caused by another minor issue anyway.
Gert
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
