Somebody asked me a simple question the other day: “how do I export all of my work items at once”. I suspected they were looking to perform a backup, but it sounded like they might want to import into another system or just archive them in some readable way. I suggested Microsoft Excel, but it can only fetch work items from one team project at a time. So repetition, using a Macro or a human, would be required.

Here’s an alternative we came up with …

1. Downloaded and installed Team Foundation Power Tools.

2. Picked one of the Team Projects, added a query, and removed the Team Project = @Project clause, so that it was completely empty:

3. Changed the Column Options, added the columns we wanted to export. For testing, we selected ID, Team Project, Work Item Type, and Title.

4. Ran the query and verified that it pulled the right work items and fields we wanted.

5. Saved the query (My query) and named it AllProjectWorkItems.

6. Dropped to the command prompt and executed the following commands:

    cd c:\Program Files\Microsoft Team Foundation Server 2008 Power Tools

    tfpt query "Calculator\My Queries\AllProjectWorkItems" /Server:vsts /format:xml > c:\AllWorkItems.xml

7. This command generated an XML file containing all of the fields from all work items from all projects. This satisfied their requirement.

At this point you can update the query adding more columns, until you have the superset of what you need for the export of all types from all projects. With a little finesse, the XML document could be migrated into Excel or another software application.

Out of the box, Microsoft has a Work Items check-in policy which requires you to select at least one work item when checking in your code in TFS 2008. If you install the Team Foundation Server Power Tools, you’ll get the Work Item Query check-in policy. This is nice because it allows you to specify a team query to which the work item associated with a check-in must belong. The example I give is that the team may want to spend the next couple of days on a “bug bash”, so you could use this policy to point to the “Active Bugs” query, etc.

What’s missing is a policy that enforces you selecting exactly one work item during check-in. I believe this is crucial for maximum traceability: one changeset to one work item. This is a good habit to adopt as it increases the maintainability of the code, offering better get, branch, build, and merge options. Another way to put it: chatty check-ins (many, throughout the day) are preferred to chunky check-ins (one big one at 5pm).

If only Microsoft had added a configuration page to either of the above policies, I wouldn’t have had to build this policy.

Follow the P&P How-To guidance using the attached project to implement this policy.

Attachments: SingleWorkItemPolicy.zip (19kb)

If you’re like me, then you don’t pay attention when you install a lot of software. Often times I just click Next > Next > Finish without reading the screens.

For example, I guess I wasn’t paying attention to who the registered user was when I installed Visual Studio 2008 or Windows for that matter, because the splash screen shows this:

Yes, it’s a registry setting and you can find/set it here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner

Unfortunately, changing it didn’t do anything, until I learned the trick from John Robbins (Wintellect):

After you change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner, restart Windows and then run “DEVENV /setup” from an elevated PowerShell window. That will update the splash screen registry key.

Don’t trust the install guide that you find inside your Beta 2 download media. It’s an older version that was from last month.

Instead, download the latest, beta 2 guide (TFSInstall-beta2-9192009.chm) here.

I’ve been doing a lot of work with the Database, er Development edition of VSTS 2008. Of course I’m running the GDR-R2 version which really changed the architecture of the database projects, as well as the process of building and deploying.

Prior to the GDR, if you deployed a database project it would automatically create a Data Connection in the Server Explorer window. I liked this, because I would almost always follow-up a first time deployment with some data generation or unit testing, and it just made it easier to select the pre-defined connection from the dropdowns. It seems that the GDR erased this timesaver.

For example, I just deployed a GDR-R2 database project according to these settings:

And when I go to the Server Explorer window, I don’t see my VSTS\dev.AdventureWorks2009.dbo connection like I would have expected:

Well it seems that this change was by design and it is configurable! According to Duke Kamstra, there’s a property in the database project (.dbproj) file that lets you control this behavior:

<DeployToDatabaseAddToServerExplorer>False</DeployToDatabaseAddToServerExplorer>

If you set the property to True, the connection will get added to the list which Server Explorer displays, and the behavior I enjoyed prior to GDR will return. For added coolness, if you always want this behavior you could modify the template(s) that are instantiate dbproj file(s) from: C:\Program Files\Microsoft Visual Studio [9.0 | 10.0]\VSTSDB\Extensions\SqlServer\ProjectItems\*\*.dbproj

Duke also tells me that the same property exists in Visual Studio 2010.

I was at a client site last month where they have TFS2008SP1 installed and running on Windows Server 2008 SP1. Everything was working fine. We created several team projects. No problems.

I come back three weeks later and it wouldn’t create a team project. I kept getting the “Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server” error. According to the client, they hadn’t touched anything. So, I started with Ben Day’s blog post on the subject, but his fix didn’t work for me. I then checked all the service accounts, permissions, farm administrator group, database status, etc. – all the standard things, but no help.

Come to find out none of the SharePoint collection/sites would come up, let alone allow me to create new ones. The Admin site worked, but every other site gave the “Cannot complete this action. Please try again” wonderfully helpful error message.

Windows event logs and SharePoint event logs were useless, but I did find a KB article talking about setting impersonation explicitly from code, so I decided to check the Authentication settings on the Default Web Site and sure enough it was Disabled. I changed it to Enabled, ran IISRESET for good measure, and voila!

I watch House enough to know that “everybody lies”. It’s a basic Houseism. That was the case here. The “we didn’t touch anything” statement turned out to be false.

I’ve been hearing about these type of government contracts more and more lately. I guess they’ve been around for years, but just maybe getting more popular in the circles I travel. IDIQ contracts provide for an indefinite quantity of supplies or services during a fixed period of time. They are frequently awarded by US Government agencies, including the GSA and the DOD. They are most often used for architect-engineering services, such as IT projects.

As I work with government agencies, I find their waterfall approaches to project management and estimation to be frustrating. I hear a lot of “we do it because we’ve always done it that way” or “that’s just the way it is in government”. I continue to question this, especially when I see there are government agencies, especially federal, failure-prone ones who are learning to trust their (agile) vendors and IT service providers more and more. The IDIQ contract type is just such proof. It rocks.

I did some searching and found that I wasn’t alone in this thinking. I found some articles on Alistair Cockburn’s site that mention IDIQ as part of a larger list of Agile contract approaches.

I spent this morning working with a client who will be using Eclipse and Teamprise client to support their ongoing Java break/fix work while they migrate their application to .NET. Both teams want to use (the same) Team Foundation Server so that work items, version control, and automated builds are shared between all.

These are some questions that came up during a simulation that we ran through this morning, as well as some answers back from Martin Woodward of Teamprise. I wanted to share with anyone else who might have similar questions.

Q. Is the Annotate command available from within Eclipse?
Not yet. We have this in Teamprise 4.0 which we will be releasing to sym-ship with TFS 2010 RTM. We’ll be having previews available of Teamprise 4.0 during the 2010 Beta 2 period as well as having a Teamprise 3.3 version which will work against TFS 2010 but not have the TFS 2010 features (follow history on merge, branches as first class citizens, hierarchical WIT etc).

Q. Get Latest on Check-out, if configured at TFS does Eclipse play nice with that option or does it ignore it?
The Teamprise clients have a preference for this feature. Currently we do not look for the server side setting in TFS 2008 as our support of Get Latest on Check-out predated when Microsoft added it to TFS.

Q. Are the Eclipse check-in policies completely different than Visual Studios? In other words when I enable the Work Items policy in Eclipse do I have to also enable it in Visual Studios?
Yes. Java and .NET check-in policies are completely independent. This is because of the programming model behind them (i.e. .NET ones implemented in .NET, Java ones implemented in Java).  For more information on implementing custom Java check-in policies if you need to see the Teamprise Check-in Policy SDK. However we ship with additional policies to the Visual Studio client so hopefully you won’t have to.

Q. Do you have any guidance (such as "don't do it") for having both Eclipse and VS use the same workspace and possibly edit some Java project files in Eclipse and others in VS?
You can do it – and it will work fine. The only problem is that the pending changes manage in each would need a refresh (press the refresh button) if you are editing in one application then switch to the other so that it knows about pending changes created in the other application. That said, we’ve found people find it easier to understand if they keep to the rule of 1 Eclipse workspace == 1 TFS workspace, therefore creating a new workspace to work in for the Eclipse development is probably easiest but not necessary.

Q. Does your Remote Accelerator product work fine for both Eclipse and VS on the same desktop?
Yes, works for any TFS client on the same machine that talk the correct TFS protocol. The only restriction is that it is single user – i.e. the person running the accelerator process must be using the same credentials to talk to TFS as the client application is using to talk to TFS. This is enforced by the Accelerator.

Q. If you want to call a specific target within the Ant build.xml file, can you specify this in the MSBuild command-line arguments textbox when queuing a build, will it'll trickle down to Ant?
If you want to call the same target every time, then you can edit the <targets></targets> attribute in the AntBuildFile itemgroup as defined in the TFSBuild.proj file. If you want to be able to optionally pass one through as MSBuild arguments in the Queue Build dialog then you would but the variable that you wanted to use in the targets attribute (i.e. <targets>$(AntTarget)</targets>) and then optionally specify the property in the dialog ( -P:AntTarget=myTarget)

Q. The .trx file generated by JUnit – is that Teamprise that generated it and I'm guessing it's pushed to the data warehouse automatically?
Yes. JUnit targets need to output results using the xmlformatter (as standard). The Teamprise Build Extensions then look for the JUnit result files and transform them into the trx file format. They then call MSTest.exe with the /publish parameter to publish the JUnit results to TFS which in turns gets automatically pushed to the warehouse. Note that as we are using MSTest the build server needs a “team” version of visual studio installed on it (Team Dev, Team Test or Team Suite) for the publish functionality to be enabled. You can get the Teamprise Build Extensions and look at the source code (under the MS-PL) if you want to understand better how it works.

Q. Is there any support for JUnit code coverage?
For code coverage you can still produce the usual Java reports and have them included in the build drop location, however there is currently no way to publish code coverage data to TFS for Java applications. This is due to the way that the code coverage results format is tightly bound to the PE (windows portable executable) file format. We’ve been working closely with the team on this one and currently hope to have a solution in place after TFS 2010 RTM.

Note: These questions were based on Eclipse version 3.4.1 and Teamprise version 3.2.1.

Thank you for attending this week’s webcast on the new capabilities of Visual Studio Team System 2010 Test Edition. Specifically, we covered these topics: