May I sugges a sort step first to generate the 'filename-list'?
| "Gary Feldman"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 04/21/2005 03:56 AM |
|
Nau, Michael wrote:
>It looks like when running the <foreach> task over a set of files in a
>particular directory, the task is run on each file in alpha order. For
>example, running the following nant task:
>
><foreach item="File" property="filename">
>
...
>My question is can I depend on this every time? I don't see this
>documented anywhere?
>
>
I can't speak for the development team. However, there are several
reasons why I think it wouldn't make sense to guarantee this.
Specifically, even though you have a relatively simple fileset in your
<items>, filesets can be fairly complex. Furthermore, I don't see where
Microsoft, in the .MSDN docs, guarantees it for their functions.
Indeed, at the Windows SDK level, they explicitly say that FAT file
systems won't guarantee order. This suggests to me that file systems
over the network won't, either, because there's no guarantee that the
file system will use NTFS/CDFS (the two for which Microsoft does
guarantee order at the Windows SDK level).
The simplest thing to do might be to just check the order and fail if
it's broken. This would allow you to punt solving the problem until it
actually becomes an issue, instead of trying to solve it now on the
basis that it's not guaranteed for the indefinite future. You can do
this easily with something like:
<property name="previousFile" value="" />
...
<do>
<fail message="Files out of order" if="${previousFile > filename}" />
<property name="previousFile" value="${filename}" />
...
If I had to absolutely guarantee this, I'd create a file that contains
the filenames in order, and use the <foreach> task with the
'item="Line"' item type. This requires slightly more work for
maintenance, but it gives you much more flexibility and reliability.
You can use an arbitrary order, which you might want to do to debug the
ordering depending upon why they need to be in order. You could add
comments to this file by some sort of comment convention, so that any
subsequent maintainer would know how and why this constraint exists.
You might want to add some sort of check of "${file::exists(...)}" to
make sure the list didn't refer to files that don't exist, and you might
also want to add a reverse check to warn if any files aren't in the list
that should be. The latter isn't difficult but would slow down
execution as it requires a linear search (at least with the current set
of NAnt functions and data types).
If the files themselves are being generated dynamically, then you might
also generate the listing file dynamically at the same time. If that's
not possible, then I'd go with the first approach or try to eliminate
the requirement if at all possible. (You didn't say why you need this,
so I can't tell if this is reasonable.)
Gary
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
