TFS WorkItemStore throws a COMException in an ASP.NET MVC application when using authentication

Question

I am completely shocked by this and the endless google / stackoverflow searches did not help. I use the Visual Studio SDK 2012 to connect to TFS 2012 and request a work item store. The code below works fine both in a console application and in an ASP.NET MVC application that does not use authentication or in any script running on my local computer. However, I get a COMException when I try to create an instance of WorkItemStore from an MVC application that has been deployed to the server and uses (Windows) authentication.

It doesn't matter if I have a <authentication mode="Windows" /> element in my web.config or not; as long as there is a [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 called. If I remove the [Authorize] attribute, an exception will not occur. If I call the code below at some point before calling the code decorated with [Authorize] , an exception does not occur. Somehow using AuthorizeAttibute raises this exception.

Any ideas on how to solve this problem? Or at least to more accurately identify the real root problem? I would really like to understand what is happening 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): HRESULT error E_FAIL was returned from a call to the COM component.]

Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DataStoreNative.BeginDataStoreInit (descriptor IntPtr, 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 command) +23

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

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

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

Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.GetServiceInstance (enter 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 AppPool application to a domain account or to LocalSystem .

I can’t say that I completely understand what is going on behind the scenes here, but there seems to be some kind of conflict between the authenticated identity of the user browsing the site and the AppPool identifier, which was originally ApplicationPoolIdentity by default. If the main cause of the problem is unauthorized access or something similar, it seems to me that I should have received the same exception for anonymous users, as well as for authenticated users. I would also expect an actual Unauthorized Access Exception, rather than a COMEXception of 'undefined', so I really don't know what the real root cause is. If anyone comes across this issue and cares about developing it, please do so.

Answer 2

For me, this error appears in certain situations, for example, when I created a new site in the local IIS that uses the TFS API. I even followed the comments here to no avail, I had AppPool authentication for LocalSystem. I had a separate application pool. I have included 32-bit applications for the TFS API.

For me, the problem stopped when I changed the application pool from v4.0 to v2.0, and then returned to version 4.0.

I don’t know why he fixed the problem, but it worked for me.

Answer 3

The accepted answer worked for me, but did not seem optimal. I was able to fix this by deleting the following cache directories and / or by granting them application pool access rights.

Windows 7:

 C:\ProgramData\Microsoft Team Foundation 

Windows 8.1:

 C:\ProgramData\Microsoft\Team Foundation 

These folders are created when my applications use the TFS SDK.

Answer 4

Check this answer 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