[nant-dev] Solution Task Question
I apologize in advance if I'm posting a question that has recently been answered. Many posts as oflate have gone many miles over my head...
Developersin my shoprecently got sick of reference problems and began using project references (while I was in a meeting Friday afternoon). This is good from a VS.NET standpoint because the projects are no longer machine dependant. However,it crushed my .build file using the solution taskbecause it puts some sort of registry entry into the .csproj file instead of hintpath:
Project = "{04586948-73A6-405E-A657-447805201530}" Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
This seems to be a topic of late but I haven't grasped exactly what has transpired with the solution task. Could someone toss some layman verbiage out my way?
Thanks,
Eric
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
[nant-dev] solution task question
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
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
