A common request for ASP.NET projects that are using Team System is to have a "new bug" webform. This way, customers or users have a way to get their bug submissions directly into Team System.

I whipped up a quick little "hello world" demo of an ASP.NET webform that connects to Team System and enters a bug on behalf of the user. It's a single page plus a configuration section, with some basic error handling logic in case something goes wrong.

Download the Visual Studio 2005 solution (7kb)

It's intentionally simple as is, but you could easily extend it to add more complex work items with attachments, and so forth.

The web.config looks like this:

<configSections>
  <sectionGroup name="TFS">
    <section name="Server" type="TFSConfigurationSection, TFSWebDemo"/>
  </sectionGroup>
</configSections>

<TFS>
  <Server server="http://tfsserver:8080" userName="username" password="password" domain="domain" project="projectname" />
</TFS>

Be sure to edit this to select the right server, user, and project. Note that you may need to grant permission to the 'C:\Documents and Settings\Default User\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache' folder for the user specified in web.config. Or at least, I did on our web server.

Recently, I was asked whether Team Foundation Server works in a 64-bit environment.

The answer to this question depends on whether you have a dual-server TFS install, or a single-server TFS insall.

If you have a single-server TFS install, you must use a 32-bit operating system.

If you have a dual-server TFS install, some parts of TFS can be installed on a 64-bit operating system:

• The data tier fully supports 64-bit. You can use a 64-bit edition of SQL Server to host the TFS databases.
• The build server and Visual Studio 2005 can run fine under the WOW64 emulation layer on any 64-bit edition of Windows.
• The application tier must be installed on a 32-bit edition of Windows.
• The Team Proxy must be installed on a 32-bit edition of Windows.

I imagine TFS will be more fully 64-bit in the next release. But for now, at least you can take full advantage of a 64-bit operating system for the database portion of TFS.

Here's what to do when you're adding an Active Directory user to a Team Project and you run into this error:

Team Foundation server could not resolve the user or group (name). The user or group might be a member of a different domain, or the server might not have access to that domain. Verify the domain membership of the server and any domain trusts.

As documented in this forum thread, this error usually occurs when the client attempting to add a user to a Team Project doesn't have the same domain permissions as the Team Foundation Server.

The first thing to try is adding the user via the Team Foundation Server. Log in to the server and either use the tfssubscribe.exe command line tool, or if Visual Studio 2005 is installed on the server, add them that way. But make sore you do this on the server.

If adding the user works on the server, but doesn't work on the client, then you know it's due to the difference between client domain permissions and the TFS domain permissions.

UPDATE: Don't forget to check the credentials of the TFS service accounts. If the TFS service account password has expired, or if the TFS service account is otherwise invalid, you can see this error message as well.

I found out last week that the Team Build server doesn't perform the essential Publish step that makes a ClickOnce app, well, a ClickOnce app!

But this is easy enough to fix.

Let's start with a simple Hello World ClickOnce app that has one shared DLL dependency. If we do a Team Build for this app, we get the following files in the drop folder:

OneClickApp.application
OneClickApp.exe
OneClickApp.exe.manifest
SharedLibrary.dll

Notice anything missing? To be fair, even in the Visual Studio 2005 IDE, Publish is a seperate step from Build that you must manually invoke via a different menu.

Even if you're building and publishing the project remotely on the build server, you must Publish locally at least once, so all the Publish preferences are stored in the project files.

In order to Publish a project on the Team Build server, we have to make a small edit to the tfsbuild.proj file. Under the SolutionToBuild XML element, add a SolutionToPublish element:

<ItemGroup>
  <SolutionToBuild Include="$(SolutionRoot)\OneClickApp.sln" />
  <SolutionToPublish Include="$(SolutionRoot)\OneClickApp.sln" />
</ItemGroup>

Check this change in, then try rebuilding. Now the drop folder contains the Publish results, too:

OneClickApp.application
OneClickApp.exe
OneClickApp.exe.manifest
SharedLibrary.dll
OneClickApp_1_0_0_0\OneClickApp.exe.deploy
OneClickApp_1_0_0_0\OneClickApp.exe.manifest
OneClickApp_1_0_0_0\SharedLibrary.dll.deploy
setup.exe

See all the new files at the bottom? With that small edit, this build is now functionally equivalent to a local Build plus Publish.

After building a web project in a Team Build, you probably want to deploy that website to a target server. And what better place to do this than in the build scripts themselves?

This is pretty easy to do; we'll just customize the AfterBuild event to XCOPY the contents of the \_PublishedWebsites folder somewhere. Note that you must grant permission for the Team Build account to the target UNC path first-- otherwise the copy will immediately fail!

There are two slightly different ways to do this, depening on what kind of web project you chose.

If you are using Web Application Projects, you'll need to edit the project file. The easiest way to do this is to right-click the project and select "Unload". After doing that, you can right click the unloaded project and edit the project file directly within Visual Studio:

Edit the project file to include the following command. The variable $(WebProjectOutputDir) conveniently includes the exact path we want:

<Target Name="AfterBuild">
<Exec Command="xcopy /y /e &quot;$(WebProjectOutputDir)&quot; &quot\\remote\share&quot;"/>
<Target>

Target AfterBuild:
xcopy /y /e "c:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\
WebApplication1" "\\remote\share"
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\Default.aspx
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\Web.config
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\SharedLibrary1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\SharedLibrary1.pdb
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebApplication1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebApplication1.pdb
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebService1.dll
C:\builds\Demo\WebApplication1\Binaries\Release\_PublishedWebsites\WebApplication1\bin\WebService1.pdb
8 File(s) copied

If you are using Web Site Projects, you must have one Web Deployment project for each Web Site. Until you do, there's nothing to edit, and nothing to deploy. You'll be editing the Web Deployment Project directly: right click it and select "Open Project File" to begin.

It's almost the same as the previous XCOPY command, except the variable you want this time is $(WDTargetDir). Unfortunately this path includes a trailing slash, so we have to add a period afterwards to indicate that we want to copy the contents of the folder.

<Target Name="AfterBuild">
<Exec Command="xcopy /y /e &quot;$(WDTargetDir).&quot; &quot;\\remote\share&quot;"/>
</Target>

Target AfterBuild:
xcopy /y /e "c:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\
WebSite1_deploy\." "\\remote\share"
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\Default.aspx
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\PrecompiledApp.config
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\web.config
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\App_WebReferences.compiled
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\SharedLibrary1.dll
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\SharedLibrary1.pdb
C:\builds\Demo\WebSite1\Binaries\Release\_PublishedWebsites\WebSite1_deploy\.\bin\WebSite1_deploy.dll
7 File(s) copied

You could achieve the same effect by modifying a post-build event in the Team Build script, but I find it easier to modify the individual projects.

If you're still using Web Site projects, I strongly urge you to switch to Web Application Projects. Web Application Projects are included in Visual Studio 2005 Service Pack 1. There are lots of good technical and practical reasons to make the switch, especially in Team System. But I digress.

If you're still using Web Site projects, you'll have to make some modifications before you can build these projects using Team Build.

In order to build a Web Site project at all, you must add a new project type to your solution-- the Web Deployment Project. It's a new project type that you'll need to download from Microsoft and install. But don't worry: it's a very small download, and a quick, painless install.

Once you have Web Deployment Projects installed, right click each web site and select "Add Web Deployment Project".

Once you have the deployment projects set up, make sure they're deselected in Configuration Manager for the Debug builds. There's no need to waste compile time on deployment until you're ready to create a release.

After you do a Team Build for this project, you should see a new _PublishedWebsites folder in the drops folder that contains the website and dependencies:

Now, this is the behavior you'll get by default with a Web Application project, but for each Web Site project, you must have one Web Deployment Project in place to get things working.

If you're testing a complex new team build, you may find yourself going through a lot of build cycles. This can be painful, because most complex builds also take a while to complete.

To speed up the build process, you can skip some parts of it. You can do this in one of two places. First, in the TFSBuild.proj, you can insert these elements in the PropertyGroup:

<!-- insert in PropertyGroup -->
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
<SkipWorkItemCreation>true</SkipWorkItemCreation>
<SkipLabel>true</SkipLabel>
<SkipPostBuild>true</SkipPostBuild>

Alternately, you can edit the TFSBuild.rsp file to achieve the same results:

# This is a response file for MSBuild
# Add custom MSBuild command line options in this file
/p:SkipClean=true;SkipInitializeWorkspace=true;
ForceGet=false;SkipWorkItemCreation=true;
SkipLabel=true;SkipPostBuild=true 

(Note the above should all be on a single line; I broke it up for ease of display.) What are we skipping here? Well, we skip...

• .. deleting the source code folder
• .. doing a "force get" of the source code, so we use the code that's already present on disk
• .. labelling after completing the build
• .. compiling a list of work items that changed in the build
• .. creating a work item when the build fails

But despite all the skipping, the essential part of the build still completes. And that's usually what we're trying to troubleshoot.

(thanks to Dave McKinstry and Omar Villarreal for these tips!)

Build engineering is one of the most challenging parts of Team System. It can be difficult to get a Team Build working exactly the way you want. When you're troubleshooting a build, the build log output file, BuildLog.txt, is your best friend.

The build log is fairly helpful as-is, but it's possible to make it even more verbose in those times when you're troubleshooting an obscure build problem.

Visual Studio, like Team Build, also uses MSBuild under the hood to compile solutions. In Visual Studio, you can set the build verbosity via a handy IDE setting. It's under Tools, Options, Projects and Solutions, Build and Run. The "MSBuild project build output verbosity" field offers four values: Quiet, Minimal (the default), Normal, Detailed, and Diagnostic.

You can also set verbosity via a Team Build script.

MSBuild.exe supports the verbosity command line parameter:

/verbosity:<level;> Display this amount of information in the event log.
                   The available verbosity levels are: q[uiet], m[inimal],
                   n[ormal], d[etailed], and diag[nostic]. (Short form: /v)
                   Example:
                     /verbosity:quiet

All we need to do is edit the TFSBuild.rsp file in our TeamBuildTypes folder to pass this parameter on to MSBuild.exe:

# This is a response file for MSBuild
# Add custom MSBuild command line options in this file
/v:diag

Check TFSBuild.rsp in, and then do a build. The resulting BuildLog.txt will be much more.. er.. verbose!

Here are the results of running a build for each verbosity level:

The default verbosity level for Team Build is normal, so be careful when ratcheting it all the way up to diagnostic!

The Team Alerts dialog lets you subscribe to basic email alerts on a Team Project.

But the dialog is severely limited; the full richness of the email subscription mechanism in Team Foundation Server isn't available. To set up advanced subscriptions, you needed to use bissubscribe.exe. This is problematic, because the command-line syntax is complicated, and also because bissubscribe.exe is only available on the Team Foundation Server.

To address this deficiency Naren posted a GUI tool that lets you create Work Item Event Subscriptions in July 2006. I took that tool and modified it so that it supports all event subscriptions, along with a bunch of other enhancements The new Team Foundation Server Event Subscription Tool is up on CodePlex now.

Some examples of subscriptions you might want to create are:

Email me when any new work item is created:

PortfolioProject = 'TeamProject1' AND ChangeType = 'New'

Email me when any work item moves to the resolved state:

"CoreFields/StringFields/Field[ReferenceName='System.State']/NewValue\" = 'Resolved'

Email we when a specific (string) field changes in a work item:

PortfolioProject = 'TeamProject1' AND "ChangedFields/StringFields/Field[ReferenceName='field']/NewValue" 
 null


Email me when someone checks source code into a specific folder:

'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject1/A\")]' 
 null


Email me when someone overrides a checkin policy:

TeamProject = 'TeamProject1' AND PolicyOverrideComment 
 ''


The queries are all based on XPath applied to the Event XML. As you can see, it's quite powerful-- far more powerful than the simplistic Team Alerts dialog would lead you to believe!

“In addition to our summer and winter estate, he owned a valuable piece of land. True, it was a small piece, but he carried it with him wherever he went.”

From Woody Allen’s Love and Death.

So, what HAVE we been spending our time on? Our little piece of the Windows Vista operating system.

For the last 20 months we’ve been building the digital locker assistant (DLA), a dedicated download client that works with Microsoft’s online digital locker, which is in turn part of Microsoft’s Windows Marketplace.

Windows Marketplace supports direct browser based downloading. However, when the download is greater than 1-2 Gigabytes using the DLA is a much better way to go. The most popular use of the DLA so far has been buying and downloading entire copies of Windows Vista and Office 2007.

We were rather skeptical that users would want to download Vista or Office since they are really big downloads but earlier in the year the success of selling and downloading of super large games from Windows Marketplace convinced everyone that downloading Vista would be attractive to consumers.

You can get the digital locker assistant two ways: If you have Windows XP, go to the Windows Marketplace website, create an account and download and install the MSI. It’s only a 1 meg download.

Or, it’s built into every copy of Windows Vista (except Server versions).

Actually building a part of Windows Vista was a huge effort but it’s really neat to install Vista and see our little piece in there.

I was the dev lead for the DLA for XP and Vista. Two very senior Windows developers with me at Vertigo, Chris Idzerda and Ralph Arvesen, rounded out the dev team (that is, they actually did most of the work). Initially, I was dev lead and PM but soon we needed more help with the process and got a full-time program manager, Anne Warren, who was also PM for the Windows Marketplace (WMP) website. The website dev team was some 15 developers and we had a build team of one (that should have been three). Our test team was in India so the dev/test cycle was almost 24/7, something like 24/6 – we’d hand off work in the afternoon and it would be tested all (our) night with a nice bug list waiting for us in the morning.

And then there’s the rest of the Vista team at Microsoft: really a cast of thousands. I think they ALL emailed me at least once. The High DPI functionality team. The Localization team (“do you know your UI looks really bad in Arabic?”), the Group Policy team, Remote Desktop team… you get the picture.

Let’s look at the app

In Vista there are two ways the digital locker assistant (DLA) may be invoked. The primary way is when you buy something at Windows Marketplace and it’s in your digital locker and you click “download.”

You may also browse to the DLA by finding it under the Vista Control Panel.

Then look under Programs or Programs and Features (using Classic view) and find “Manage programs you buy on line.” If you open this link you will invoke the DLA and if you have never sync’d up with your online digital locker you will see this:

If you have software in your online digital locker you can see it listed here by clicking on “Sign in if you already have a digital locker account.” Digital locker accounts are Windows LiveID (a.k.a. Passport) accounts mapped to a Windows Marketplace account. You’ll get a login prompt:

and after synchronizing with your online digital locker you’ll see all your purchased, free, and trial items listed. In my case (below) I clearly have a bunch of games in my locker. These were just to test downloading large items. Right.

Technology under the covers

The DLA is built in Win32/C++ as an ATL Windows application but we get some goodies from WTL as well. For those going “huh?” look at my post ATL and WTL resources.

At this point most people are asking me: why C++? Why not .NET and/or WPF? Or, if you’re using C++, why not MFC?

The DLA started (and is still available) as a downloadable application for XP. Our target users are what Alan Cooper would call “permanent beginners” (like that relative that always calls you for tech support…) — with a modem.

This means making the download as small as possible. Vertigo is a premier .NET shop but we could not use .NET because the 22 MB .NET runtime install kills us (that .NET never made it into the XP Service Packs… argh). Fortunately, we happen to have a few developers around (i.e., old geezers) who can do C++. We used ATL again to keep the size of the executable small.

In hindsight, it was just as well that the XP effort started in C++. Once we expanded the project to include being built into Vista we found that, in Windows System programming and the Vista source tree, C++ is expected and still king (See my post Has Microsoft flipped the Bozo bit on .NET? for a full discussion).

This meant that we could develop one source code base and, with some care, make it build in the Windows OS build system for Vista and VS2005 for XP.

Single source is nice but why not make a single binary that runs on Vista and XP? Sigh. We do — sort of, but it’s complicated.  From a programmer’s perspective, Vista makes one dramatic change from traditional Win32 applications and that’s in how localized resources are loaded.

To handle localization traditional Windows practice is to create an RC file for all resources (dialogs, images, sounds, strings, keyboard shortcuts, etc.) which are compiled into the resource DLL. Localization teams produce localized RC files based on your master RC file and these are all built into a suite of resource DLLs. At run time the application loads the appropriate resource DLL based on logic you have to write which looks at the calling thread’s locale settings.

Internal to the application is a language-neutral block of resources (typically English-US based) and if an appropriate external resource DLL cannot be found for the current locale settings, this internal block is used instead. This is known as “fallback” behavior.

Here’s the new twist in Vista: in Vista the OS loader (not the app) picks the resource DLL and locates it in memory where the app thinks its internal fallback resources are. This is expected behavior and currently only appears to work for a native Vista-built application so our “legacy” resource loading technique as used in XP was not acceptable to those who guard the Windows Source tree. Did I mention all the code reviews? Making Vista-style resource loading work in XP, while theoretically possible, was a task we did not choose to take on. So we ended up with one set of source code feeding two build processes; one for XP and one for Vista. Through careful coding there are remarkably few “if Vista do this, if XP do that” points in the code. 

While we currently block running the XP installer on Vista (in theory blocking installation of the XP DLA on Vista), it turns out that the XP DLA runs fine on Vista. I should not be suprised by this becuase we did quite a bit of casual sanity testing on this but it was not initially part of the test matrix. We found out by somewhat by accident as users were upgrading their XP machines (where the user had added the XP DLA) to Vista and then running the XP DLA.

For our downloading mechanism we hand off all download jobs to Microsoft BITS (Background Intelligent Transfer Service). While BITS works well for us I still think Micorsoft is tempting the gods by including “Intelligent” in their product name. BITS is the guts behind hwo Microsoft Updates are downloaded. I’ve also discovered that Google Updater uses BITS as well. What we gained by using BITS was automatic download management including background downloads, downloads that persist when our application is not running, downloads that seamlessly restart when the machine is rebooted, and lots of error handling algorthms that we did not have to write or maintain. I’d use BITS again if needed. We did have to build a simple HTTP download as well because some modem-based accelerators do not play nice with BITS.

Overall it was a great experience. While it is a chaotic, exhausting process it was a lot of fun too. 

I’d do it again.

Really.

After I’ve had a couple years to rest.

I recently ran into a problem with a local TFS server. Although I was logged in as my local account, TFS insisted that I was logged in as Administrator. Since the server thought I was a different user, it prevented me from opening my local workspace with this error:

The path is already mapped in workspace

The path conflict error reminds us of one important fact about workspaces: only one local path can be mapped, per user, per team foundation server. Two users can't share the same filesystem path. And two different team foundation servers can't share the same filesystem path, either.

The system caches your workspace mappings in this location, so if you're having workspace-related problems, it's worth clearing this cache file out:

C:\Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\VersionControl.config

As Buck Hodges points out, you can also clear the local cache file at the command-line:

tf workspaces /remove:*

But clearing the cache didn't help in my case. No matter how much I cleared, how many times I rebooted or logged off, I kept showing up as "Administrator", which means I was conflicting with myself! I could map to a new folder, but that's not what I want. How is this possible?

Well, it's possible if you physically log in to the Team Foundation Server using a different set of credentials. Those credentials are cached deep in the bowels of Windows, and retrieved automatically the next time you contact the server. That's our problem!

To clear the credential cache, try Start, Run, then type

control userpasswords2

And press enter. On the resulting dialog, click the advanced tab, and click Manage Passwords. Remove all cached credentials from this list.

Once I cleared the cached credentials, I was able to access the Team Foundation Server as myself again. Problem solved.

With this in mind, if you must log in to the Team Foundation Server, try to do so under your own credentials. It'll cause less problems later.

One annoying thing about Team Builds created through the Team Build wizard is that they pull down all the source code in the entire Team Project by default. This is almost never what I want. But it's easy enough to fix.

First, check out the TFSBuild.proj and WorkspaceMapping.xml files from the TeamBuildTypes folder in source control.

Remember, the build user is just a user, exactly like you. And it has workspace mappings, just like you do. But in this case the workspace mapping is too broad. It's at the root of the Team Project. Let's fix that by editing WorkspaceMapping.xml. Change it from this..

<Mappings>
  <InternalMapping ServerItem="$/TeamProject1" LocalItem="C:\does-not-matter" 
    Type="Map" />
</Mappings>

To this..

<Mappings>
  <InternalMapping ServerItem="$/TeamProject1/DemoBuildWebApp"
    LocalItem="C:\does-not-matter"
    Type="Map" />
</Mappings>

All we're doing is adding the Solution folder to the Team Project path. This is the key fix-- until we do this, the build user will get latest on the entire source tree. That's no good.

Two additional notes about the build user workspace mapping file:

• If you do have a legitimate need to pull down a giant source tree, you can make it a little less painful by cloaking (aka hiding) some of the subfolders here.
• The path specified here is truly irrelevant. I changed it to C:\does-not-matter to make a point. The local path is always the server build folder, so whatever you put here is completely ignored.

Next, we need to update our compilation path to reflect the fact that it's no longer in a subfolder. Edit TFSBuild.proj and modify this section from..

<SolutionToBuild Include="$(SolutionRoot)\DemoBuildWebApp\DemoBuildWebApp.sln" />

To this..

<SolutionToBuild Include="$(SolutionRoot)\DemoBuildWebApp.sln" />

Now check in the changes, re-build, and you'll see in the build report and the build folder that only the specific source in the solution subfolder was retrieved. Big improvement!

You can display Team System reports in the Team Portal using the default Page Viewer web part, which redirects to the URL

_layouts/tfsredirect.aspx?IsReport=1&ReportName;=name

But there's a better way.

I recommend installing the SQL Server 2005 Reporting Services Web Parts. They're already on your server, but they're not set up. To set them up, run this command on your Team Foundation Server web tier:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN\
STSADM.EXE -o addwppack -filename 
"C:\Program Files\Microsoft SQL Server\90\Tools\
Reporting Services\SharePoint\RSWebParts.cab"

Once you do this, you'll have two new Web Parts specifically designed for reporting, so you no longer need to rely on the generic Page Viewer. Note that the new controls are in the "Virtual Server Gallery":

Here's the Report Explorer web part in action

And here's the Report Viewer web part in action:

The report gadgets work better. They offer much more control over the report output. For one thing, if you set any parameters to the report in design mode, those parameters are saved. You can also turn off the toolbar so the report comes up pre-configured to whatever parameters you last set.

Note that you will need to bits of information in the properties for each control:

• Report Manager URL: http://teamsystem/Reports
• Start Path (explorer): /teamproject
• Start Path (viewer): /teamproject/reportname

Remember, friends don't let friends use the generic Page Viewer web part to view Team System reports!

We have introduced a new blog site as part of our new website. Our blogs are now hosted in SharePoint 2007 and retrieved via web services for display.

So go check out our new blogs. Things look all shiny and new over there!

Customizing Work Item Types in Team System isn't quite as easy as it should be, but it's not difficult.

The Work Items are actually XML. To export them, you use the command line utilities witimport and witexport, which are located in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE path by default.

Here's how to export all 5 standard MSF Agile work item types (Bug, Task, Scenario, Quality of Service, and Risk):

witexport /f c:\task.xml /t %tfs% /p demo /n Task
witexport /f c:\bug.xml /t %tfs% /p demo /n Bug
witexport /f c:\scenario.xml /t %tfs% /p demo /n Scenario
witexport /f c:\risk.xml /t %tfs% /p demo /n Risk
witexport /f c:\qos.xml /t %tfs% /p demo /n "Quality of Service Requirement"

I created two little batch files which automate the process of exporting and importing all 5 standard Work Item Types from the MSF Agile template. You can download them here:

• export-all-work-item-types.bat
• validate-all-work-item-types.bat

Rename the files from .txt to .bat, and edit the path and TFS server name variables to match your environment.

Once you download the work item type XML files, you'll need to edit the resulting XML files to make whatever changes you need in the Work Items. There's some good guidance at MSDN on making common Work Item Type edits:

• Walkthrough: Make Basic Customizations to a Work Item Type
• Walkthrough: Make Advanced Customizations to a Work Item Type
• Walkthrough: Administer Fields in a Work Item Type

But editing raw XML still isn't my idea of a good time. You can make the experience slightly more pleasurable by adding IntelliSense to Visual Studio 2005 for Work Item Type XML. Rob Caron describes how. It's quite easy.

1. Download the process template schemas from the MSDN help topic Process Template Schemas Download.
2. extract the contents to: %ProgramFiles%\Microsoft Visual Studio 8\Xml\Schemas

After you copy the schemas to the right place, restart the IDE and you'll discover some shiny new IntelliSense when you begin editing the Work Item XML:

Once you're done making edits, validate your changes to make sure you didn't break anything.

witimport /f c:\task.xml /t %tfs% /p demo /v

Then, if you're happy with the validation results, remove the /v flag to import the work item.

witimport /f c:\task.xml /t %tfs% /p demo

And you're done! Wasn't that easy? OK, I wouldn't call it easy, but it's not too painful.

If you want something even easier, like a full-blown GUI tool to edit Work Item Types, you might want to check out the VSTS Customization Toolkit. It has some quirks, but it has worked fairly well the few times I've tried it. And it definitely beats editing raw XML.

I've always liked our business cards. They're one of the things that impressed me about Vertigo when I first interviewed here. Cool business cards are always a perk. Here's a quick scan of the current model:

There's a little hole in the middle and a cool spiral design on the back, so you can experience some "Vertigo" yourself by spinning it around.

We've had the same logo since 1997, when the company was founded, so we're probably overdue for a rebranding. And we're getting one February 1st-- we'll be inducing Vertigo a whole different way. I'll post side-by-side scans of the new business cards next to the old ones.

Team Projects are designed to be large-- they should host many solutions. Because Team Projects can be so large, that's why the Areas and Iterations dialog is so critical. Areas and Iterations allow you to logically slice up large Team Projects in space and time. Setting up a project structure via Areas and Iterations is one of the most important jobs a project manager has.

If you're wondering what this should look like, Eric Lee posted a great example of how Microsoft's internal VSTS development teams aggressively use Areas to logically divide a Team Project:

Areas and Iterations are important for another reason: they are one of the few places you can express hierarchy within work items. Outside of areas and iterations, work items are exclusively peer-to-peer. If you want to do any kind of reporting based on hierarchy, you'll need to set up an area or iteration to support it first.

One side-effect of slicing and dicing your large Team Projects is that project email alerts become problematic. The default UI for email alerts only allows you to subscribe to emails at the project level:

On a large Team Project, it's unlikely you would want an email alert when anyone checks anything in under the Team Project. You probably want email alerts for specific areas of the tree.

To do that, you'd normally use the bissubscribe.exe command-line tool, as described on Buck's blog. It seems straightforward enough:

bissubscribe /eventType CheckinEvent /address someone@domain.com 
/deliveryType EmailHtml /server http://teamsystem:8080 
/filter "'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject/A\")]' 
 null"


We'd just replace "$/TeamProject/A" with whatever path we're interested in. But there's one small problem: bissubscribe.exe is not installed on the client! It only exists on on the Team Foundation Server, at this path:

C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\bissubscribe.exe

That makes subscribing to events on a large Team Project somewhat.. problematic for the client, at least using the provided GUI. There's not even any way to browse your list of current subscriptions! There is Naren's GUI tool for creating work item subscriptions, but we were unable to quite get it to work.

The good news is that you can copy the bissubscribe.exe tool to the client and run it from there.

Microsoft recently released Visual Studio 2005 Service Pack 1. The update patches any version of Visual Studio, with the exception of the free Express Editions. It also patches any client edition of Team System:

• Visual Studio 2005 Team Edition for Software Testers
• Visual Studio 2005 Team Edition for Software Architects
• Visual Studio 2005 Team Edition for Database Professionals
• Visual Studio 2005 Team Edition for Software Developers

Service Pack 1 fixes tons of bugs in VS 2005, including many in Team Explorer, the essential client piece of Team System. I would install SP1 as soon as is practical for your team. Be warned, however: Visual Studio 2005 Service Pack 1 can be painful to install. It takes massive amounts of disk space and memory to install successfully, and can take longer to install than Visual Studio 2005 itself! As documented on Heath Stewart's blog, these two problems are common. We've experienced them at Vertigo, and I've heard from clients who have run into them as well.

1. You receive the error "File '...' was rejected by digital signature policy". Follow Heath's registry edit workaround.
2. During the SP1 install you run out of disk space. Disable the patch cache to remove redundant file backups during the patch and dramatically speed up the install process. Jon Galloway put together a little batch file which automatically disables the patch cache during the install, then reinstates it after the patch. I highly recommend using this batch file to install SP1.

   reg export HKLM\Software\Policies\Microsoft\Windows\Installer installer.reg
   reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f
   net stop msiserver
   start /wait VS80sp1-KB926601-X86-ENU.exe
   reg delete HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /f
   reg import installer.reg
   net stop msiserver
   del /q installer.reg 2>nul
   

In general, make sure you have tons of free disk space before installing SP1, and set aside a least an hour for the actual install. You do have to babysit it, because it'll prompt you for each update it installs.

There's also a companion Service Pack 1 update for Team Foundation Server as well. It is, thankfully, much easier to install than Visual Studio 2005 SP1. I've had no problems whatsoever installing the TFS SP1 patch, but I do have a few notes on the install.

1. You do not need to patch the server and client at the same time. It's perfectly fine to have SP1 clients talk to a non-SP1 server, or vice-versa. They can be installed completely independently.
2. You must always install KB919156 before SP1, so go ahead and download that first.
3. If you have seperate tiers for build, data, and web, you must install the patch on each tier. It doesn't appear to matter what order you patch them in.

The full list of fixes for TFS SP1 can be found in these two posts (one, two) by Brian Harry.

Good luck and happy patching!

The business development team at Vertigo recently standardized on the Samsung Blackjack phone.

It's fantastic hardware. The smartphone has finally shrunk to a pocketable form factor after all these years. Ironically, it's the software that needs to improve -- the Windows Mobile 5.0 OS on the phone leaves a lot to be desired. It's not exactly intuitive.

I dug through a massive tips and tricks thread trying to figure out ways to work efficiently in Windows Mobile on the Blackjack. Here's a summary of the best:

• Hard reset the phone by holding down UP and POWER to boot. It will ask to confirm.
• You can adjust the brightness of the screen in Settings under Power (scroll down)
• Pressing and holding the Home button brings up the task manager
• Pressing and holding the jog dial brings up a list of apps
• Pressing the power button brings up the quicklist
• Hold down message key to turn off backlight on screen.
• Fn + B = Toggle Bluetooth
• Press the V key for PAGE DOWN and the T key for PAGE UP.
• Hold down any key while typing to get its "alternate" character. i.e. Hold down the Q for a moment and you'll get the + symbol. This is nice if you don't like hitting Caps/Shift Q to get it.
• if you are reading an email, press the center d-pad "action" button... it will take you to the new contact entry with that persons email address already filled in.
• Apparently the phone doesn't support automatic keylock, you have to hold down the "end call" key for 3-4 seconds and it locks the phone.
• When you have a URL in the address bar hold down the BACK button above the red hang up button and it will delete the entire URL.
• In any of the edit fields (contacts, I.E., and others) if you hold down Undo (top right U-Turn with an arrow) it will delete the contents of the field you are in.
• There is no way to get periodic reminder tones for missed calls or messages. This little app addresses that deficiency.
• Holding down the back button on the right hand edge of the device launches the Camera app for taking pictures.

If you want to sync data between the phone and the computer, you can use ActiveSync on Windows XP, or Windows Mobile Device Center on Windows Vista. WMDC replaces ActiveSync, but is still in Beta 3 as of right now.

You'll probably want a few apps on your phone. Remember this is Windows Mobile 5.0, not PocketPC, so be sure to pick the right version of the app. I highly recommend starting with a freeware registry editor such as PHM Registry Editor. There are a lot of cool settings that are only exposed through the phone's registry*. I installed "regedit.Stngr_ARM.CAB" on the blackjack and it worked fine for basic registry editing. Once of the first things you'll want to do is turn off the "application lock", either via editing the registry or by downloading and running a small registry edit file named "appunlock.cab" on your phone.

Battery life is OK, but not great. That's probably why it comes with an extra battery and a standalone battery charger out of the box. The phone does trickle charge over USB when it's connected, however, I couldn't get it to charge at all via USB when the battery was very low and the phone wouldn't turn on. There are pictures of the extended battery in action here. This might be a good upgrade if you're running into battery issues.

The phone has a lot in common with the Motorola Q, so often tweaks and files for the Q will work on the Blackjack. You can download new start page designs that work fine from koodezine and qusers. Here's the one I'm using:

And remember, the phone accepts MicroSD cards for additional storage-- they're tiny compared to their SD and MiniSD brethren.

* that's right, there's a Windows Registry on a phone. Depressing but true.

My coworker and erstwhile twin, Matt Hempey, turned me on to the superthin All-Ett wallet. I was in the market for a new wallet, as my current Tumi wallet was almost 10 years old and starting to show its age.

After seeing Matt's All-ett, I was sold. I ordered my own All-ett. As promised, the fully populated All-ett is thinner (much thinner!) than my old wallet is empty. Amazing! It's so much more comfortable to sit down with this in my back pocket. I no longer feel motivated to remove my wallet from my back pocket when I sit down. That's important, because I tend to forget where my wallet is when I remove it and leave it lying around.

I only have three minor criticisms:

• The ultra-thin spinnaker sailcloth they use is a tiny bit "crackly" in use. It's not a problem in practical use, you can't hear yourself sit down, but it is a little disconcerting at first.
• The orientation of the pockets means the contents tend to fall towards the middle when you open it. It's a little more fiddly than a "typical" wallet when opening it and fishing items out of it. But given that I tend to open my wallet maybe 3-4 times per day, at most, that's a tradeoff I'm perfectly willing to make.
• The color selection is absolutely hideous. Black works fine, of course, but you can tell this is sailcloth when you look at the color selection. Would you like your wallet in teal green, seafoam green, or kelly green? That's what I thought.

Minus those very, very minor criticisms, highly recommended.

I've always wished I could carry a pen on my keychain, but I've never found one small and convenient enough to add to my existing keychain. I already carry quite a bit of stuff on my keychain: a LED flashlight, a Leatherman Squirt, and of course my keys. I'm not sure if I want to add a pen to that list. But there's a better way: I can carry a pen in my wallet!

I found two wallet pens that worked:

The Derringer Wallet Pen is only $8. Unfortunately, it was slightly too large for my old wallet at 4" long. So I had to give it away.

The wallet pen is quite a bit more expensive at $40. But it's made of sterling silver, and most importantly, it's only 3" and even thinner. So it's even more portable.

The wallet pen, as small as it is, fits perfectly in the "crease" of a typical wallet. It does bulge up a tiny bit in the super thin All-ett, but it still works.

I'm very happy with my new wallet arrangement. It's more comfortable, it's way thinner, and now I always have something to write with, too!