"Does TFS support Java code?"

One of the most common questions I get from managers of J2EE development groups is, "Does TFS support Java code?" To the untrained eye, this is a valid question as most managers are a bit removed from their coding days.

Those of us in the know though, we understand that most development languages are written in ASCII based files. In Java, for example, we write our code in .java files which are ASCII based. TFS versions them just fine. Just like it would Perl, Python, C++/C, etc. And even if you write in some format that spits out a binary file, TFS would version them just fine as well. Though, like all Source Control tools, not quite as efficient.

To TFS, a ASCII file is an ASCII file. TFS knows nothing of J2EE and to be honest, does not care. I know most of you all understand this, but I wanted to drop a note as it's a common question we get from non-technical folks.

Update 2 on the horrid "There may be problems with the work item type definition" error

Well I'm back from an extended vacation / company holiday. Before I left a week or so ago, I was working with a member of the TFS development team on what I have been referring to as the horrid "There may be problems with the work item type definition" error. Search this blog for "horrid" and you'll find a number of posts.

First of all, I'd like to thank the TFS development team for reaching out to us on this error. It's very random and I can't reproduce the error on demand, so I was ambivalent about submitting it through connect. The TFS development team however, reached out and asked if they could help. As it turns out, they could.

What we're finding is the error seems to be related to a user's SQL View being out of sync with the tables, after a work item template change. Example changes we're making are adding/removing states and then adding/removing rules (e.g. REQUIRED) around those states. We've come to this conclusion, as first it only happens to certain users (on a variety of different machines). And second, the most common fix is to remove/add the user. From what development tells me, this act will force a refresh of the user's View.

Anyway, we're not out of the woods yet on this. But I'm really happy with the support MS has been offering us with TFS. Compared with my frustrating customer support experiences with ClearCase, TFS (and Teamprise) support is swimmingly.

Migrating Legacy Defect Data to TFS

Not too much new here. We just passed the halfway mark in our TFS migration and so far everything is pretty good. A few minor issues like the AD displayName not syncing with TFS, but nothing too major. Knock on wood.

There are a number of posts on this, but I thought I'd add my experiences with migrating legacy defect data to TFS. Like most everyone else, we simply used Excel with the TFS plug-in. Here is our process.

- Lock down the legacy defect management tool so it's read only.
- Export the data to Excel. We just migrated the open defects.
- Map the fields. For example, Owner in old tool with the format "FirstName LastName" mapped to Assigned To in TFS with the format of "LastName, FirstName (Company)". This is actually the hardest part.
- Run the Publish.
- Verify results.

The one thing we did that really helped was to migrate the legacy ID number to a simple text field in TFS. This allowed the user a reference to go back and look at data we were unable to migrate like state history.

Good luck with your migrations!

TFS 1.5, TFS Orcas, VSTS 2008 Team Foundation Server?

I've been refereeing to the next release of TFS as "TFS 1.5."

"Hey Mac, what's the next release for TFS?"
"That would be TFS 1.5 my good man. Can't wait to get our hands on it as it has some nice Team Build features like continues integration we want to try out."

And like a lot of things, I've been misinforming people in the office. While I've heard people refer to the next release as TFS 1.5, Brian Harry has confirmed for me that there is no official "1.5" release number in the next TFS release. He did admit though that some people have called it 1.5, informally that is.

I've also heard of it called "Orcas" which as it turns out, is somewhat correct. The official name from MS marketing (or whoever makes up these names) is "Visual Studio Team System 2008 Team Foundation Server."

Semantics aside, this release is a minor release that does not have a lot of the bells and whistles that, what I've heard people call Rosario, will have. If I remember right, Rosario will have the really cool things like work item hierarchy.

Not to cut TFS 2008 (yet another term I just made up for it) short though. Among other things, it will provide SharePoint 2007, Continuous Build, server side tools for deleting work item types (we're going to love this), and the obligatory list of bug fixes. Brian has a nice list of things here that you can check out.

One way to rollback changes using Teamprise

I don't purport to say this is the best, or only way to rollback changes using Teamprise Explorer. It's just one way we came up with.

Before you do this, make sure you DON'T have "Automatically get the latest version before check out" selected under Tools > Preferences > Source Control. From my findings, this setting can cause some issues with the solution below. I'm working with Teamprise to see if there is a bug, or if I'm solving a problem with the wrong solution.

To rollback changes, or in other words, revert the latest version to a previous version:

• Right Click on the file you need to rollback and select View History. Right Click on the appropriate changeset and select Get this version.
  
  
• Right Click on the file in the Source Control window and say Check out for Edit. You should now have the old version of the file checked out.
  
  
• Right Click on the file and select Check In Pending Changes...
  
  
• The Resolve Conflict window will pop up. Select the file and click Resolve... Select Undo Server changes. This will tell the server that you mean to change the most current version of the file on the server.
  
  
• Lastly, Right Click on the file and select Check In Pending Changes... This will commit the changes to the database.

Disabling Visual Studio 2005 Just-In-Time Debugger

Being a TFS administrator, I run into some of the oddest situations. Here's today's.

A user of mine works with files located on a Unix machine, but accessible via Samba. She basically just looks at logs. Because Notepad does not handle the "end of line" character well (it will not automatically stick in a carriage return when viewing the file) she uses WordPad. Yes, you're probably just as surprised as me. Some people still use WordPad!

I had a good laugh asking her why she used such an antiquated tool. It's because WordPad will insert a carriage return when viewing so the log file looks nice. I directed her to more advanced tools (Textpad is my favorite), and she said she'd look into getting something better in the future.

Anyway, the real problem was that WordPad was throwing random exceptions for her. In the past she got the "WordPad MFC Application has encountered a problem and needs to close. We're sorry for the inconvenience." Thanks Microsoft. I appreciate your apology.

After installing Visual Studio Team Explorer, it was tossing up the Just-In-Time debugger and asking her if she wanted to debug the error in WordPad. This confused the user and prompted an email to the TFS administrator who made her install the offending software.

My goal was to turn off the debugger and return to Microsoft's apology note. I first started by going to Visual Studio's Tools > Options > Debugging > Just-In-Time and unchecking all the boxes. The standard Just-In-Time debug message went away, but it was replaced with an ugly "you don't have a default debugger configured dummy!" message. Or something along that line.

A quick Google search led me to this article. They show you the two reg hacks to fully disable debugging on your machine. Remember, standard registry backups should be applied before doing these steps.

I'm glad to note the user is now back to normal and continues to use WordPad and still gets random exceptions.

SQL Reporting Services Training

Three of us are in "SQL Reporting Services" training this week. Class "2793A: Implementing and Maintaining Microsoft SQL Server 2005 Reporting Services" to be exact. My suggestion is, if your first introduction to Reporting Services is with TFS (like ours was), spend the time and money to take a class. Reporting Services is not easy.

This class is pretty basic, but it does help you get the fundamentals down. After you take the class, I'd suggest you take something that works with Analysis Services. The material in 2793A is centered around pulling data from a relational model. TFS, on the other hand, has the cube which we'd like to use. Thus the instructor suggested our next stop be in an advanced course in Analysis Services.

Update on the horrid "There may be problems with the work item type definition" error

The issue TFS has with the AD displayName changing is bad. But now that we know what it is, it's not so bad. On the other hand, the horrid "There may be problems with your work item type definition.." error continues to give us fits.

The first time we got it, the error was legitimate, though not descriptive. We had a state named the same as a group. Microsoft is fixing this. Fair enough once we got it figured out. Now we seem to get it when ever we're making a lot of state and transition changes. Throw a few rules (e.g. REQUIRED) and we have real problems.

We got it again on Monday. This time I tabled everything I was working on and dedicated myself to figuring it out. I turned logging on by adjusting the web.config's traceLevel to 4 and traceWriter to true. Be careful with this if you don't have a lot of disk space. It will throw you a lot of information. Even with all that information, nothing good came from the logs except the standard "Microsoft.TeamFoundation.WorkItemTracking.Server.ValidationException: Forcing rollback ---> System.Data.SqlClient.SqlException: Forcing rollback" stack trace. Then I deleted all my local cache (typically your first step), but continued to get the error.

Next, out of curiosity, I tried logging into a new machine with my account. Same issue. I then tried Teamprise and TSWA. Same issue in both. Finally, before quitting my job and moving to Mexico, I tried logging into Teamprise using a different account. Something you can do with Teamprise which is a nice feature. This time it worked!

So why? My local cache was all removed. I tired the same account on multiple machines and still got the error. The permissions between my account and the account that works are the same. As a last resort, I restarted IIS thinking maybe something was cached on the server side. Just to be extra safe, I also removed all my local cache again. Sure enough, that did it. I could once again create work items.

So my hypothesis is, TFS must be doing some server side caching for work items. Or maybe there was something in memory that was not being cleaned up correctly? I'll continue to see if this solution works and post my results.