Sure, it integrates into Visual Studio, but that represents ROI for Microsoft, not me.
I've come from scheduling build scripts (.cmd -fu), with some Ant/nAnt experience to the nightmare world of the overdesigned MSBuild, which is just completely opaque. With a syntax that makes a simple tag reference impossible (properties are assigned by the tag name), too much confounding magic (this property or item or target has a special name that is used somewhere deep within the Web Deployment target file, and good luck finding a simple reference for that), and a completely impenetrable variable syntax ( @(FilesToCopy ĘC> '$(MSBuildProjectDirectory)\Bin\%(Filename)%(Extension)') Are you kidding me ), and the ever-human-readable GUIDs (also impossible to find a quickref for) sprinkled throughout.
I've found exactly one book, published last year (not even by MS Press), on MSBuild. Other books may provide an appendix or something, but I haven't found anything helpful.
Today I finally got my Web Deployment Project to build successfully as a Team Build, but nothing showed up in the WDP Output Directory. Great, so it isn't working, and there is no error message to tell me why. WTF
Side topic: What are the intended purposes of Web Sites, Web Application Projects, and Web Deployment Projects How do they compare Why do all three exist Am I using the wrong thing
Why am I doing this Because it's the Microsoft direction What do I gain As far as I can tell, the primary differences are some better reporting and auditing, integration with the VS Team Process Template (once we decide to try customizing that again), and that our QA staff will now need to open VS to start a test build, where they could just open \\<server>\admin$\Tasks before.
In the meantime, I am hemorrhaging hours, and seriously wondering... why