13

I am attempting to switch to the TFS 2015 SDK dlls (Version 14) for a few reasons. First, they are in nuget and second, the 2013 SDK dlls (Version 12) require the 32-bit flag flipped in IIS.

I pulled down nutget package and the namespaces all line up with the existing version 12 namespaces.

Everything compiles fine and there was no error on local deployment.

However, when I attempt to load projects using the WorkItemStore service.

TfsTeamProjectCollection collection = new TfsTeamProjectCollection(URL);
var service = collection.GetService<WorkItemStore>();

I get:

Additional information: Unable to load DLL 'Microsoft.WITDataStore64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

When I switch back on the 32 bt flag in IIS I get:

Additional information: Unable to load DLL 'Microsoft.WITDataStore32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Note: this was all working code, all I did was remove the references to the GAC assemblies and add the NUGET package.

According to Microsoft, the nuget package should work with TFS 2013 and work for users for the 2013 SDK

Existing Windows apps leveraging an older version of the TFS Client OM.

Sam Sussman
  • 1,005
  • 8
  • 27
  • 1
    Renaming the WITDataStore.dll from the 64bit GAC to WITDataStore64.dll and copying it to the bin works. – Sam Sussman Aug 20 '15 at 21:33
  • You might want to check if the `Copy Local` property of the referenced assembly is set to: `False`, if it is, set it to `Always`. This way it will be copied to the output directory when the project builds. – Stefan Aug 20 '15 at 21:34
  • It isn't a referenced assembly and it wasn't before. I get an error when I try to reference it directly. – Sam Sussman Aug 20 '15 at 21:40
  • 1
    I will keep this question for reference. A bug has been submitted and a MS forum mod was able to recreate the error [here](https://connect.microsoft.com/VisualStudio/Feedback/Details/1695433) – Sam Sussman Aug 21 '15 at 15:06
  • Is it possible that a COM component isn't registered? The error message and HR result tend to point that direction. – Stefan Aug 21 '15 at 20:29
  • Well the TFS SDK was moved from a GAC install to a nuget package (2013 -> 2015). The simple switching to the NUGET package should contain all required dlls. That WITDataStore.dll was included in the GAC install, but not the nuget package. I am fairly sure at this point it was just missed. – Sam Sussman Aug 22 '15 at 23:03
  • http://stackoverflow.com/questions/34135086/how-to-solve-failed-to-add-reference-to-microsoft-witdatastore – Tim Abell Jan 16 '16 at 02:20
  • Related post - [Unable to load DLL 'Microsoft.WITDataStore32.dll' (TeamFoundation.WorkItemTracking)](https://stackoverflow.com/q/31031817/465053) – RBT Dec 21 '20 at 13:56

4 Answers4

5

None of the above worked for me. I had to copy that file to my C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE folder (found this out by using procmon to see where my app was looking for it).

Tom
  • 61
  • 1
  • 1
  • I copied the dll from IDE\ReferenceAssemblies\v2.0 to IDE, the issue is gone. – sky Jul 07 '17 at 08:04
  • This solved my issue. Does anybody know if there any way to point this to look in the bin directory of the project so that it can run from a machine without the visual studio directory structure? – Reed Mar 21 '18 at 15:40
2

I had to add the dll to the startup-project of my solution to get this to work. example:

MyTFSApp (windows client) nuget package Microsoft.TeamFoundationServer.ExtendedClient installed or Microsoft.WITDataStore32.dll added to the bin folder

MyTfsLibrary (class library with code accessing WorkItemStore) nuget package Microsoft.TeamFoundationServer.ExtendedClient installed

Jaan Marks
  • 19
  • 2
  • I added a post-build event to copy the 2 unmanaged DLLs to the startup bin folder: copy Microsoft.WITDataStore*.dll $(SolutionDir)[StartupProject]\bin – GarDavis Aug 14 '18 at 20:16
0

Copy file Microsoft.WITDataStore64.dll in folder C:\Windows\System32

Mikhail Zhuikov
  • 1,213
  • 2
  • 9
  • 19
-1

Try copying those Dlls from the GAC into your local bin. Nuget packages are usually create references to the bin, so if your program is looking there instead of the GAC that could be why it is throwing the error.

heilch
  • 161
  • 4
  • 14