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
