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 thisI 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).
documented anywhere?
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 [email protected] https://lists.sourceforge.net/lists/listinfo/nant-users
