Team Foundation Error: Type ‘Microsoft.TeamFoundation.ClientBasicAuthCredential’ is not marked as serializable

If you are getting this when trying to run a build in TFS or when trying to edit a build definition, you only need to reset your credentials. Go to Control Panel > User Accounts > Manage Windows Credentials > In tab Generic Credentials, find the one for your TFS server and edit the credentials. If that doesn’t work, try removing the credential.

SSDT Power Tools November 2012 for Visual Studio 2012 – Installation Steps

When VS 2012 informed me there was an update for the SSDT Power tools, I was expecting to click the update button and that would be it. Instead, a message popped up informing that the SQL Server Data Tools reference was missing. Knowing that I already had SQL Server Data Tools installed, I decided to go straight to the SSDT Power Tools site and install it from there. It did install, but when I opened VS 2012 and went to the SQL Server Object Explorer, VS crashed… every time. Certainly not the desired effect, so I immediately uninstalled the vsix by going to Tools > Extensions and Updates > Installed > Tools. Now that VS 2012 was not crashing, it was now time to figure out why it would not work. Here are the steps for installing it correctly.

  1. The first step is to update the version of the SQL Server Data Tools at
    1. Download the update in step 2 from the page above, but do not install yet
    2. Install the Microsoft® SQL Server 2012 Data-Tier Application Framework (November 2012) at
      1. Everything on this page needs to be installed. If you are on an x64 machine, the x86 versions also need to be installed.  This is the order I took.
        1. ENU\x64\SqlDom.msi and ENU\x86\SqlDom.msi
        2. ENU\x64\SQLSysClrTypes.msi and ENU\x86\SQLSysClrTypes.msi
        3. ENU\x64\DACFramework.msiand ENU\x86\DACFramework.msi
    3. Now install the SQL Server Data Tools downloaded in bullet 1 above
  2. Finally, install the SSDT Power Tools found at

SSDT and the power tools should now work as expected.  Even though this is for the November 2012 release, these steps may be needed for future updates.

TFS 2012 – Add Users to a Team Project Group

Working in Team Explorer 2012, one noticeable change is the administration for a team project or collection.  It has been moved to the Web Access application.  When trying to add a user to a group in a team project, it may seem confusing due to the user not showing in the drop-down and not being able to browse to the user unless the person has already been added to a group somewhere in TFS.  It turns out this is because this feature has been moved to a Web application and out of the desktop application.  Here is what you need to do to add a new user to a team project that has not been added anywhere in TFS 2012.

In Team Explorer, go to the settings screen and click on Group Membership as seen below.


This will take you to the security screen in the Control Panel.  To add a user to a team project, select the group on the left side of the screen, (e.g. selecting the “<team project name> Team” link on the left will add the users to the Contributors group).  Then click on Add > Add windows user or group seen below.


This will open the dialog to select the user as seen below.



There is a message on the dialog explaining what needs to be done, but it is easy to miss.  The problem is if the user has not been added to TFS anywhere, they will not show up in the drop-down and you will not be able to browse to find the person.  The only way to add the person is to manually type in the person’s username with domain, e.g. domain\username.  Once the person is added, the identity will be added to the TFS valid user group and will be available going forward.  The reason for this is the Web application is unable to check or browse the domain since it is browser based and not a desktop application.

Problems with Team Foundation Server 2012 RC Web Access in Internet Explorer

Working in the Web Access tool in Internet Explorer 9, I noticed most features missing from many of the screens. There are problems in the Control Panel screens, Product Backlog, etc. Key elements of the page do not load. What makes it even more puzzling is everything works in FireFox and Chrome.

If you are experiencing this problem, refreshing the page (F5) loads all elements of the page. However, this is on a page-by-page basis. The problem may be caused by an add-on. In my case, it is the Google Toolbar. I disabled the toolbar and set the default search for address bar searching to google in Internet Explorer. The Web Access application is now working.

Team Foundation Server 2012 RC Install Error: TF400534 : Package (tfs_servercoreres_x64) caching failed with the following status : 0x80070001. HRESULT : 0x80070001

If you get this error at the start of the installation process, chances are it is corrupt. The size of the download should be around 1.07 GB. If it is around 900 MB, download it again from

You should see an Installation Options section near the middle of the page.

Transaction Error Calling SQL Server 2000 from Data Layer

During the implementation phase of an engagement where I re-architected their system using a layered approach, one of the developers was getting the following error when calling a SQL Server 2000 database.

“The transaction has already been implicitly or explicitly committed or aborted”

The data layer is using the Enterprise Library 5.0 Data Access Application Block.  All calls are wrapped in a TransactionScope using a connection string from an app.config file.  There is a generic delegate called InstanceReader that accepts an IDataReader as a parameter.  The snippet of code below shows how it is written.

This works for SQL Server 2005 and SQL Server 2008, so it was puzzling why SQL Server 2000 was complaining about it.  The advice in the community was to enable MSDTC.  That did not resolve the problem.  Not knowing where to go next, I decided to look at the connection string options to see if there were something special that needed to be passed in for SQL Server 2000.  I did not find anything that was SQL Server 2000 specific, but I did find something that looked promising when looking up the ConnectionString property on MSDN –

There is a keyword called “Enlist” which is set to true by default.   The keyword is described as “true indicates that the SQL Server connection pooler automatically enlists the connection in the creation thread’s current transaction context”.  Apparently, in SQL Server 2000, it tries to enlist a second transaction even when one has already been established using TransactionScope.  The following connection string does not work with SQL Server 2000.

<add name=SQL2000ConnectionString connectionString=Database=MyDatabase;Server=.;Integrated Security=SSPI providerName=System.Data.SqlClient />

But, adding the Enlist keyword and setting it to false resolves the problem as seen below.

<add name=SQL2000ConnectionString connectionString=Database=MyDatabase;Server=.;Integrated Security=SSPI;Enlist=false providerName=System.Data.SqlClient />

I tried to get them to disable MSDTC to see if that really needed to be enabled, but they were struggling with it for a couple of days and were not in the mood to experiment.  Maybe next time.

Team Foundation Server Integration Tools – Watch Your Shared Step

One of my clients had recently created a Team Project in TFS 2010, but after a few weeks, decided they wanted to change the name of the Team Project.  Since this is not supported in TFS 2010, we decided to create a new Team Project with the new name and use the Integration Tools to move the work items and source code over.  Being a TFS 2010 to TFS 2010 migration, I expected everything to go smoothly and for the most part it did.  After confirming that everything got migrated correctly, I removed the users permissions from the old Team Project and directed them to use the new one.

After a couple of days, I started to receive reports from a few of the testers that they could not open their Test Cases.  They were getting the following error “TF26198: The work item does not exist or you do not have permissions to access it”.  I was able to open the Test Cases.  They also were unable to open some of the Requirement work items with the same error, but other Requirements they could open.

The problem turned out to be the Shared Steps work items.  Any Test Case that had Shared Steps or any requirement that linked to a Test Case that had Shared Steps could not be opened by the testers.  It turns out that the Integration Tools migrate the Test Cases and the Shared Steps correctly, but the mapping of the Test Cases to the Shared Steps is not.  The Test Cases were still pointing to the Shared Steps work items from the old Team Project.  For example, when opening the Shared Steps from a Test Case in the new Team Project, the work item id of the Shared Steps work item was the one from the old Team Project.  The reason why they could not open the Test Cases or Requirements was because I took their permissions away from the old Team Project.  Once I added their permissions back, they were able to open them.

The solution for me was to map the work item ids from the old Team Project’s Shared Steps to the new Team Project’s Shared Steps work item ids.  I then went through each Test Case and deleted the Shared Steps work items from the Manual Steps and re-added them with the equivalent Shared Steps work item in the new team project.  The other option would have been to go directly into the “WorkItemLongTexts” table of the TFS collection database and change the Shared Step reference in the XML data structure.  This probably would have taken just as long if not longer and would be very risky.  It is never a good idea to change data directly in the TFS databases.  Luckily, they only had around 50 Test Cases, so it took a couple of hours to fix.

I have not tried it yet, but there is the Test Case Migrator plus tool that is supposed to migrate all Test Case related work items over correctly.  It can be found at