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

Uprear

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.

Uprear

Nick, did you keep the AuthorizeAttribute on your controller? How did you set up IIS's Authentication, that is to ask, which modules are enabled? I'm getting the same error and haven't found the solution yet. I am using ASP.NET Impersonation & Windows Authentication. – Glossator

I did keep the AuthorizeAttribute on my controller, yes. I just checked IIS and (surprisingly) the only module enabled is Anonymous Authentication. We've moved our IIS to a new server since I posted this question. I'm nearly certain I previously had Windows Authentication enabled as well, but either way the site is working correctly so I'm not messing with it. :-) – Uprear

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.

Aphid

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.

Barron

Same by me, after I deleted the folder shown above, everything worked fine. – Onassis

Answer 4

Check this response http://social.msdn.microsoft.com/Forums/vstudio/en-US/e4c84467-309a-45bd-9da8-973732897440/problem-with-microsoftteamfoundationworkitemtrackingclientdatastore?forum=tfsgeneral (Read All)

http://blogs.msdn.com/b/buckh/archive/2012/02/01/listing-the-work-items-associated-with-changesets-for-a-path.aspx

Indore