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 From: Martin Aliger [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 6:49 AM To: ! nant Hi all, What should this code in Reference::GetReferenceFiles do? // Get a list of the references in the output directory foreach (string referenceFile in Directory.GetFiles(fi.DirectoryName, *.dll)) { // Now for each reference, get the related files (.xml, .pdf, etc...) string relatedFiles = Path.GetFileName(Path.ChangeExtension(referenceFile, .*)); foreach (string relatedFile in Directory.GetFiles(fi.DirectoryName, relatedFiles)) { // Ignore any other the garbage files created string fileExtension = Path.GetExtension(relatedFile).ToLower(CultureInfo.InvariantCulture); if (fileExtension != .dll fileExtension != .xml fileExtension != .pdb) { continue; } referencedFiles.Add(new FileInfo(relatedFile).Name); } } I do not underestand it at all. I have project which references assembly not in solution but in precompiled dll. It is in folder together with other 50 dlls which have no link with this one. And this code copy all that dlls to mine output directory! Regards, Martin --- 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
RE: [nant-dev] solution task question
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
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 must disagree Tom. I have solution in VS with one reference to DLL e:\net\dll\Gordic.General.dll when compile and look into bin/Debug I see this: Gordic.General.dll Gordic.Support.Win32.dll Gordic.Support.Win32.pdb Gordic.General.xml this is all. But folder e:\net\dll contains about 50 dlls and some xmls. Nant copy ALL these to output folder which is definitly not correct. I believe there was some idea behind that code. But what? Martin - Original Message - From: Eddie Tse [EMAIL PROTECTED] To: 'Tom Cabanski' [EMAIL PROTECTED]; 'Martin Aliger' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 2:28 PM Subject: RE: [nant-dev] solution task question 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 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 --- 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
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