[nant-dev] ReflectionTypeLoadException when using custom task
I've written a custom task, put the
compiled DLL in the same directory as nant.exe, named it XXXTasks.dll,
and my public class inherits from task and has the TaskNameAttribute.
But when I attempt to use it, I get
the following:
[Core.TypeFactory:Error loading Elements
from Allstate.AllCorp.CustomNantTasks,Version=1.0.1537.25977, Culture=neutral,
PublicKeyToken=null(d:\allcorp\tools\bin\allstate.allcorp.customnanttasks.dll).
- [] <>]
Exception: System.Reflection.ReflectionTypeLoadException
Message: One or more of the types in
the assembly unable to load.
Source: mscorlib
at System.Reflection.Module.GetTypesInternal(StackCrawlMark&
stackMark)
at System.Reflection.Assembly.GetTypes()
at NAnt.Core.TypeFactory.AddDataTypes(Assembly
taskAssembly)
Best,
Garrett
The full output from my nant run follows:
D:\AllCorp\Tools\CCNET\server>..\..\bin\nant.exe
-buildfile:bootstrap.build
log4net: log4net assembly [log4net,
Version=1.2.0.30714, Culture=neutral, Public
KeyToken=b32731d11ce58905]. Loaded from
[d:\allcorp\tools\bin\log4net.dll]. (.NE
T Runtime [1.1.4322.573] on Microsoft
Windows NT 5.0.2195.0)
log4net: DefaultRepositorySelector:
defaultRepositoryType [log4net.Repository.Hi
erarchy.Hierarchy]
log4net: DefaultRepositorySelector:
Creating repository for assembly [NAnt, Vers
ion=0.84.1435.0, Culture=neutral, PublicKeyToken=null]
log4net: DefaultRepositorySelector:
Assembly [NAnt, Version=0.84.1435.0, Culture
=neutral, PublicKeyToken=null] Loaded
>From [D:\AllCorp\Tools\bin\NAnt.exe]
log4net: DefaultRepositorySelector:
Assembly [NAnt, Version=0.84.1435.0, Culture
=neutral, PublicKeyToken=null] does
not have a DomainAttribute specified.
log4net: DefaultRepositorySelector:
Assembly [NAnt, Version=0.84.1435.0, Culture
=neutral, PublicKeyToken=null] using
domain [log4net-default-domain] and reposit
ory type [log4net.Repository.Hierarchy.Hierarchy]
log4net: DefaultRepositorySelector:
Creating repository for domain [log4net-defa
ult-domain] using type [log4net.Repository.Hierarchy.Hierarchy]
log4net: DOMConfigurator: configuring
repository [log4net-default-domain] using
file [D:\AllCorp\Tools\bin\NAnt.exe.config]
watching for file updates
log4net: DOMConfigurator: configuring
repository [log4net-default-domain] using
file [D:\AllCorp\Tools\bin\NAnt.exe.config]
log4net: DOMConfigurator: configuring
repository [log4net-default-domain] using
stream
log4net: DOMConfigurator: loading XML
configuration
log4net: DOMConfigurator: Configuring
Repository [log4net-default-domain]
log4net: DOMConfigurator: Configuration
update mode [Merge].
log4net: DOMConfigurator: Logger [root]
Level string is [ERROR].
log4net: DOMConfigurator: Logger [root]
level set to [name="ERROR",value=7].
log4net: DOMConfigurator: Loading Appender
[ConsoleAppender] type: [log4net.Appe
nder.ConsoleAppender]
log4net: DOMConfigurator: Setting Property
[ConversionPattern] to String value [
[%c{2}:%m - [%x] <%X{auth}>]%n]
log4net: DOMConfigurator: Setting Property
[Layout] to object [log4net.Layout.Pa
tternLayout]
log4net: DOMConfigurator: Created Appender
[ConsoleAppender]
log4net: DOMConfigurator: Adding appender
named [ConsoleAppender] to logger [roo
t].
log4net: DOMConfigurator: Hierarchy
Threshold [DEBUG]
log4net: DefaultRepositorySelector:
Creating repository for assembly [NAnt.Core,
Version=0.84.1435.0, Culture=neutral,
PublicKeyToken=null]
log4net: DefaultRepositorySelector:
Assembly [NAnt.Core, Version=0.84.1435.0, Cu
lture=neutral, PublicKeyToken=null]
Loaded From [d:\allcorp\tools\bin\nant.core.
dll]
log4net: DefaultRepositorySelector:
Assembly [NAnt.Core, Version=0.84.1435.0, Cu
lture=neutral, PublicKeyToken=null]
does not have a DomainAttribute specified.
log4net: DefaultRepositorySelector:
Assembly [NAnt.Core, Version=0.84.1435.0, Cu
lture=neutral, PublicKeyToken=null]
using domain [log4net-default-domain] and re
pository type [log4net.Repository.Hierarchy.Hierarchy]
log4net: DefaultRepositorySelector:
domain [log4net-default-domain] already exis
its, using repository type [log4net.Repository.Hierarchy.Hierarchy]
NAnt 0.84 (Build 0.84.1435.0; net-1.0.win32;
rc 1; 12/6/2003)
Copyright (C) 2001-2003 Gerry Shaw
http://nant.sourceforge.net
[Core.TypeFactory:Error loading tasks
from Allstate.AllCorp.CustomNantTasks, Ver
sion=1.0.1537.25977, Culture=neutral,
PublicKeyToken=null(d:\allcorp\tools\bin\a
llstate.allcorp.customnanttasks.dll).
- [] <>]
Exception: System.Reflection.ReflectionTypeLoadException
Message: One or more of the types in
the assembly unable to load.
Source: mscorlib
at System.Reflection.Module.GetTypesInternal(StackCrawlMark&
stackMark)
at System.Reflection.Assembly.GetTypes()
at NAnt.Core.TypeFactory.AddTasks(Assembly
taskAssembly)
[Core.TypeFactory:Error loading Elements
from Allstate.AllCorp.CustomNantTasks,
Version=1.0.1537.25977, Culture=neutral,
PublicKeyToken=null(d:\allcorp\tools\bi
n\allstate.allcorp.customnanttasks.dll).
- [] <>]
Exception: System.Reflection.ReflectionTypeLoadException
Messag
Re: [nant-dev] Re: NAnt pedantic mode
On Wed, 2004-03-17 at 16:57, Matthew Mastracci wrote: > Gert Driesen wrote: > > > You mean an attribute that didn't exist ? Properties that don't exist cause > > a build error already ... > > Yep - that's what I was thinking. > > > But I agree that we should indeed have this mode (or just always run NAnt in > > this mode, what do you propose) ... > > > > In what cases should NAnt throw a build error : > > > > - a system property that no longer exist > > - an attribute/child element that is deprecated, and the IsError property of > > the ObsoleteAttribute is set to true > > - a task/type that is deprecated, and the IsError property of the > > ObsoleteAttribute is set to true > > - an attribute/child element that does not (or no longer) exist > > +1 on all four. AFAIK, 2 and 3 are already done. nope, we currently only log an error message for 2 and 3 (and 4 I think). We do not cause the build to fail. > Looks good to me. The biggest issue I run into is renamed attributes. > Renamed sub-elements could also end up being a bit of a problem. > > Should this be the default mode? I'm not sure about this one, but we > would need a way to run in "less-strict" mode. Perhaps less-strict should be default. We can always change the default later. Gert --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
Gert Driesen wrote: I can also guarantee 100% that VS.NET (2003) is only using the hintpath as a last resort ;) I've reverted the change in CVS. Thanks for the explanation :) Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
Gert Driesen wrote: Matthew, I can also guarantee 100% that VS.NET (2003) is only using the hintpath as a last resort ;) The actual order is : 1. the project directory (at least this is what MS says, but I doubt this) 2. The ReferencesPath (as stored in the user options file, eg. .csproj.user) 3. The .NET Framework directory 4. The AssemblyFolder (even if the AssemblyFolderKey is not specified on the reference itself) 5. The HintPath Please send me a repro to convince me otherwise, but make sure you first check if you don't have entries in the ReferencesPath attribute in the .user file :) Oh - you're right, I had a bunch of reference paths in the project's .user file. I deleted my .user file and ended up with the same behaviour. Looks like VS.NET is ignoring the HintPath in this case and just using the AssemblyFolder version of the .DLL. So anyways, I finally understand that you are correct - VS.NET does check AssemblyFolders before HintPath. IMHO this is a strange way to do things. VS.NET doesn't make it easy to easily reproduce a build between two machines, does it? Unfortunately, I need to build on a clean system that doesn't have any csproj.user files. Perhaps I'll just delete the AssemblyFolders key from the registry on the build machine. Sorry for doubting. ;) Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
Matthew, I can also guarantee 100% that VS.NET (2003) is only using the hintpath as a last resort ;) The actual order is : 1. the project directory (at least this is what MS says, but I doubt this) 2. The ReferencesPath (as stored in the user options file, eg. .csproj.user) 3. The .NET Framework directory 4. The AssemblyFolder (even if the AssemblyFolderKey is not specified on the reference itself) 5. The HintPath Please send me a repro to convince me otherwise, but make sure you first check if you don't have entries in the ReferencesPath attribute in the .user file :) Gert - Original Message - From: "Matthew Mastracci" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> Sent: Wednesday, March 17, 2004 5:03 PM Subject: Re: [nant-dev] Re: Solution task fixes + speedups > I can absolutely, 100% guarantee that this is the case. I have a > .csproj file with the following reference: > >Name = "C1.Win.C1FlexGrid" > AssemblyName = "C1.Win.C1FlexGrid" > HintPath = "..\supportDlls\C1.Win.C1FlexGrid.dll" > /> > > The DLL in the HintPath is of version 1.1.20024.78. When I compile with > VS.NET, the DLL that ends up in the bin directory is version 1.1.20024.78. > > There is also an AssemblyFolder entry that looks like this: > > C1Studio = C:\Program Files\ComponentOne Studio.NET\bin > > In this directory is C1.Win.C1FlexGrid.dll version 2.1.20034.144. This > is not the DLL we want to compile against. > > If you want to revert the ordering, please wrap the assembly folder > stuff with a check for the "AssemblyFolderKey = blah" attribute of the > reference. AFAIK, if this attribute is missing, VS.NET ***will not*** > use the AssemblyFolders for resolution. > > Does this sound acceptable? It looks like with this logic, I should be > able to compile my project (while keeping your resolution order intact). > > Gert Driesen wrote: > > > Matthew, > > > > I looked into this again, and I'm pretty sure I'm right : > > > > The HintPath is definitely the "last resort" for VS.NET. So we should undo > > your change (unless you can send me a repro). > > > > The issue you encountered was probably due to the fact that we don't yet use > > the path list in the ReferencesPath attribute (of the Settings node) in the > > .user file (the project user options) to locate assemblies. (feel free to > > add support for this to the solution task :-)) > > > > Gert > > - Original Message - > > From: "Matthew Mastracci" <[EMAIL PROTECTED]> > > To: "Gert Driesen" <[EMAIL PROTECTED]> > > Cc: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> > > Sent: Tuesday, March 16, 2004 11:35 PM > > Subject: [nant-dev] Re: Solution task fixes + speedups > > > > > > > >>Gert Driesen wrote: > >> > >> > >>>But you actually have two different "assembly folders" : you have the > >>>assembly folder that is referenced in your project file using the > >>>"AssemblyFolderKey" attribute of the element, eg. > >> > >>... > >> > >> > >>>and you have the rest of the AssemblyFolder registry keys. Perhaps > > > > VS.NET > > > >>>first checks the AssemblyFolderKey, then the HintPath and then the rest > > > > of > > > >>>the assembly folders. But I'm just guessing here. > >> > >>Aha... I don't have an AssemblyFolderKey attribute on my reference - > >>it's a direct file reference. The AssemblyFolder check was still > >>picking it up, however. > >> > >>Perhaps the order was correct as you had it, but we should skip the > >>assembly folder check if that attribute is missing. > >> > >> > Even if Microsoft describes it as a last resort, it's definitely not how > VS.NET does it. > >>> > >>> > >>>I'll verify it tomorrow, and report it to MS if necessary > >> > >>Cool. Thanks! > >> > >>Matt. > >> > >> > >>--- > >>This SF.Net email is sponsored by: IBM Linux Tutorials > >>Free Linux tutorial presented by Daniel Robbins, President and CEO of > >>GenToo technologies. Learn everything from fundamentals to system > >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > >>___ > >>nant-developers mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/nant-developers > >> > >> > > > > > > > --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: Solution task fixes + speedups
Matthew Mastracci wrote:
If you want to revert the ordering, please wrap the assembly folder
stuff with a check for the "AssemblyFolderKey = blah" attribute of the
reference. AFAIK, if this attribute is missing, VS.NET ***will not***
use the AssemblyFolders for resolution.
Just to clarify, I think the change should be this (pseudo-patch):
private bool ResolveFromAssemblyFolders(XmlElement referenceElement) {
- if (referenceElement.Attributes["AssemblyFolderKey"] != null) {
+ if (referenceElement.Attributes["AssemblyFolderKey"] == null) {
+ return;
+ } else {
string assemblyFolderKey =
referenceElement.Attributes["AssemblyFolderKey"].Value;
Matt.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
I can absolutely, 100% guarantee that this is the case. I have a .csproj file with the following reference: The DLL in the HintPath is of version 1.1.20024.78. When I compile with VS.NET, the DLL that ends up in the bin directory is version 1.1.20024.78. There is also an AssemblyFolder entry that looks like this: C1Studio = C:\Program Files\ComponentOne Studio.NET\bin In this directory is C1.Win.C1FlexGrid.dll version 2.1.20034.144. This is not the DLL we want to compile against. If you want to revert the ordering, please wrap the assembly folder stuff with a check for the "AssemblyFolderKey = blah" attribute of the reference. AFAIK, if this attribute is missing, VS.NET ***will not*** use the AssemblyFolders for resolution. Does this sound acceptable? It looks like with this logic, I should be able to compile my project (while keeping your resolution order intact). Gert Driesen wrote: Matthew, I looked into this again, and I'm pretty sure I'm right : The HintPath is definitely the "last resort" for VS.NET. So we should undo your change (unless you can send me a repro). The issue you encountered was probably due to the fact that we don't yet use the path list in the ReferencesPath attribute (of the Settings node) in the .user file (the project user options) to locate assemblies. (feel free to add support for this to the solution task :-)) Gert - Original Message - From: "Matthew Mastracci" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, March 16, 2004 11:35 PM Subject: [nant-dev] Re: Solution task fixes + speedups Gert Driesen wrote: But you actually have two different "assembly folders" : you have the assembly folder that is referenced in your project file using the "AssemblyFolderKey" attribute of the element, eg. ... and you have the rest of the AssemblyFolder registry keys. Perhaps VS.NET first checks the AssemblyFolderKey, then the HintPath and then the rest of the assembly folders. But I'm just guessing here. Aha... I don't have an AssemblyFolderKey attribute on my reference - it's a direct file reference. The AssemblyFolder check was still picking it up, however. Perhaps the order was correct as you had it, but we should skip the assembly folder check if that attribute is missing. Even if Microsoft describes it as a last resort, it's definitely not how VS.NET does it. I'll verify it tomorrow, and report it to MS if necessary Cool. Thanks! Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: NAnt pedantic mode
Gert Driesen wrote: You mean an attribute that didn't exist ? Properties that don't exist cause a build error already ... Yep - that's what I was thinking. But I agree that we should indeed have this mode (or just always run NAnt in this mode, what do you propose) ... In what cases should NAnt throw a build error : - a system property that no longer exist - an attribute/child element that is deprecated, and the IsError property of the ObsoleteAttribute is set to true - a task/type that is deprecated, and the IsError property of the ObsoleteAttribute is set to true - an attribute/child element that does not (or no longer) exist +1 on all four. AFAIK, 2 and 3 are already done. in what cases should NAnt output a warning (deprecated message) in the build log : - a system property that has been replaced/renamed (eg. replaced by a function), but the original property still exists. - an attribute/child element that is deprecated, and the IsError property of the ObsoleteAttribute is set to false - a task/type that is deprecated, and the IsError property of the ObsoleteAttribute is set to false +1 on all three here too. Please correct me wherever necessary and add items to these lists Looks good to me. The biggest issue I run into is renamed attributes. Renamed sub-elements could also end up being a bit of a problem. Should this be the default mode? I'm not sure about this one, but we would need a way to run in "less-strict" mode. Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Change to "call" task makes upgrade difficult
Personnaly, I prefered tha way it worked before the changes:
-if i have a target with the depends attribute, the target(s) in the
depends are executed only if they weren't executed previously.
-having the force attribute on the call task.
But i would agree in having the force attribute to true by default, as when
I explicitly call a target i would expect it to alway be executed, but if i
specify that a target depends on another target it's only to make sure that
the specified target was executed.
Regards,
Nick
Original Message Follows
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Matthew Mastracci" <[EMAIL PROTECTED]>,"James C. Papp"
<[EMAIL PROTECTED]>,"Nant-Developers (E-mail)"
<[EMAIL PROTECTED]>
Subject: Re: [nant-dev] Re: Change to "call" task makes upgrade difficult
Date: Wed, 17 Mar 2004 08:18:30 +0100
Matthew, can you add this task to NAntContrib cvs ? Its in the NAnt patches
tracker.
But I wonder if we should change it to use a collection of target elements,
eg.
That way you can also conditionally execute a certain target. (by the way:
not sure I like the name of the task)
We could ofcouse always reinstate the force attribute of the task,
but in that case it should be true by default ...
Gert
- Original Message -
From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "James C. Papp" <[EMAIL PROTECTED]>; "Nant-Developers (E-mail)"
<[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 1:21 AM
Subject: [nant-dev] Re: Change to "call" task makes upgrade difficult
> James C. Papp wrote:
>
> > This was also my rational of not just adding a flag to . The
> > task is just a dynamic form of the task's depends
attribute..., in
> > all other respect their ultimate functionality would be identical. The
> > task was not meant to be used as a way to call targets, but
(more
> > accurately), to assert that a set of dependencies were meet or handled
(if
> > needed) before continuing. This is similar a little bit to .NET
security
with
> > the way you can request certain privileges up front (as assembly
metadata), or
> > dynamically by asserting them within code.
>
> Heh... I just ran into the same problem you have. My workaround so far
> is to add the following attribute to all of my "execute-once" targets:
>
> unless="${target::has-executed(target::get-current-target())}"
>
> I would love to have the task instead. :)
>
> Matt.
>
>
> ---
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> ___
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
>
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
_
MSN Messenger : discutez en direct avec vos amis !
http://messenger.fr.msn.ca/
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt pedantic mode
> -Original Message- > From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED] > Sent: den 17 mars 2004 07:52 > To: Matthew Mastracci; Nant-Developers (E-mail) > Subject: Re: [nant-dev] NAnt pedantic mode > > > > I've run into a number of build-script bugs today that are > related to > > NAnt task properties changing/disappearing/obsoleting/etc. > > > > What does everyone think of a command-line flag to put NAnt into > > pedantic mode? This would throw an error if any build task > tried to > > use a property that didn't exist or was obsoleted. > > > > I would personally run in pedantic mode all the time. > > > > Ideas? Comments? Flames? :) > > That's a great idea. I personally find it annoying that I can > pass an argument (attribute, fileset) that is ignored because > it is misspelled but I get no word of warning. > > I think that this commandline flag should be also settable at > the project > level: > > > ... > > > Jarek Or how about a "dry run" mode? That way I won't even hav to wait for ages for the code to run through all my stuff. Maybe I don't even need code at all, I can develop/test the script syntax dry. /Nicke --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
