I have a VS2010 developed utility application that will do TFS workitem query and check, and I can only use it on machines that already have VS2010 installed (I think Team Explorer 2010 should be the one that's really needed).
Nowadays we've moved to VS2019 on the client side since VS2010 is quite old and buggy, but the TFS server is still 2010, it's not easy to migrate because there is too many data on it.
Here comes the problem, I hope the utility could be updated so it can support running on machines that only VS2019 installed. Anyway, VS2019 can access TFS2010 by itself, why not the utility if I could develop it with VS2019?
First, I believe my code should be able to connect to TFS 2010:
using System;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;
namespace ConsoleApp2
{
class Program
{
static void Main(string[] args)
{
TfsTeamProjectCollection collection = new TfsTeamProjectCollection(new Uri(@"http://tfs:8080/tfs/DefaultCollection"));
}
}
}
It compiles smoothly, then it gives me these when I run it:
Unhandled exception. System.EntryPointNotFoundException: Unable to find an entry point named 'ZeroMemory' in DLL 'kernel32.dll'.
at Microsoft.VisualStudio.Services.Common.Internal.NativeMethods.ZeroMemory(IntPtr address, UInt32 byteCount)
at Microsoft.VisualStudio.Services.Common.CredentialsCacheManager.GetCredentialsFromStore(String targetName)
at Microsoft.VisualStudio.Services.Common.CredentialsCacheManager.GetCredentials(String featureRegistryKeyword, String targetName)
at Microsoft.VisualStudio.Services.Common.CredentialsCacheManager.GetCredentials(String featureRegistryKeyword, Uri uri, Boolean requireExactUriMatch, Nullable`1 nonInteractive)
at Microsoft.VisualStudio.Services.Client.VssClientCredentials.LoadCachedCredentials(String featureRegistryKeyword, Uri serverUrl, Boolean requireExactMatch, CredentialPromptType promptType)
at Microsoft.VisualStudio.Services.Client.VssClientCredentials.LoadCachedCredentials(Uri serverUrl, Boolean requireExactMatch, CredentialPromptType promptType)
at Microsoft.TeamFoundation.Client.TfsConnection.LoadFromCache(Uri serverUrl, ICredentials credentials)
at Microsoft.TeamFoundation.Client.TfsConnection..ctor(Uri uri, String locationServiceRelativePath, IdentityDescriptor identityToImpersonate, ITfsRequestChannelFactory channelFactory)
at Microsoft.TeamFoundation.Client.TfsConnection..ctor(Uri uri, String locationServiceRelativePath)
at Microsoft.TeamFoundation.Client.TfsTeamProjectCollection..ctor(Uri uri, Boolean fromFactory)
at Microsoft.TeamFoundation.Client.TfsTeamProjectCollection..ctor(Uri uri)
at ConsoleApp2.Program.Main(String[] args) in D:\Code\ConsoleApp2\ConsoleApp2\Program.cs:line 11
D:\Code\ConsoleApp2\ConsoleApp2\bin\Debug\net5.0\ConsoleApp2.exe (process 22888) exited with code -532462766.
Press any key to close this window . . .
To make the build successful, I added the references to dlls under C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\TestTools\TeamExplorerClient
:
Basically, I have no idea what I can do next, any advice or suggestion would be appreciated.
It looks like you're targeting .NET 5, most of the TFS client object model isn't ready to run under .NET Core and .NET 5+. Try creating your application as a .NET 4.7.2 application and try again. Especially the old Work Item Tracking code relies on a set of native libraries and SOAP services that haven't been ported. Azure DevOps Server now uses REST APIs for most of these requests instead.
And instead of referencing the assemblies directly from the visual studio installation folder, try adding a reference to the official nuget packages instead:
Microsoft.TeamFoundationServer.ExtendedClient
NOTE: I'm not 100% sure whether the latest version of the nuget would work, since TFS 2010 went out of support, but you can add an older version that 19.x if needed.
PS: Even though your TFS 2010 server is big and contains a lot of data, also think about the safety and integrity of that data. TFS only runs on unsupported Windows Server OS versions, against unsupported SQL Server versions and is itself no longer patched, updated and kept secure. If you value your source code, which I suspect you do, migration to Azure DevOps Server or Azure DevOps Cloud are highly recommended.