Wednesday, July 15, 2009

"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'.

Tuesday, July 07, 2009

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.