Hi Scott,
As agreed, I implemented an Available task that allows you to check for the
available of a file or directory resource.
I currently have two possible resource checks :
- File
- Directory
eg.
I used "resource" instead of "file" (or "directory") for the attribute name,
so we can add mo
Title: Message
On my
builds, I have a separate file that just contains properties and nothing
else. For example,
http://tempuri.org/nant-vs.xsd"
name="Global Properties">
<...>
Then I
include it in my main build file with the include task.
This
works very well for
I notice that we have both a resgen and a resx task in dotnet tasks. The
only differences I see is that resgen wraps the resgen.exe while
uses the api's directly and resx only takses a single input file instead
of a fileset. Is there some other difference I'm not aware of ?
Normally I'd prefer
Matthew Mastracci wrote:
I've manually applied Aaron's changes to my tree, cleaned up the style
to match the NAnt coding style and attached it to this message.
If noone objects, I'll check this in.
Looks ok to me.
? patch
I've manually applied Aaron's changes to my tree, cleaned up the style
to match the NAnt coding style and attached it to this message.
If noone objects, I'll check this in.
? patch.txt
Index: ResGenTask.cs
===
RCS file: /cvsroot/nant
I agree with putting it in. I'm not a big fan of the filesystem
enforcing policy like this. We need to be consistent across all of our
file-based tasks, however (I posted a change earlier that would give the
same results for the task).
Should we change it so that this behaviour is by default
Matthew,
This has not been committed yet. I'm of the mind now that this is just a lazy
mans attrib task. One can very easily just call an attrib before this task to
insure that it is not read only. However, if no one is opposed to this change,
I say put it in.
I'd really like to see my changes
Has anyone reviewed, commented or commit this patch yet? Any objections
to this?
Sansone, Aaron wrote:
All,
I've made a change to the DeleteTask that I would like to have
reviewed/committed if you all agree with the change.
This issue I ran into was forcing a delete even if the file is read on
What about this one? I use the already-gotten dstInfo to test for
attribute we don't want and clear them if they exist. Shouldn't be a
lot of overhead in this case:
diff -u -r1.4 CopyTask.cs
--- src/NAnt.Core/Tasks/CopyTask.cs 26 Feb 2003 07:02:30 - 1.4
+++ src/NAnt.Core/Tasks/Cop
This patch adds the following functionality to the element:
- multiple delimiters are allowed
- multiple properties are allowing the item="Line" case, but only if
delimiter(s) are specified
- trim="" property allows you to specify trimming whitespace from
begin, end or both parts of a string
Should I move the attribute setting bit to the earlier File.Exists
test? This way, we should only have a single place to test it and the
network overhead should only be a single attribute set per existing
file. I may actually be able to retrieve all the file properties in one
go and only set
--- Matthew Mastracci <[EMAIL PROTECTED]> wrote:
> This fixes the problem with read-only file destination for the
> task. If noone objects, I'll check this in.
snip
> > if (File.Exists(dstPath))
> > File.SetAttributes(dstPath,
> FileAttrib
Ooh. Could you post the shell script? I'd like to work on putting
something together to help folks get bootstrapped into NAnt from Linux.
(Hmmm... this might be a better long-term approach on both platforms.
Instead of including a previous set of NAnt binaries)
Some maybe-not-so-useful fin
This fixes the problem with read-only file destination for the
task. If noone objects, I'll check this in.
cvs server: Diffing src/NAnt.Core/Tasks
Index: src/NAnt.Core/Tasks/CopyTask.cs
===
RCS file: /cvsroot/nant/nant/src/NAnt.Cor
> And Philip... I'm curious as to the environment you got mono NAnt to run
> in. Cygwin, or the real deal in linux?
Suse Linux 8.0, shell script for the initial build, GVim text editor
---
This sf.net email is sponsored by:ThinkGeek
Welcome t
--- Dave Bettin <[EMAIL PROTECTED]> wrote:
>
> Hey guys,
> Log4net has been succesfully compiled and ran on mono. Also there is a mono
> debugger gui that can be used to track down problems. Perform a cvs checkout
> on "mono-tools" to get the debugger.
On log4net, I guess I was wondering what fe
16 matches
Mail list logo
