Team System

Sharepoint Services error in Team Foundation Server RTM

Team Foundation Server automatically creates a SharePoint Services web site for each Team Project. However, post-install, we noticed that none of the SharePoint project sites would allow us to add new web parts from the gallery. Every time we tried to add a web part, we got this error:

An unexpected error has occurred. Web Parts Maintenance Page: If you have permission, you can use this page to temporarily disable Web Parts or remove personal settings. For more information, contact your site administrator.

I assumed we did something wrong in the install. I finally got around to testing this, and I found that a clean install of Team Foundation Server produces the exact same error. Shockingly, this is a problem every single customer will have with Team System!

Fortunately, there is a post-SP2 hotfix for Windows SharePoint Services, KB915746, that does fix the problem. We found the answer on this thread of the official VSTS forums.

We called Microsoft and obtained the hotfix. After installing hotfix 915746, our SharePoint project sites are fully functional: we can add Web Parts without error. I highly recommend all installations of Team Foundation Server pick up and install this hotfix for fully functional Team Project websites! If you can't stomach a hotfix, you'll have to wait for Windows SharePoint Services SP3 to be released-- whenever that will be.

Web Application Projects in Team System

While investigating a problem we were having internally with web application solutions in Visual Studio 2005 and Team Build server, I came upon the Web Application Project type for Visual Studio 2005. Wow, wish I found out about this one sooner and it was actually part of Visual Studio 2005! The new built in web application project in Visual Studio 2005 is ok, but it sure has a lot of quirkiness that makes it more troublesome than beneficial in my experience.

After playing around with the new Web Application Project (WAP from now on.. no not that WAP!) for a while, I discovered a couple of tips that might help others out there.

• In order to get the new WAP support in Visual Studio 2005, you will have to download and install a Visual Studio update and then the new project type:
  - Visual Studio Update
  - Visual Studio 2005 Web Application Projects
  
  
• Creating a new web application project is the same steps as in Visual Studio 2003: you create a new Web Application Project through File > New > Project instead of File > New > Web Site.
  

  
  
  

• The WAP type does work with temporary projects, but you will have to close and reopen your project once you save it to a real folder. If you attempt to run your project after saving it to a folder, you will get a couple of nasty error messages:
  

  
  
  
  
  
  
  Looks like the references aren't updated when you save to a real folder. Smells like a bug to me. ;)

What's nice about having a WAP type is everything works just like VS2003 again. You know exactly where your project settings are saved and you don't have to go through any special menu options. For example, the original way of enabling code analysis for web applications was through the Website menu option. Totally unintuitive. Now with a WAP, it's through the traditional Project Properties dialog. Much better!

Another awkwardness with the original web application type is being forced to checkin files into your source control just because those files are in the same directory as your web app. The WAP type finally fixes this problem since it now knows exactly which files are part of your project and which are not.

Thankfully, the best benefit of VS2005 web application projects carry over to the WAP type in that you don't need to use IIS for debugging. You can still use the webdev server!

So back to the original problem of web applications and Team Build. One of the reasons why we found out about WAP is the explicit support for Team Build. In fact it's the first bullet point!

After messing around with my test project, I found that it indeed does support Team Build, but not out of the box. Issue 6 in the Web Application Project FAQ mentions that the build server needs a copy of the WebApplications build target in order to support the build. Otherwise the build will fail with a

The imported project "H:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" was not found.

error message. Just copy your local C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications folder to the build computer (in the same location) which should fix this problem.

What gets built is the single DLL of your web application and also a release build of your entire website in the traditional VS2003 format: ASPX files, DLL files, and any other files you want included. If you would like a VS2005-like web application build (ie. not updatable, precompiled), then you will need to also use the Web Deployment Project.

Here's some other links/resources to read up on to learn more about Web Application Projects in Visual Studio 2005:

• Scott Guthrie has a listing of all the features and a detailed walkthrough of a web application project.
• FAQ and Known Issues on Web Application Projects.
• Whitepaper on Web Application Projects.

Installing the Check for Comments Check-In Policy

Why doesn't Team System include a "must have comments" policy for check-ins out of the box? I have no idea. It seems like an obvious oversight to me, but it doesn't.

But the good news is that it's relatively easy to install the missing comment policy.

In a previous entry on adding a new check-in policy, I provided the source code for a comment policy. I re-packaged that source into an easy one-click installer:

• Download the Team System Check for Comments Policy installer (140kb)
• Download the Team System Check for Comments source code (11kb)

Once you install this policy, it can be enabled for the entire Team Project. Enable it through the Team, Team Project Settings, Source Control Settings dialog. Once you enable the code comments policy, developers who have the policy installed will see this:

And developers who don't have the policy installed will see this:

In other words, developers who don't have the policy installed will be treated to a mandatory checkin policy failure on every single checkin. If that's not enough motivation to install the proper policy, I don't know what is..

How do I build a Team Project with shared code?

One question that comes up a lot in Team System deployments is "how do I share code across team projects"? The easiest way to accomplish this is to set up a Team Project specifically for common, shared code. Here's a simple example of this scenario.

We have one Team Project for ClientApp, and a second Team Project for CommonUtils. ClientApp is a console application that references CommonUtils.

These projects will share a common path on the hard drive:

• c:\tfsprojects\ClientApp
• c:\tfsprojects\CommonUtils

And they'll have workspace mappings to those local hard drive paths:

Source Control Folder	Local Folder
$/ClientApp	c:\tfsprojects\ClientApp
$/CommonUtils	c:\tfsprojects\CommonUtils

CommonUtils is a Class Library project with a post-build event to copy its output to a \binaries folder:

The resulting path is c:\tfsprojects\CommonUtils\CommonUtils\binaries\CommonUtils.dll. The ClientApp project will reference this DLL:

We can now create a Team Build for ClientApp.

However, this build will fail! Team Build cannot figure out the shared DLL reference and thus throws an error. The build output log shows the exact error:

warning MSB3245: Could not resolve this reference. Could not locate the assembly "CommonUtils". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors

However, we can fix this. Thanks to a helpful post by Manish Agarwal, we know how to edit the TFSBuild.proj script to fix this. Check out the clientappbuild build script from Source Control Explorer, and begin editing.

1) add these variables to the PropertyGroup section:

<!-- to be added under PropertyGroup -->
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

2) add these ItemGroup entries which map both Team Projects and both solutions:

<ItemGroup>
  <!-- add one entry for every solution we reference -->
  <SolutionToBuild Include="$(SolutionRoot)\CommonUtils\CommonUtils.sln" />
  <SolutionToBuild Include="$(SolutionRoot)\ClientApp\ClientApp.sln" />
</ItemGroup>

<ItemGroup>
  <!-- add one entry for every Team Project we reference -->
  <Map Include="$/ClientApp/ClientApp">
    <LocalPath>$(SolutionRoot)\ClientApp</LocalPath>
  </Map>
  <Map Include="$/CommonUtils/CommonUtils">
    <LocalPath>$(SolutionRoot)\CommonUtils</LocalPath>
  </Map>
</ItemGroup>

3) hook up the BeforeGet event to retrieve the workspaces for each Team Project, too:

<Target Name="BeforeGet">
  <DeleteWorkspaceTask
      TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
      Name="$(WorkspaceName)" />
  <Exec
    WorkingDirectory="$(SolutionRoot)"
    Command="&quot;$(TfCommand)&quot; workspace /new $(WorkSpaceName) /server:$(TeamFoundationServerUrl)"/>
  <Exec
   WorkingDirectory="$(SolutionRoot)"
   Command="&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;"/>
  <Exec
    WorkingDirectory="$(SolutionRoot)"
    Command="&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot;%(Map.LocalPath)&quot;"/>
</Target>

Check in the build script, execute it, and now we have a successful Team Build of a Team Project that references a DLL in another Team Project:

And our build output folder contains what we would expect-- the application DLL, and the shared dependency DLL, too:

(Thanks to Eric Cherng for his help in writing this blog post!)

Enabling Code Analysis for Web Projects

Code Analysis is a standard feature of the Developer edition of Visual Studio Team System. It's easy to enable; just visit the Code Analysis tab on the project properties page.

However, web projects aren't like other types of projects. To enable Code Analysis for Web Projects, you have to use the Website menu.

Bear in mind that the Website menu is only available when the Web project is selected in Solution Explorer.

From the Code Analysis Configuration page, we can switch on the various rules:

I know this seems trivial, but I've struggled with it multiple times. It's difficult to remember where the Code Analysis options are for web projects-- they're in a completely different place!

Why did Microsoft create Team System?

It's sort of an open industry secret that Microsoft created Team System to address the shortcomings of their existing internal tools* and processes. There's an excellent new whitepaper on Microsoft's site, Deploying Visual Studio 2005 Team Foundation Server as an Enterprise-Wide Service Technical Case Study, that explains:

Microsoft has tens of thousands of software developers, usually working on over a thousand development projects. Project teams can consist of project managers, business analysts, application architects, software developers, and software testers.

In the past, the project teams found it difficult and time-consuming to coordinate their efforts because their tools were not well integrated with each other. The project teams closely coordinated their products (output) to help ensure compatibility and interoperability, but, in the past, did not coordinate or integrate their project planning or reporting to a high degree. All the project teams used similar methodologies and tools, but these were usually somewhat different and generally not integrated.

Each project team developed and executed its own project plan, sometimes using nonstandard methodologies. Within the projects' separate project plans, there were often variations in the work items being tracked or different definitions of the same tracked work items. For example, the definition of how to calculate "percent of work completed" would vary significantly between projects. Some projects tracked "bugs," whereas others tracked "defects"; some scheduled according to an 8-hour day, and others scheduled according to a 10-hour day. Work items were tracked separately within each project.

The smaller development teams used commercially available products, such as Microsoft Visual SourceSafe, for source control and version tracking. Larger teams used a set of internally developed tools for work item tracking, source control, version tracking, and bug tracking. These tools were all operated separately, on separate servers, and were difficult to manage. The IT groups planned infrastructure for each project's tools separately. The architecture and infrastructure made integration very difficult.

Each project team had to deal with separate support teams for each tool. Each tool-centered support team had to deal with hundreds of project teams. There was some confusion about which support team was responsible for which problem. Each project team had to arrange separately for production and management of its Microsoft Windows SharePoint Services collaboration site. The team had to work with a separate SharePoint Services group to build and host the project's SharePoint portal. This portal was not integrated into the source control or bug tracking systems. Information had to be manually transferred to the SharePoint site, or some custom automated integration had to be built.

Each project team also had to construct and manage its own build machines and test rigs. The test rigs were not standardized or stored, so they were different for each project team. The build system used custom scripts and tools constructed around the internal source control system. Each team had to manually manage the build process. The results from the separate projects were not coordinated.

It was impossible to report across projects. For project tracking at higher levels of the organization, the individual project summaries had to be collected and manually compiled into reports, or customized automation had to be built. There was much duplication of reporting efforts. Because there was so much variation in information between projects, including the item definitions, it was difficult to relate items—work items, processes, artifacts—or confidently compile summary information. Much of the important communication within and between projects was not captured, because it was performed on the telephone or in face-to-face communications.

The cross-project reporting problems made it difficult for upper management to make informed decisions about the various projects individually or development projects as a whole. There was no operational transparency into a project's details. Also, the reporting problems made it difficult and expensive to comply with statutory requirements, such as Sarbanes-Oxley, which requires proof of "an adequate internal control structure."

The good news is that Microsoft is "dogfooding" Team System right alongside its customers. They're using it heavily; more and more Microsoft internal projects are transitioned to Team System each day. And many of the improvements-- like those cited in the latest Brian Harry dogfooding stats-- will trickle down to customers in the form of service pack 1.

The bad news is that your organization may not have "tens thousands of software developers" like Microsoft. Microsoft's problems may not be your problems. But if you develop a lot of software, it's highly likely you're struggling with many of the same issues-- and Team System can help.

* Including Source Depot, Product Studio, etc