Okay - I added code to recreate the AppDomain within the GacCache each time we do a project build. Even though it might not be necessary, it should ensure that we "trim the fat" by getting rid of all the stuff we loaded into the AppDomain during the project run.
Since we keep the results of previous runs cached, this shouldn't have an appreciable impact on performance. Matt. On Sat, 2004-09-04 at 09:04, Gert Driesen wrote: > ----- 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 -- Matthew Mastracci <[EMAIL PROTECTED]> ------------------------------------------------------- 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
