I have exactly the same problem as you, and it seems not to have been corrected since
then.
I took care of setting the "Copy Local" property of my file reference to "False", but
the
solution task still copies 43 files in my output directory.
There is actually a slight difference of behaviour between Visual Studio and the
solution task :
- in Visual Studio, if Local Copy is not defined it is assumed as "False" (beware
that the value you see in the IDE is not always written in the project xml file
because False is the default value !)
- in NAnt, if the attribute Private (which corresponds to "Copy Local") is not
defined in the project file, and the reference is neither a project reference nor an
assembly in the GAC, the CopyLocal value is set to TRUE !!
I fixed that on my machine and it worked fine for my whole solution (25 projects).
To summarise, I propose the following behaviour for the CopyLocal value :
- always take into account the value of the Private attribute if defined
- if not defined :
* if it is a project reference then CopyLocal is true
* if anything else (file present in gac or not) then CopyLocal is false
It should work as I said if u change the following line (NAnt/VS.Net/Reference.cs,
line 101 of current version) :
_copyLocal = _privateSpecified ? _isPrivate : true;
by this one
_copyLocal = _privateSpecified ? _isPrivate : false;
(it is in the else part, when the assembly is not in the GAC)
regards,
vincent
-------- Message d'origine--------
De: Mike Roberts [mailto:[EMAIL PROTECTED]
Date: jeu. 26/06/2003 23:11
À: [EMAIL PROTECTED]
Cc:
Objet: [Nant-users] Question about <solution> reference resolution behaviour
Hi,
I'm just starting to use the <solution> task and I'm a bit confused by
its behaviour. If a project references a dll in a folder, <solution>
seems to copy *all* the dlls from that folder to the build/output
directory, not just the one that was referenced. In my environment, this
leads to my output dirs having significantly more content in them when I
use <solution> as opposed to when I use VS's compiler. Is there a reason
for this behaviour?
Cheers,
Mike
^){([8bAzE&z
y!yޞm)rڞ^h왨x%gj{]z�X( ~zwilqzlX)ߣڞ^h
