brianary

I've been trying to set up a Team Build for a simple web application for about a week now, and I just don't see the point anymore.

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


Re: Team Foundation Server - Build Automation Another day completely wasted

Aaron Hallberg - MSFT

Sorry to hear you are so frustrated with MSBuild / Team Build... Here are some resources that may help:
  • MSBuild Reference on MSDN.
  • MSBuild Transforms - this is the @(ItemGroup->'Transformed Item Group') syntax.
  • Web Application Project info. I believe the history here is something like - VS 2005 tried to replace the old VS 2003 web project model with a "project file-less" model known as the Website project. This did not make too many people happy, at which point the Web Application Project was introduced as an add-on and later as part of a service pack.
  • Team Build overview.
  • My blog, where you can find some advanced topics on customizing your Team Build build process, links to other useful MSDN blogs, etc.
  • MSBuild Team Blog.
As you mentioned, the primary benefits of using Team Build include integration with the rest of VSTS - reporting, auditing, version-control/work item tracking integration, etc. When Orcas comes up there will be other benefits as well - out-of-the-box support for continuous integration, retention policies, etc.

If you have specific questions on Team Build, I would also encourage you to search this forum and create a new thread if you don't find the answer. There are a fair number of folks who can answer questions here, and the MS employees (myself included) try to be pretty responsive in general. MSBuild questions can also be posted here if they relate to Team Build, or on the MSBuild forum.

-Aaron





Re: Team Foundation Server - Build Automation Another day completely wasted

psYcon

"our QA staff will now need to open VS to start a test build, where they could just open \\<server>\admin$\Tasks before."

tfsbuild.exe from commandline can do the same thing.





Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

Those sources, most of which I was already aware of, weren't really of much help. It seems like too much Microsoft documentation is a little ivory-tower: heavy on conceptual and obvious stuff that I usually already know going in, and light on corner-case discussion (like the interaction between WDPs and Team Builds, e.g.). Also, there never seems to be a *quick reference* that I can print out and hang on my wall.

I guess what I'm saying is that I'm tired of poring over vast amounts of documentation that provides no help for problem after problem after problem. Especially when I hear the latch of vendor lock-in behind me.

I've made more progress (I'll post the specifics to another thread), but as always, there is yet another problem.

I'm giving Team Builds to the end of the day. If I can't get them working after two weeks, then screw them. I'm not letting this turn into our months-long Team Process Template debacle. There just isn't enough benefit to justify this amount of resources.




Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

That's encouraging, though I'm having trouble finding a command-line options reference.




Re: Team Foundation Server - Build Automation Another day completely wasted

Buck Hodges

Here's the documentation for the command line, tfsbuild.exe: http://msdn2.microsoft.com/en-us/library/aa337622(VS.80).aspx.

Buck






Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

As you might imagine, I saw that when I wrote it.




Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

So, where am I Nowhere, that's where.

After I got a trivial site working, I soon tried applying the Team Foundation Server Team Build to a more complex real-world app, but it's just been one error after another. I have had an enormous opportunity to waste a huge amount of time learning things as deadline after deadline passed. If I get fired, at least I will have spent a month and a half learning proprietary minutiae and ineffective workarounds likely to change soon.

I was able to spend weeks determining that TFS Source "Control" just plain doesn't integrate into VisualStudio. Oh, you still have to open VisualStudio to use it, which is incredibly convenient, and there are context menus in the "Solution" Explorer, but that's it. If you create a new project, or create a *.designer.cs file using the "Convert to Web Application Project" option (for example), Source Control does not add it to the project, nor does it offer to add it to the project, nor does it even list it as "unversioned" in the Source Control Explorer, nor is there any indication in the Solution Explorer that the new stuff hasn't been added, nor is there a menu item to add a project to Source Control. Source Control is content to just sit there uselessly. That is what Microsoft means by "integration".

I was able to spend some time learning what all the different web project types are for. Web Site Projects were a failed attempt to go without a project file, and to frustrate developers using the free versions of the web development tools. Web Application Projects were the bandaid for Web Site Projects, adding a project file to track the project settings. Web Deployment Projects are a wrapper for aspnet_merge.exe, which ignores the project settings in the Web Application Project, and just constantly looks for things to complain about. WDPs are what you want to try and use to publish from a Team Build, if you are able to get it to work.

I was able to spend a week determining that you don't want to version your bin folder, except when you do. You shouldn't version anything in your bin folder except 3rd party DLLs you browsed for. There doesn't appear to be a *.dll.refresh file anymore to tell the build system where to get the file.

I eventually learned that you have to check things out, or else you get an unhelpful Save As/Overwrite/Cancel/Help dialog. If you overwrite, Source Control will dutifully ignore this, meaning you still have to go back and check the file out, then check it back in. This is critical for solution and project files. If you aren't sure which files you've changed, you can check everything out, then check it in, but you have to enter your comment BEFORE Source Control will tell you if there were any changes. To view files on the filesystem that have not yet been added to Source Control (as anyone who has used TortoiseSVN is probably used to), you need to use the TreeDiff TFS PowerToy.

Why am I still nowhere
error ASPPARSE: Could not load type 'TheMasterPage'.
The type or namespace could not be found
The type or namespace could not be found

The local build works fine, and the WAP compiles fine, but the WDP fails. It's whack-a-mole: find one elaborate Rube-Goldbergesque workaround, and another error pops up.

At this point, I don't really expect to ever be productive with TFS. YMMV, but let my bleached bones serve as a warning.




Re: Team Foundation Server - Build Automation Another day completely wasted

Bhavik Shah - MSFT

I see that Aaron has already provided few msdn docs help link to you. However, I see following two missing so adding them here.

Following two tech notes explain how you could configure ASP .Net WEb Site and Web Deployment projects to get them build with team build.






Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

My problem is likely due to four factors: mixing a Web Application Project with dependencies on other projects in the solution, publishing to the server using a Web Deployment Project that appears to ignore the dependency defined in the WAP, and running the WDP from a Team Build.

If I run the WDP locally, everything works fine.
If I Team Build a WDP/WAP solution that does not depend on other projects, all is OK.
The WAP Team Build compiles just fine, though it doesn't contain the facilities to precompile the app or perform config file replacement.
I haven't tried converting the WAP back to a Web Site Project, but that seems like a major step backwards. I guess it's possible that WDPs may have only been designed to support WSPs.

I was able to address most of my Source Control issues using File > Source Control > Change Source Control. It turns out that a couple of the projects weren't properly added, even though I created them from the Solution Explorer.

But I really can't figure out why the build works locally, and not in the Team Build environment.





Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

Both of those links point to the same address, and I don't really understand how that article applies to my situation. I don't need to create a directory or virtual directory, and if I'm going to start using the <Exec> task, why wouldn't I just <Exec> a .cmd script that did all of the actual work It's a format I'm more familiar with, and wouldn't be any higher maintenance than peppering the MSBuild script with <Exec>, which really seems to defeat the purpose of the whole MSBuild environment (especially in this case, when a <Copy> task exists).




Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

Well, I was finally able to generate a test case (see WAP + WDP + project dependency + Team Build = no workee), and a co-worker suggested a workaround. I also updated Here's how to Team Build a Web Application Project to include the workaround, too.

My real-life project still won't build, of course. Maybe I need to continue messing with the path.




Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

I also notice your method for determining the value of the WebBinariesLocation property isn't going to work in my environment.

You might try:
Code Snippet

<PropertyGroup>
<WebBinariesLocation>$(SolutionRoot)\..\Binaries\$(Platform)\$(Configuration)\_PublishedWebSites\MyWebSite</WebBinariesLocation>
</PropertyGroup>



That will work unless the platform isn't part of the path, which seems to happen sometimes, or unless the solution folder is deeper than one level into the source control.




Re: Team Foundation Server - Build Automation Another day completely wasted

brianary

My two month nightmare is finally over. Today the final error (a recent permission issue) fell, and builds are working.

Much thanks to Aaron Hallberg, and his generalization of one of the workarounds I posted earlier, and to the VisualStudio team for their support early in this process.