Re: [nant-dev] solution task question

[Matthew Mastracci]

If .NET reflector allows you to query for metadata without permanently 
locking a DLL, I'm all for it.  :)  In fact, I can use that in a number 
of places!  The separate AppDomain *may* work as we need, but I've found 
that even though the AppDomain terminates, you can still end up with 
file locks held in certain situations (this is a technique we use here 
with moderate success).  Unfortunately, I can't remember the exact 
circumstances of keeping the file locks held.  It may be that only using 
reflection might not lock the DLL.  Perhaps someone can experiment with 
this.

Martin Aliger wrote:

Thanks Matt alot - I underestand it now. Unfortunatelly it's quite hard to
solve...
Maybe we could use code from .NET Reflector? I do not look into sources yet
(is it open?), but works fine. Perhaps create new AppDomain, load assembly
there, use inter-appdomain communication and terminate that appdomain?
For now - maybe just add some comments to that Reference::GetReferenceFiles
should be enough
Martin

----- Original Message -----
From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "Eddie Tse" <[EMAIL PROTECTED]>
Cc: "'Tom Cabanski'" <[EMAIL PROTECTED]>; "'Martin Aliger'"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 02, 2003 3:55 PM
Subject: RE: [nant-dev] solution task question
 

The solution task is busted in this regard.  VS.NET will open each of
the assemblies and determine the other assemblies that are referenced by
it.  This is one of the reasons that you end up with VS.NET locking
certain output assemblies!  :)
This would require code to open each of the assemblies (which, of
course, will lock the files on disk until the AppDomain terminates) and
scan for their assembly dependencies.  Please note that using
Assembly.Load(byte[]) is not an acceptable alternative.  Not only do
some assemblies lock up when loaded this way, but it can also leak
unmanaged memory in certain cases!  Shadow copy directories might work,
but I haven't investigated how NAnt has been handling these.
Because of the lame .NET locking rules, the solution task assumes that
each of the files in the output directory were placed there because they
were referenced by the actual output file.
Matt.

On Tue, 2003-09-02 at 06:28, Eddie Tse wrote:
   

I noticed this today as well with the <solution> task and it is not the
     

same
 

behaviour using VS.NET.  For me, unreferenced assemblies do not get
     

copied
 

by VS.NET to the output directory.  It only copies assemblies that are
referenced directly in your project file or indirectly by a referenced
assembly which it can find via the reference path.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
Cabanski
Sent: Tuesday, 2 September 2003 10:21 PM
To: Martin Aliger; [EMAIL PROTECTED]
Subject: RE: [nant-dev] solution task question
That's correct behavior that also happens when compiling from VS.NET;
referenced DLLs get copied to the executable folder.  You can change
     

this
 

behavior from VS.NET if you go to the properties of the reference and
     

set
 

copy local to false.  Unless you are putting probing directives into
     

your
 

configuration file, your DLLs either need to be in the same folder as
     

your
 

executable or they have to be strongly named and placed in the GAC.

I assume this is all correctly in the solution task since we use it
extensively in a large project with some GAC dlls, some project dlls and
some copy local dlls referenced directly.
-------------------------------------
TFC




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
     

--
Matthew Mastracci <[EMAIL PROTECTED]>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
   



 





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers