> 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.  

> What do you think ?
> 
> Gert
> 
> ----- Original Message ----- 
> From: "Jackfan" <[EMAIL PROTECTED]>
> To: "Gert Driesen" <[EMAIL PROTECTED]>
> Sent: Saturday, September 04, 2004 9:16 AM
> Subject: Re: Re: Re: [nant-dev] Bugs
> 
> 
> > Dear Gert Driesen:
> >
> > Good news!
> > I create one key 2.1, and copy values from 2.2, it worked for this case!!!
> > But a new problem:
> > =======================================================================
> > build:
> >
> > [solution] Starting solution build.
> > [solution] The reference component 'VBIDE' has an updated custom wrapper 
> > availa
> > ble.
> > [solution] Building 'SystemFrameWork' [DEBUG] ...
> > [solution] Building 'CustomControl' [DEBUG] ...
> > [solution] Building 'Common' [DEBUG] ...
> >
> > BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
> >
> > Cannot copy 'D:\Work\idg\Common\Office.dll' to 
> > 'D:\Work\idg\OutPut\Debug\Office.
> > dll'.
> >    Access to the path "D:\Work\idg\OutPut\Debug\Office.dll" is denied.
> >
> > Total time: 37.3 seconds.
> > =======================================================================
> > You know, I have not only one project that will use Office.dll, so after 
> > succeed to compile the first project(has office.dll),
> > then compile the 2nd project(has office.dll), it will occur error.
> >
> > Is this bug or wrong of my configuration?
> >
> > Thanks in advance for your response!
> >
> >
> > ======= At 2004-09-04, 15:03:05 you wrote: =======
> >
> >>Can you check whether the following registry key exists :
> >>
> >>HKEY_CLASSES_ROOT\TYPELIB\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.1\0\win32
> >>
> >>if it doesn't exist, can you tell me what keys do exist under
> >>
> >>HKEY_CLASSES_ROOT\TYPELIB\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}
> >>
> >>Thanks,
> >>
> >>Gert
> >>
> >>----- Original Message ----- 
> >>From: "Jackfan" <[EMAIL PROTECTED]>
> >>To: "Gert Driesen" <[EMAIL PROTECTED]>
> >>Sent: Saturday, September 04, 2004 8:09 AM
> >>Subject: Re: Re: [nant-dev] Bugs
> >>
> >>
> >>> Dear Gert Driesen:
> >>>
> >>> Error still exists, but changed to:
> >>> =================================================================================
> >>> NAnt 0.85 (Build 0.85.1705.0; net-1.0.win32; nightly; 2004-9-1)
> >>> Copyright (C) 2001-2004 Gerry Shaw
> >>> http://nant.sourceforge.net
> >>>
> >>> Buildfile: file:///D:/Work/idg/default.build
> >>> Target(s) specified: build
> >>>
> >>>
> >>> build:
> >>>
> >>> [solution] Starting solution build.
> >>> [solution] The reference component 'VBIDE' has an updated custom wrapper
> >>> availa
> >>> ble.
> >>>
> >>> BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
> >>>
> >>> Couldn't find reference to type library 'Office'
> >>> (TYPELIB\{2DF8D04C-5BFA-101B-BD
> >>> E5-00AA0044DE52}\2.1\0\win32).
> >>> ==================================================================================
> >>> by the way, I used 3 generated dlls from Microsoft Office2000, 
> >>> VBIDE.dll,
> >>> Office.dll, Excel.dll, and my real office version is 2003 .
> >>> But in visual studio .net, there is no any problem, it can be compiled 
> >>> and
> >>> run successfully.
> >>>
> >>> ======= At 2004-09-04, 12:48:26 you wrote: =======
> >>>
> >>>>Hi,
> >>>>
> >>>>This issue was fixed since the 0.84 release.
> >>>>
> >>>>Try using a recent nightly build of NAnt
> >>>>(http://nant.sourceforge.net/nightly/builds).
> >>>>
> >>>>Gert
> >>>>
> >>>>----- Original Message ----- 
> >>>>From: "Jackfan" <[EMAIL PROTECTED]>
> >>>>To: "nant-developers" <[EMAIL PROTECTED]>
> >>>>Sent: Friday, September 03, 2004 9:35 AM
> >>>>Subject: [nant-dev] Bugs
> >>>>
> >>>>
> >>>>> Dear nant-developers:
> >>>>> In my solution, there is one project that will include office.dll,
> >>>>> excel.dll, vbide.dll, but nant can't find them, is this a bug?
> >>>>>
> >>>>> =====================Error=================================
> >>>>>
> >>>>> build:
> >>>>>
> >>>>> [solution] Starting solution build.
> >>>>>
> >>>>> BUILD FAILED
> >>>>>
> >>>>> INTERNAL ERROR
> >>>>>
> >>>>> System.ApplicationException: Couldn't find reference to type library
> >>>>> 'Office' (T
> >>>>> YPELIB\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.1\0\win32).
> >>>>>   at NAnt.VSNet.Reference.HandleWrapperImport(XmlElement 
> >>>>> elemReference)
> >>>>>   at NAnt.VSNet.Reference..ctor(Solution solution, ProjectSettings ps,
> >>>>> XmlEleme
> >>>>> nt elemReference, SolutionTask solutionTask, String outputDir)
> >>>>>   at NAnt.VSNet.Project.Load(Solution sln, String projectPath)
> >>>>>   at NAnt.VSNet.ProjectFactory.LoadProject(Solution sln, SolutionTask
> >>>>> slnTask,
> >>>>> TempFileCollection tfc, String outputDir, String path)
> >>>>>   at NAnt.VSNet.Solution.LoadProjects()
> >>>>>   at NAnt.VSNet.Solution..ctor(String solutionFileName, ArrayList
> >>>>> additionalPro
> >>>>> jects, ArrayList referenceProjects, TempFileCollection tfc, 
> >>>>> SolutionTask
> >>>>> solutio
> >>>>> nTask, WebMapCollection webMappings, FileSet excludesProjects, String
> >>>>> outputDir)
> >>>>>
> >>>>>   at NAnt.VSNet.Tasks.SolutionTask.ExecuteTask()
> >>>>>   at NAnt.Core.Task.Execute()
> >>>>>   at NAnt.Core.Target.Execute()
> >>>>>   at NAnt.Core.Project.Execute(String targetName, Boolean
> >>>>> forceDependencies)
> >>>>>   at NAnt.Core.Project.Execute()
> >>>>>   at NAnt.Core.Project.Run()
> >>>>>
> >>>>> Please send bug report to [EMAIL PROTECTED]
> >>>>>
> >>>>> Total time: 2.9 seconds.
> >>>>>
> >>>>>
> >>>>> ========================My build 
> >>>>> file===================================
> >>>>> <?xml version="1.0"?>
> >>>>>  <project name="idg" default="build" basedir=".">
> >>>>>
> >>>>>  <property name="solution"  value="test.sln"/>
> >>>>>  <property name="config.debug" value="DEBUG"/>
> >>>>> <property name="config.release" value="RELEASE"/>
> >>>>>  <property name="output.debug"   value="OutPut\Debug" />
> >>>>> <property name="output.release" value="Output\Release" />
> >>>>>
> >>>>> <target name="clean">
> >>>>> <delete dir="${output.debug}" verbose="true" failonerror="false" />
> >>>>> <delete dir="${output.release}" verbose="true" failonerror="false" />
> >>>>> </target>
> >>>>>
> >>>>>  <target name="build">
> >>>>> <solution solutionfile="${solution}" outputdir="${output.debug}"
> >>>>> configuration="${config.debug}"/>
> >>>>>  </target>
> >>>>> </project>
> >>>>>
> >>>>> Your sincerely:
> >>>>> Jackfan
> >>>>> [EMAIL PROTECTED]
> >>>>> 2004-09-03
> >>>>>
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------
> >>>>> 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
> >>>>>
> >>>>
> >>>
> >>> = = = = = = = = = = = = = = = = = = = =
> >>>
> >>> Your sincerely:
> >>> Jackfan
> >>> [EMAIL PROTECTED]
> >>> 2004-09-04
> >>>
> >>>
> >>>
> >>
> >
> > = = = = = = = = = = = = = = = = = = = =
> >
> > Your sincerely:
> > Jackfan
> > [EMAIL PROTECTED]
> > 2004-09-04
> >
> >
> > 
-- 
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

Reply via email to