we could always output the compiler options in debug mode, but in order to
see them you'd then have to start NAnt with the -debug switch
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Monday, January 05,
James,
This looks good. However I'm wondering if it would be better to use
seperate properties for stderr and stdout
Ian
Here is a patch that adds two badly needed features (well..., at least for me
:-)) to the exec/ task.
One is resultproperty, which is used to specify a property that will
Hi all,
I'm trying to develop new xml type. Right now I have some preliminary patch
to enable script like this:
xml id=x1
book
author
nameJohn/name
surnameSmith/surname
/author
titleJohn Smith's life/title
/book
/xml
target name=test
xmlpeek refid=x1
Hello Martin,
It's a good idea, still it is a bit complicated to deal with xmlpeek,
if you need a single value. Surely, function will help a lot.
MA What I want to do is something James and Ivan also proposed: add some way to
MA return information from task back to script. I dont think that add
In my project I have a class that has many public static members. I have built this
project into a library Utilities.dll and this is used in another project.
The problem that I am facing with this is that the project does not compile as it says
The type or namespace Combine in the class or
Hi,
Is the presence of ResGen tool is mandatory for Nant
to build properly ?
Is there any option where we can specify not to use
any ResGen ?
Thanks,
Guru
=
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
1.) If you have the time, go for it!
2.) Improvements are great.
3.) Adding support for this is a good idea. At the solution and project
level seems like a nice one to have too.
- Original Message -
From: Martin Aliger
Hi all !
1/
Do you think, that now is good time to some cleaning
I'm inclined to put new tasks like this in NAntContrib. Does anyone have a
major complaint about that? We can always move it later.
As for your implementation; It seems okay. I'm a little confused about what
you've done for the on attribute. It looks like you are not expanding,
supporting
For tasks (such as the solution task), what about having C# classes in
NAnt that map to XML itself? They could appear as XML to
xmlpeek/xmlpoke/xmlforeach, but would be backed by C# classes internally.
This would make it far simpler to return values from tasks.
Martin Aliger wrote:
Hi all,
Original Message
Subject: [Nprof-developers] Re: solution task
Date: Tue, 06 Jan 2004 11:09:22 -0700
From: Matthew Mastracci [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED],
[EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Sounds good to me too - just ensure that you've
Some time ago I proposed a syntax to allow the ultimate customization of
solution task.
It was something like:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false showcommands=true
projects
includes name=${build.dir}/**/*.csproj/
/projects
override
This sounds interesting but I'm not sure I follow. Can you explain a little
more?
The concept of inputs/outputs to tasks (when called from other tasks) and
adding context info so tasks know about following task, and preceding tasks,
sounds interesting. But I'm not sure how this ties in here.
The dynamic attribute is set to true by default, so normally you would not have
to touch it, though I agree with you, I don't see any reason why you would ever
want to prevent the expansion of the on attribute. It was a leftover from my
testing harness and I just never removed it. I've included
Yea, I was thinking the same thing (Ant does it this way), but sometimes you
want the combined output (particularly with Windows command-line tools which
seem not to get the whole stderr, stdout concept), and if you have two separate
properties there is no way to recombined them in the order that
I suppose my original message wasn't that clear. I'm not completely
certain this idea is fully formed in my head either! ;)
What I'm proposing is that the NAnt build script writer user would use
the task outputs as if they were XML, but under the hood they would be
fully-fledged C# classes.
I like the ability to customize any field within the project. Would it
be more suitable to perform this modification using the
xmlpeek/xmlpoke tasks outside of the solution task itself?
Perhaps some sort of per-project handler subtask could work as well:
solution ...
projects ... /projects
I'd say NAntContrib as well. Its a good placce to try out new ways of
doing things. If it becomes the a standard usage then of course we'll
move it back.
Ian
Scott Hernandez wrote:
I'm inclined to put new tasks like this in NAntContrib. Does anyone have a
major complaint about that? We can
Using xpathnavigators for this stuff would be nice. There was an msdn
article a while back implementing an xpathnavigator interface over a zip
file. It would work well for any sort of hierarchical data. +1 on using
some sort of hierarchical storage for task inputs and outputs.
Ian
Scott
Yep, I reviewed that and it was not up to snuff. It was an example of how
you could do it. Not a real world implementation. The Bamboo.Prevalence
implementation is much farther along. I'll approach them about splitting
that out into its own project. There will be enough there to justify that I
Sounds good. I'll have to go take a look at it. Bamboo.Prevalence that is.
Ian
Scott Hernandez wrote:
Yep, I reviewed that and it was not up to snuff. It was an example of how
you could do it. Not a real world implementation. The Bamboo.Prevalence
implementation is much farther along. I'll
20 matches
Mail list logo
