noshyuz wrote:
depending on your usage, it might be that the directories list is
pretty static, however one advantage of the solution file is that you
can change the list of dependent projects that are included - in this
case, you have to make sure you mirror the changes both in the project
file and in the NAnt script.
You don't need a directories list, at least not for the project types I
cited. Just set up the delete from your root directory, using patterns
such as
<include name="**\Debug\**" />
<include name="**\bin\**" />
and make sure none of your developers are foolish enough to use "Debug"
or "bin" as a project name or for other purposes.
also, if you make changes in how you build/install/package up your
projects (maybe some use non-default directories, or have additional
pre/post build steps, etc), it would be nice to not have to go change
your NAnt scripts
Usually those sorts of changes should only be done on the NAnt side,
leaving the Visual Studio solution side with the defaults. This makes
life much easier for both the developers and the release engineers.
When I first started working with NAnt, I was paranoid that the solution
task would diverge from the Visual Studio builds, but that hasn't
happened, and as I see how the solution task works, I'm not worried
about that happening as far as file names and directory paths are
concerned. I'm more worried about NAnt getting all the command line
settings correct.
I believe NAnt already takes care of the pre/post build steps, so that's
a non-issue.
also - it would be great if there was some property or value exposed
from the solution task or somewhere that gave you the list/location of
the bin/obj directories as specified in the .NET solution/project
files, so that even if you had to write NAnt script to parse that
property and delete the list of dircetories, at least you'd know that
you were removing the right things, since there would be a single
source of the data in question.
I agree that such a thing would be nice, but I don't consider it high
priority. A better strategy is just to keep the build simple.
it's not impossible to do manually, of couse, but it's one more thing
that has to be included and done manually, since it's a separate
config file for a separate tool, and thus it's something that can be
forgotten, so if it were possible to automate, it would be less error
prone.
I haven't seen these sorts of errors happening. Far more common is a
developer forgetting to check-in a change to a project file, or checking
in a changed project file without adding a new source file to the
repository.
Gary
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
