I'm rewriting our NAnt build scripts to make them cleaner and simpler, as well as more general purpose.
One of the steps in our build process is to package certain files into a zip file. Before we had created a fileset
with lots of included file types, trying to catch everything that might be in the project. This occasionally caused problems when we wanted to include a non-standard file type with the project.
I was hoping that I could find a way to create a fileset
based on the files (and, also, a subset of the files) listed in the Visual Studio project file (.csproj). I could then use this fileset in a zip
task. I haven't found anything that does this automatically (though the now-deprecated SLiNgshoT
task in NAntContrib looked a little promising).
I started down the path of trying to do this manually, but have gotten stuck. I have a target that gets the project from the solution (using regex
), then tries to get each Content file in the project using xmlpeek
(with the XPath query /n:Project/n:ItemGroup/n:Content/@Include
). The problem here is that xmlpeek
doesn't return every value, just the first. And, even if it did return every value, I'm not sure how I'd get it into a fileset
from here.
Is there any way to salvage this track of thinking? Can I accomplish what I want with a custom NAnt task (I'd prefer not to have every project dependent on a custom task)? Is there some built-in way to do this that I'm not finding?
Please feel free to ask questions in the comments if something about my goal or method isn't clear.
Thanks!
UPDATE: To clarify, my point in all of this is to make the whole process much more seamless. While I can easily add all .xml files to a package, this often gets .xml files that live in the same folder but aren't really part of the project. When I already have a list of the files that the project uses (separated out between Content and other types, even), it seems a shame not to use that information. Ultimately, no one should have to touch the build file to change what gets included in a package. It doesn't seem like too much of a pipe dream to me...
See this related question. The microsoft.build.buildengine interface should let you get much better access to the information you need, but unfortunately I think you would have to build a custom task.
But I think that parsing a project file to generate a fileset that is used elsewhere is ... a bit much to put all inside your build script. And since you seem to want to re-use this, I don't think that depending on a custom task is any worse than any other form of re-use (even if you can do it all in existing Nant tasks, you'd still need to have every project inherit that process somehow).