Resources for Building ASP.net Applications with VSTS/TFS

  • Article

I often hear that our customers hit challenges when developing ASP.net applications with VSTS and TFS. I’d like to kick off a dialog with a goal of identifying the key pain points so that we can deliver guidance to eliminate, or at least mitigate that pain.

Managing Web Application Sources in TFS Version Control

Our Patterns & Practices team has a guide on how to Structure ASP.net Applications in TFS. It was, however, originally written for TFS 2005 and assumes that you’re working with a Web Site Project rather than a Web Application Project (see below). Fortunately, working with Web Application Projects in version control is straightforward since they are structured like most other common project systems in Visual Studio. You may also want to review Team Development with TFS and the TFS Branching Guide 2.0.

Generally, you won’t want developers publishing changes to an instance of your ASP.net application directly from their machines unless that instance is in their own personal sandbox. Rather, the automated build should deploy the application to a test or staging environment as appropriate (more on deployment later in this post). Also, be sure to use the tilde (~) in virtual paths referenced in server controls rather than referencing a specific server name so that those paths will resolve correctly on everyone’s machine (including the build machine).

Web Application Projects vs. Web Site Projects

Visual Studio 2005 introduced a new, and somewhat controversial Web Project System that’s now commonly referred to as “Web Site Projects.” Scott Guthrie has provided a thorough overview of that project system. Unfortunately, Web Site Projects are not directly supported by MSBuild and Scott’s original recommendation was to add a “build helper project” to the same solution that you would customize to implement your build process. For many users, however, this solution was less than ideal and in response to customer feedback, the ASP.net team released Web Application Projects in May 2006.

In Visual Studio 2005, Web Application Projects are compiled into a single assembly using an MSBuild-based compilation process. This made it much easier to migrate Visual Studio 2003 web projects to Visual Studio 2005 (and .NET 2.0) while making it possible to build ASP.net 2.0 projects with Team Foundation Server 2005. Visual Studio 2008 included support for both Web Site Projects and Web Application Projects leaving it up to the user to decide which was the best fit for their needs. Maor David provides a succinct summary of when to use which model. Rick Strahl shares his experiences with transitioning to Web Site Projects and Web Deployment Projects in greater depth.

ASP.net Application Deployment

In parallel with the evolution of the ASP.net project system, users were looking for ways to simplify and, ideally, fully automate deployment of their web applications. There were competent third-party solutions for Visual Studio 2003, but there wasn’t anything in-the-box with Visual Studio 2005. The ASP.net team partially addressed this need with Web Deployment Projects which was meant to prepare your application for deployment via the Copy Web Site or Publish Web Site features. Deployment Projects weren’t included with Visual Studio 2008, but support was released in January 2008.

Web Deployment Projects can be used with either “Web Site” or “Web Application” projects in Visual Studio 2005 and 2008. Scott Guthrie has a tutorial on VS 2005 Web Deployment Projects which also applies to Visual Studio 2008, though there are some new features in the 2008 version. There are, however, issues with Team Build and Web Deployment Projects.

Deployment continued to be a pain point for ASP.net developers and Microsoft broadened its efforts to simplify the process by partnering with the IIS team. As of this writing, Beta 2 of the Web Deployment Tool is available for download (in x86 and x64 flavors). This tool creates a package that contains “content, configuration and SQL databases for deployment or sharing with others.” It supports IIS 6.0 and 7.0 and is included with Visual Studio 2010 as well as the Web Platform Installer. We are actively working with the ASP.net and IIS teams to make sure that this tool will work well for teams using Team System and Team Foundation Server.

Building ASP.net Applications with TFS

There are a number of things to keep in mind when building ASP.net applications with TFS 2008. You’ll generally want to install the Development and Test Editions of Visual Studio Team System (or Team Suite). With regard to licenses, your build machine doesn’t need licenses for these (or any) editions of Team System so long as the person creating the build definition in TFS does. You will, however, need a TFS CAL for the build machine. Having the Development and Test Editions installed on the same machine as the Build Agent will enable you to run unit tests and perform code analysis as part of your automated build.

If you are using VSTS/TFS 2005, be sure to apply Visual Studio 2005 Team System SP1 and Team Foundation Server SP1, which includes support for Web Application Projects, to your build machines. If you encounter error MSB4019, you will need to manually copy a targets file to your build machine. You will also want to install Web Deployment Projects for VS 2005 on the build machine if you plan to use deployment projects. If you’re using VSTS/TFS 2008, Web Application Project support is included with the Development and Team Suite Editions of VSTS, but you’ll need to install Web Deployment Projects for VS 2008 on the build machine to successfully build those.

If you plan to run automated unit tests of your web application as part of your automated build process, you may want to familiarize yourself with the development web server that’s included with Visual Studio. Team Build uses it to run automated tests for ASP.net applications. It differs from IIS in some significant ways, like dynamically selecting a port to run on. Note that it’s also possible to switch between IIS and the Developer Web Server in your Web Application Project. Brian Orrell has a concise example of how to unit test ASP.net pages with Team Build.

If you work with Web Site Projects and Web Application Projects you may have noticed that they have different default platforms (“.NET” for Web Site Projects and “Any CPU” for Web Application Projects). Team Build deals with solution configurations which map to distinct configuration and platform for each project within that solution. You’ll want to make sure that the Team Build project file (TFSBuild.proj) is configured to build the “Any CPU” flavor of your configuration. Joel Semeniuk talks more about configurations in his blog post on Automating Web Site Builds with Team Build.

Where do we go from here?

What pain points have you encountered with ASP.net applications and TFS? Let me know either by posting a comment here or by contacting me directly and I’ll do my best to help you find a solution. Of course you can also post your question on the Build Automation MSDN Forum, which my teammates and I visit on a regular basis.