Thoughts on Microsoft's purchase of Teamprise

Since I was the first to bring TFS/Teamprise into my company, I've been asked to comment on the Microsoft/Teamprise deal. Though Teamprise and Microsoft have seemed to have a tight relationship all along (and users have benefited from this), I believe combining them makes good business sense. Why? Let me explain.

Large companies, like the one I work for and partially own (tongue and cheek here as I own a small portion of stock), want vendors who have consolidated tool sets that fit their development ecosystems. I've only worked for one company, but I'm guessing that most organizations have two large pillars: Java and .NET. What we don't want to do is buy one tool for our .NET folks and another for our Java folks. Often, a single person works in both technologies so buying two licenses doesn't make economic sense.

TFS along with Teamprise has allowed us to satisfy the needs of developers working in .NET and those working in Java on Linux desktops. One sticking point however has been that we have two vendor relationships to manage. While this has never bothered me much, our procurement department has mentioned that they like to limit the touch points. And since they deal with the myriad of legal contracts and license management (a significant pain point for large organizations), I can understand their concerns.

Buying Teamprise makes TFS a more attractive solution for companies with multiple development ecosystems. Three years ago when I approached our vice president with the TFS proposal, he questioned why Rational could give us everything we needed while TFS required us to buy an additional product. This concern was allayed by other factors (ease of use, migration path, price, etc.,) but it would have been an easier sell if Microsoft had a cross-platform solution back then. I can only imagine this purchase makes TFS more attractive to those on the fence about what product to go with.

Lastly, a note to Microsoft's leadership: In my 12 year career, Teamprise from top to bottom has been the easiest company to work with. Everything from support (Tonya Nunn is great) to development leadership (Martin and Edward Thomson of course), we've had nothing but positive experiences with them. I hope you leverage their close, personal approach to working with customers. They are every bit as important (if not more) to Teamprise's success as the software itself.

"You are not logged into Windows Live Messenger"

After a user (a business representative user) installed the October Power Tools, they started getting a message saying "Team Foundation Error: You are not logged into Windows Live Messenger" when opening VS.NET 2008 Team Explorer.

I didn't look into it much (too many other things going on), but I guess these steps fixed it (or disabled whatever was causing the issue).

1. Open VS 2008 and wait until Team Members is not "working..."
2. Right-click on it and select Personal Settings
3. Under Collaboration, click Change
4. On the opened dialog select None and click OK
5. Click OK once again

I got them from this forum page.

"TF84037: There was a problem initializing the Microsoft Excel Team Foundation AddIn"

We seem to have a number of people who get the error "TF84037: There was a problem initializing the Microsoft Excel Team Foundation AddIn. Re-installing the Team Foundation Client may be required." Which usually boils down to the user not having .NET Programmability Support enabled on their Office installation. Here are some plagiarized instructions I stole from someone else who I can't remember who. Thanks to whoever I took these from.

It looks like Office 2007 .Net programmability support is not installed. You need to modify your installed version of Office and install this option. I thought we had a better error message for this...
1. In Add/Remove programs, locate your Office application and select it.
2. Click on the 'Change' button
3. Select 'Add or Remove features' and click 'next'
4. Select 'Choose advanced customization of applications' and click 'next' OR select something like 'Add .Net programmability support'.
5. In the tree view, expand 'Microsoft Office Excel' and make sure the .NET Programmability Support option is set to 'run from my computer'.
6. Click 'update'.

Slow "Get" issue resolved

Three or four months back we decided to move our build systems from a dedicated virtual machine (VM) farm to the company supported VM farm in the data center. The data center infrastructure had all the bells and whistles (support, backups, redundancy, etc.,).

Everything worked well with the exception of the Gets. Our Gets were taking between 5-10 times longer than in our dedicated farm. We thought it might be a hardware issue, but the new VMs had more memory, more processors, sat physically closer to our TFS server, etc. What the heck?

I spent a good 2-3 days running tests and engaging experts including Teamprise and Microsoft. (I also gained some gray hair.) No such luck getting it figured out.

Turns out my colleague ran into a guy who was having similar issues after migrating to the data center VM farm. Turns out, the data center VM farm was running a new version of our virus scanning software. The real-time scanning must have been checking every file. Once we turned that off, our Gets were significantly faster in the data center VM farm.

What I still don't understand is that the Gets were taking abnormally longer on JAR files (e.g. mac.jar) compared to other binary files (e.g. mac.msi). I'm thinking that since a Jar file could be setup as an executable (I think that is possible in Windows), the virus scanner was spending extra time on those. This is just a hunch.

So if you're running into performance issues with your TFS Gets, try disabling your virus scanner (just for testing of course) and see if that is the cause.

"Updating Work Item Data has encountered a problem"

If you get an error in Teamprise like "Updating Work Item Data has encountered a problem. Java.sql.SQLException: File input/output error: Unexpected Token:", just clean your local cache. It's probably some kind of synchronization issue with the local cache and TFS server.

On XP the Teamprise local cache data are stored under C:\Documents and Settings\%USERNAME%\Local Settings\Application Data\Teamprise\2.0. For this error you just need to delete the ./db directory. You will have to close Eclipse or Teamprise before doing so.

Finding the process locking files or folders on Windows 2008 Server.

If you ever need to find what process has a file/folder locked in a 64-bit Windows 2008 Server machine, check out Handle. I usually use WhoLockMe, but it didn't work on my 64-bit machine running Windows 2008 Server.

Unzip handle.exe on your machine and issue "handle c:\myFolderName". It will list out the process ids that have the file or folder locked.

Sysinternals has a ton of other tools that I've found very helpful in administering servers.

Disabling an ASP.NET Web Project from building in a Solution

We ran into a problem recently where we wanted to add an ASP.NET Web Project to our Solution but to not be built during the Team Build. Why? It's a long-story, but it seems to be working well for the group. We had this setup before and working fine, but then someone broke it and we just got around to fixing it again.

Unfortunately when adding the ASP.NET Web Project this time, we were getting errors in Team Build because Team Build couldn't find the project to build Hum? In the Solution's Configuration Manger we had unselected the "Build" check mark for the ASP.NET Web Project. Yet the build continued to run.

After scratching our heads, my colleague (my much smarter colleague) noticed that the Solution File had this in it.

{95153BD9-7C07-4754-8DB2-37512B95B43C}.Release|Any CPU.Build.0 = Debug|Any CPU

My understanding of this is that when we run the build via Team Build, we say "Release|Any CPU" in the TFSBuild.proj file. It's the default. When Team Build (actually MSBuild) sees this line, it assumes that we intend to build the ASP.NET Web Project. However, we don't and what I'm still missing is why unselecting the "Build" check mark didn't remove this line.

To remove the solution setting, my colleague Right Clicked on the ASP.NET Web Project, Selected Property Pages, Selected Build and under "Before running startup page," she changed it from Build Website to No Build. The check box Build Web Site as part of Solution was already unchecked though if it was checked, we would have unchecked it as well. Now the Solution build works fine as it does not build the ASP.NET Web Project (which we intentionally don't want to build).

In summary, do get the ASP.NET Web Project to not build, we 1) unchecked the "Build" check box in the Solution's Configuration Manager, 2) Changed the ASP.NET Web Project's "Before running startup page" to No Build and 3) made sure check box Build Web Site as part of Solution was unchecked.

Some combination of these removed the line {95153BD9-7C07-4754-8DB2-37512B95B43C}.Release|Any CPU.Build.0 = Debug|Any CPU from our solution file.

TFS 2008 SP1 upgrade nightmare

I'm typically very pro-TFS on this blog, but I have to share some negative news. Mainly because it cost me, and my colleagues, an entire evening away from our families while we upgraded. Here are the issues and resolutions from our nightmare. It took us six hours in total. We're done now and I'm off to my home where I can lie awake all night and stew.

Issue #1:
Issue: .NET Framework 3.5 SP1 install failed when installing Visual Studio 2008 SP1

Resolution: Installed framework separately.


Issue #2:
Connecting to SQL Server Reporting Services. Please wait...
Invalid namespace
Value cannot be null.
Parameter name: uriString
Configuring SQL Server Reporting Services failed.

Resolution: Removed the Standby Key from the database.
C:\Program Files\Microsoft SQL Server\90\Tools\binn\rskeymgmt -l
C:\Program Files\Microsoft SQL Server\90\Tools\binn\rskeymgmt -r asdfasfasdf-8968686-asfa-asdfdsf-9as7dfasfasd



Issue #3:
Issue: Restart attempt failed.

IIS Admin Service or a service dependent on IIS Admin is not active. It most likely failed to start, which may mean that it's disabled.

03/26/09 19:55:52 DDSet_Status: Process returned 1062
03/26/09 19:55:52 DDSet_Error: The Commandline '"C:\WINDOWS\system32\iisreset.exe" /Restart' returned non-zero value: 1062.
MSI (s) (AC!14) [19:55:52:046]: Product: Microsoft Visual Studio 2008 Team Foundation Server - ENU -- Error 32000.The Commandline '"C:\WINDOWS\system32\iisreset.exe" /Restart' returned non-zero value: 1062.

Error 32000.The Commandline '"C:\WINDOWS\system32\iisreset.exe" /Restart' returned non-zero value: 1062.
03/26/09 19:55:52 DDSet_CARetVal: 32000

Resolution: The install person watched the IIS Admin service and 'W3SVC' service. When they went down, he manually brought them back up. We tried this five times manually and never got it right. We finally reverted to issuing the command "iisreset & issreset & issrest …" continually. Eventually we got the timing right and it went through. This is the one that really gets me upset. I've never seen such a thing.

Issue #4:
Issue: Team System Web Access 2008 uninstalls, but you have to delete the IIS Website and App Pool manually through the IIS Manager. You also have to purge d:\Program Files\Team System Web Access 2008 as the uninstall does not delete that either.

Resolution: Delete the IIS data and installed files manually.


Issue #5:
Issue: We ran into the issue with .NET 3.5 SP1 and Fully Qualified Domain Names. Here are some of the error messages we found in the Event Viewer.

Exception Message: TF30063: You are not authorized to access tfs.mycompany.com

TF53002: Unable to obtain registration data for application Build.

Detailed Message: TF53005: Unable to retrieve the Team Foundation Server installed UI culture.

Detailed Message: TF53002: Unable to obtain registration data for application VersionControl.

Detailed Message: TF30040: The database is not correctly configured. Contact your Team Foundation Server administrator.


Resolution: See here for resolution steps. The first one (i.e. recommended) didn't work for us. We had to do the second one, which worked. http://support.microsoft.com/kb/926642. A special thanks to Brian and Buck for posting this on their blogs.

Honestly, if it wasn't for what people post on blogs, we would have had to rolled back. A special thanks to everyone in the community who shares their experiences. Hopefully some of the issues and solutions I've given here help others.

UPDATE (3/37/09): One thing to remember is if you use a FQDN (e.g. tfs.mycompany.com) is you have to run ActivateAT [MachineName] (e.g. activateat MyTFSAppTier) on the primary app tier before running the install. We knew about this as someone else at the company told us so it wasn't an issue that we ran into, but could be one that you do if you fail to do this.

Cross Platform Builds with Team Build

For some reason I seem to constantly find myself working with cross platform solutions (e.g. .NET, J2EE, C). Recently I've been assigned to figure out how we can compile custom Apache HTTPd modules without re-inventing our current build solution (which uses Team Build). I've created a diagram that describes the proposed solution.

The basic idea is we use Team Build for all the peripheral build tasks, outside of compile. Compile has to be done on platform specific machines (e.g. Linux 64). So to compile, we simply use Ant's SSH tasks to 1) transfer code to the platform machines, 2) compile via make and then 3) transfer binaries back to the Team Build server from the platform machines so the build can continue. We use Teamprise's Build Extensions to call Ant. In addition, in previous lives, we've used Teamprise for #1 and we'll probably look at doing the same in the near future. Here is the diagram.

Teamprise’s “Show the New Project ….” Feature

If a user Imports a folder from Source Control via Teamprise’s Eclipse plug-in, the plug-in will look for a server copy or local copy of the .project file. If that file is found, it’s used for the project creation EVEN if you select the “Show the New Project ….” select button. This becomes troublesome when a user walks through the import wizard, completes the import, then realizes they wanted to use the “Show New Project ….” feature in Teamprise. If they delete the Project from Eclipse, but don’t delete the local .project file (created during the first import), subsequent imports will always default to the local .project file, EVEN if the user selects the “Show the New Project ….”.

I can see both sides of almost everything, however, I think the “Show the New Project ….” select option should override the fact that a local or server .project file is found. Or at a minimum, a warning should be tossed to the user. I think this would have saved my good friends downstairs a headache or two!