TFS WorkItemStore throws COMException in ASP.NET MVC app when using Authentication

Question

I'm completely stumped by this and endless google/stackoverflow searches haven't helped. I'm using the 2012 Visual Studio SDK to connect to TFS 2012 and query the work item store. The code below works perfectly fine in both a console application and an ASP.NET MVC app that does not use authentication, or in any scenario that's run on my local machine. However, I get a COMException when I try to instantiate a WorkItemStore from within an MVC app that's been deployed to the server and uses (Windows) authentication.

It makes no difference if I have the <authentication mode="Windows" /> element in my web.config or not; as long as there is an [Authorize] attribute on my controller or any of its action methods, I get an exception as soon as the last line of code below is invoked. If I remove the [Authorize] attribute, the exception does not occur. If I call the code below at some point before calling code decorated with [Authorize], the exception does not occur. Somehow, using the AuthorizeAttibute is inducing this exception.

Any ideas of how to resolve this? Or at least for more exactly identifying the real root problem? I'd really like to understand what is going on here.

Uri tfsAddress = new Uri("http://tfs-address:8080/tfs/DefaultCollection");
var myCreds = new NetworkCredential("userName", "password", "domain");
var tfsCreds = new TfsClientCredentials(new WindowsCredential(myCreds), false);

var defaultCollection = new TfsTeamProjectCollection(tfsAddress, tfsCreds);
defaultCollection.EnsureAuthenticated();

var store = defaultCollection.GetService<WorkItemStore>(); // <-- EXCEPTION

Stack trace:

[COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.]

Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DataStoreNative.BeginDataStoreInit(IntPtr handle, String defaultCachePath, String instanceId, Int32 cacheVersion) +0

Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.Datastore.BeginDataStoreInit(String defaultCachePath, String instanceId, Int32 cacheVersion) +56

Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal() +598

Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITfsTeamProjectCollectionObject.Initialize(TfsTeamProjectCollection teamProjectCollection) +23

Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.InitializeTeamFoundationObject(String fullName, Object instance) +43

Microsoft.TeamFoundation.Client.TfsConnection.CreateServiceInstance(Assembly assembly, String fullName) +91

Microsoft.TeamFoundation.Client.TfsConnection.GetServiceInstance(Type serviceType, Object serviceInstance) +200

Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.GetServiceInstance(Type serviceType, Object serviceInstance) +439

Microsoft.TeamFoundation.Client.TfsConnection.GetService(Type serviceType) +241

Microsoft.TeamFoundation.Client.TfsConnection.GetService() +58

Answer 1

The solution was to change the identity of the application's AppPool to either a domain account or to LocalSystem.

I can't say I fully understand what is going on behind the scenes here, but it seems there was some kind of conflict between the authenticated identity of the user browsing the site and the AppPool identity, which was originally the default ApplicationPoolIdentity. If the root cause of the problem is unauthorized access or something similar, it seems to me that I should have gotten the same exception for anonymous users as well as authenticated ones. I'd also expect an actual Unauthorized Access Exception, not an 'undefined' COMException, so I really don't know what the real root cause is. If someone comes across this question and cares to elaborate, please do so.

Answer 2

For me this error appears under certain situations, like when I created a new site in local IIS which uses the TFS API. I even followed the comments here to no avail, I had the AppPool Identity set to LocalSystem. I had a separate app pool. I had 32bit applications enabled for the TFS API.

For me the problem ceased when I changed the app pool from framework v4.0 to v2.0 and then back to v4.0.

I don't know why it fixed the issue, but it worked for me.

Answer 3

The accepted answer worked for me, but didn't seem optimal. I was able to fix this by also deleting the below cache directories and/or giving the application pool user permissions to them.

Windows 7:

C:\ProgramData\Microsoft Team Foundation

Windows 8.1:

C:\ProgramData\Microsoft\Team Foundation

These folders seem to be created whenever my applications utilize the TFS SDK.