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
