Introduction

There are times when you need to use the WCF test client in places where Visual Studio is not installed, namely a production server or a non-developer machine at times. There is a post on StackOverflow that addresses this exact concern: http://stackoverflow.com/questions/6340082/downloading-wcf-test-client-without-vs However as time moves on the answers are becoming a little outdated; and if you work at an organization like I do where the network security is above average, bordering insane, then you cannot just download anything you want as it is blocked. I cannot download files from google drive or onedrive. Therefore I had to recreate a portable WCF test client for myself yesterday following the instructions that are provided on the stack overflow post and msdn forum. I just want to document what I did so I can re-reference it later if needed.

Before we get started

The whole point here is to produce a transportable copy of the WCF test client so that you don’t need Visual Studio to be installed where you are trying to perform your WCF test. There is just one ironic caveat here – you absolutely need a machine that has Visual Studio installed in order to actually produce a transportable copy of the WCF test client. Therefore if you don’t have a machine where this can be done, then you are doomed to download a copy of the WCF test client – hopefully that is an option for you. Even the strongest network security cannot thwart the following efforts at times (depends on how insane your company’s security is):

Temporarily hosting files on a web server
FTP in some cases
Downloading files to your phone and moving them over using any method you can think of
Email if the files are small enough
IM clients
USB drives
Portable hard drives

I am not advocating doing anything illegal or something that will violate your company’s workplace policies, but at the same time some of these restrictions are so suffocating we, as developers, cannot get our jobs done. Not being able to simply download the WCF Test Client from the web is a good example of this – therefore the work around is I have to create it myself.

Your version of Visual Studio dictates what you need to do

The following table is a transformation of information from this post here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/c3c7221c-c06f-4364-887a-fb20f22877be/wcf-test-client-problem I am giving credit where credit is due to Jakub Berezanski who aggregated this very useful information. Thank you to goes to him.

How to do this, using a Visual Studio 2015 (v14.0) installation

I wrote a batch file that will copy down the files for me and in my opinion the registry keys are the most complicated part. Therefore the steps are as follows:

Copy down the required files according to the above table
Export the required registry keys
1. I recommend just exporting the x86 and x64 versions of the registry keys. I highly doubt having both will brick your machine because something has to be looking for those keys in order to actually flip out. Therefore this is pretty harmless. If you are paranoid then just stick to your box’s architecture.
2. I strongly recommend including the “InstallationFolder” key and setting it to literally what you see here: “\\” – when I didn’t include this I got a run time error. In Jakub’s post, he says you don’t need it, this is where we disagree. Whatever – this is all by trial and error.
Copy all of the files you copied from your development machine to the target machine.
Copy over the registry export file and just double click on it in order to add those keys
Run the WcfTestClient.exe and you should be good to go

Supporting example

Here is an example of the batch file to execute. Take notice that it will copy the files to the current directory. You can change this if you want. Copy this as is into a text file and give it a *.bat extension. Double click to run.

XCOPY /Y "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfTestClient.exe" ".\"
XCOPY /Y "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll" ".\"
XCOPY /Y "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcUtil.exe" ".\"
XCOPY /Y "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcConfigEditor*.*" ".\"

PAUSE

Here is an example of the exported registry values for Visual Studio 2015 (v14.0). Copy this as is into a text file and give it a *.reg extension. Double click to import the keys into the target machine.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v10.0A\\"
"ProductVersion"="4.6.00081"
"ProductName"="Microsoft .NET Framework 4.6 SDK"
"KitsInstallationFolder"="\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools]
"ProductVersion"="4.6.00081"
"ComponentName"="Microsoft .NET Framework 4.6 SDK"
"InstallationFolder"="\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x64]
"ProductVersion"="4.6.00081"
"ComponentName"="Microsoft .NET Framework 4.6 SDK"
"InstallationFolder"="\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86]
"ProductVersion"="4.6.00081"
"ComponentName"="Microsoft .NET Framework 4.6 SDK"
"InstallationFolder"="\\"

If it really bothers you to add all of those keys, feel free to not include them in your file.
Take notice that the KitsInstallationFolder and InstallationFolder keys are set to “\\”, this is the only edit I had to make. When you export them, these are actually filled in – you don’t want that on your target machine because VisualStudio is not installed, therefore it is directing the program to the current directory that the executable is running in.

Downloads

If you are able to download files freely, then you can get this data here:

WCF Client Test – Batch file and Registry key – look at the source on GitHub
WcfTestClient_fromVS2015_v14.0.rar – download the finished product in a RAR file
WCF Test Client by version.xlsx – excel file of the above HTML table

01/28/2020 Update – Visual Studio 2017

It’s been a long time since I updated this article – I just haven’t had the time it would take to figure out what was required. Here is my updated answer for Visual Studio 2017. When I actually get around to installing Visual Studio 2019 I will update again.

The problem this time around is a bogus error that would keep popping up stating that:

System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Build.Utilities.Core, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.
File name: ‘Microsoft.Build.Utilities.Core, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’

This is a bogus problem because on further inspection you will find that the configuration for the “WcfTestClient.exe.config” is clearly trying to point to a relative location of the “Microsoft.Build.Utilities.Core.dll”. This took me a bit to figure out.

Solution

You have to modify the config’s “codeBase” node from this:

<codeBase version="15.1.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" />

to read like this

<codeBase version="15.1.0.0" href="Microsoft.Build.Utilities.Core.dll" />

Which means that the DLL it needs is localized.

First thing’s first – you need to copy all of the required files to a local destination – so modify this batch file as needed:

ECHO OFF

set "dest=C:\DumpFolder\"

set "source=C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin"

XCOPY /Y "%source%\Microsoft.Build.*.dll" "%dest%"

XCOPY /Y "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.VirtualTreeGrid.dll" "%dest%"

REM This depends on which DotNet you have installed - changed the version accordingly
set "source=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools"

XCOPY /Y "%source%\SvcConfigEditor.*" "%dest%"
XCOPY /Y "%source%\SvcUtil.exe" "%dest%"

set "source=C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE"

XCOPY /Y "%source%\WcfTestClient.*" "%dest%"

ECHO Manually update the WcfTestClient.exe.config's codeBase node - change the value of the "href" attribute to "Microsoft.Build.Utilities.Core.dll"

PAUSE

I haven’t found a need to import any registry keys this time around. After copying the files locally you will want to follow the instructions above for updating the configuration.

I tested this on a machine that doesn’t have any development tools on it and it worked. I can’t guarantee anything though.

Be aware that:

I am probably copying more files than required but that’s because I am not sure what all the dependencies of “Microsoft.Build.Utilities.Core.dll” are.
The version of Dot Net Framework you have installed will affect the above batch file.

Holy moly, it’s the 1st of February 2025, and this guide is still useful. Well, ‘useful’ is an understatement – it was a lifesaver!

I’m working on a project where I am, more or less, the Grim Reaper for the infrastructure of an EOL product, dismantling a whole infrastructure bit by bit: backend systems, public endpoints, servers, domains, and everything above, under, and between. In general, a quirky assignment with a lot of curveballs.

One of those curveballs was to trigger some scheduled tasks for the very last time before fully canning a larger solution that was one part of the now EOL product. Sounds easy enough, right? Not in this universe.

It turns out this is an exe-file with one argument that, in turn, triggers two other “workflows” where the first one, of course, fails for the first time since sometime in 2014. Literally 2014.

I knew immediately why it failed: it was only a revoked API key, and I already had the data we needed processed in the next step, which should start after the first one has completed. Naturally, I started to dig around in config files, log files, databases, and whatever else I could find, to no avail.

The source code should surely have the answer, right? Personally, I still think the source code holds the answer. The small problem I met here was that I couldn’t find the solution in TFS. Yes, TFS. A TFS setup that we have been using since at least 2008 and lived through several company mergers and splits. The impression I give must make it sound like a small basement side hustle; it’s not. Although, in all fairness, I think the last check-in to TFS was sometime in 2023.

Anyway, after “some” more digging, I found the Holy Grail: some documentation! A Word document hastily written by a developer days before he quit on the spot and left the company in 2019. A part of the documentation I think fits perfectly here is this, only slightly anonymized, section: “This link between [product] and [third party API] was created, as a temporary solution, in 2013. The idea was that this system would be running only until the [product’s] customers were migrated to [new license system], however that migration never actually happened.”

As you might have guessed, I found mentions of a svc endpoint, which led me to this site. I have multiple installations/versions of Visual Studio installed on my PC, all the way back to the 2015 version, for reasons that should be obvious by now.

It is now around 5 AM Saturday morning here, and the service is chugging along just fine in our beloved WcfTestClient.exe, processing one record at a time. Hopefully, all 8,000 of the records will be processed. Sometime, at some point.

Too bad I can’t share some of the juicier details of this ordeal, or the whole documentation I found – there are some real gems in it.

A big thank you, dear Author, for sharing this guide!

9 Replies to “Using the WCF Test Client without Visual Studio”

Steve says:

2017-09-11 at 11:08

Great article, thanks for posting this.

Pavel says:

2019-06-19 at 18:23

It seems it is not working for Visual Studio 2017
requires “Microsoft.Build.Utilities.Core, Version=15.0.0.0”

1. admin says:
  
  2019-07-23 at 16:16
  
  I am going to try to address this for you. I am currently only vacation so I actually have time to look at this. Sorry for the late reply.
  
2. admin says:
  
  2020-01-28 at 15:51
  
  I’m really sorry for how long it took for me to get back to you. I have updated the article. This was particularly hard to figure out. I tested my solution and it worked for me. Let me know if this works for you.
  
Luiz Baiao says:

2019-11-12 at 18:01

Some news about what was commented by Pavel
I have the same mistake

1. admin says:
  
  2019-11-17 at 03:51
  
  I totally forgot about this. I will see if I can take care of it this week. I have some WCF services I can test with at work on Monday.
  
2. admin says:
  
  2020-01-28 at 15:51
  
  I’m really sorry for how long it took for me to get back to you. I have updated the article. This was particularly hard to figure out. I tested my solution and it worked for me. Let me know if this works for you.
  
Andy says:

2025-01-31 at 23:43

Holy moly, it’s the 1st of February 2025, and this guide is still useful. Well, ‘useful’ is an understatement – it was a lifesaver!

I’m working on a project where I am, more or less, the Grim Reaper for the infrastructure of an EOL product, dismantling a whole infrastructure bit by bit: backend systems, public endpoints, servers, domains, and everything above, under, and between. In general, a quirky assignment with a lot of curveballs.

One of those curveballs was to trigger some scheduled tasks for the very last time before fully canning a larger solution that was one part of the now EOL product. Sounds easy enough, right? Not in this universe.

It turns out this is an exe-file with one argument that, in turn, triggers two other “workflows” where the first one, of course, fails for the first time since sometime in 2014. Literally 2014.

I knew immediately why it failed: it was only a revoked API key, and I already had the data we needed processed in the next step, which should start after the first one has completed. Naturally, I started to dig around in config files, log files, databases, and whatever else I could find, to no avail.

The source code should surely have the answer, right? Personally, I still think the source code holds the answer. The small problem I met here was that I couldn’t find the solution in TFS. Yes, TFS. A TFS setup that we have been using since at least 2008 and lived through several company mergers and splits. The impression I give must make it sound like a small basement side hustle; it’s not. Although, in all fairness, I think the last check-in to TFS was sometime in 2023.

Anyway, after “some” more digging, I found the Holy Grail: some documentation! A Word document hastily written by a developer days before he quit on the spot and left the company in 2019. A part of the documentation I think fits perfectly here is this, only slightly anonymized, section: “This link between [product] and [third party API] was created, as a temporary solution, in 2013. The idea was that this system would be running only until the [product’s] customers were migrated to [new license system], however that migration never actually happened.”

As you might have guessed, I found mentions of a svc endpoint, which led me to this site. I have multiple installations/versions of Visual Studio installed on my PC, all the way back to the 2015 version, for reasons that should be obvious by now.

It is now around 5 AM Saturday morning here, and the service is chugging along just fine in our beloved WcfTestClient.exe, processing one record at a time. Hopefully, all 8,000 of the records will be processed. Sometime, at some point.

Too bad I can’t share some of the juicier details of this ordeal, or the whole documentation I found – there are some real gems in it.

A big thank you, dear Author, for sharing this guide!

1. admin says:
  
  2025-02-09 at 00:13
  
  Hi! I am very happy to hear that this helped you. I have been asked before to provide an updated version of this documentation for newer versions of Visual Studio and I just never had the time to do it. The test client varies ever so slightly between Visual Studio versions and I had to deal with it again like back in 2021. I am surprised it’s still a thing, but hell even the company I work at now still utilizes WCF for some projects. Sorry I didn’t get back to you sooner, you know how it goes in our industry 🙂 so busy sometimes I cannot breath. I finally had a chance to read your comments and reply. Your workplace sounds typical in my experience. I have learned that over the course of my career, it doesn’t matter how big the work place is or how impressive their name is, once you get inside and see how the sausage is made it makes you cringe. It falls in line with the saying, “Never meet your heroes.” you know regardless of whether you were thrilled to work for an employer or not.
  
  Just a thought, it’s been several days now so maybe I am too late, but you can run multiple instances of the test client and process your work load in parallel effectively. Or just write a console application to do it for you. It’s pretty easy to do, you just need to have a MEX endpoint available to you, point your console application to the service via Service Discovery (built in tool in VS) and it will build a WCF Client for you in your application. Then you can put it into overdrive, of course up to you on how you want to handle it.

Obscure Problems and Gotchas

Introduction

Before we get started

Your version of Visual Studio dictates what you need to do

How to do this, using a Visual Studio 2015 (v14.0) installation

Supporting example

Downloads

01/28/2020 Update – Visual Studio 2017

Solution

Related

9 Replies to “Using the WCF Test Client without Visual Studio”

Leave a Reply Cancel reply

Visual Studio	Version	Required Files	Batch file	Required registry key
2012	11.0	C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\WcfTestClient.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\WcfTestClient.exe” “.\”	HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86
		C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll	XCOPY /Y “C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcConfigEditor.	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcConfigEditor.” “.\”
2013	12.0	C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\WcfTestClient.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\WcfTestClient.exe” “.\”
		C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_12.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll	XCOPY /Y “C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_12.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll” “.\”	HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1A\WinSDK-NetFx40Tools-x86
		C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\SvcUtil.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\SvcUtil.exe” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\SvcConfigEditor.	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\SvcConfigEditor.” “.\”
2015	14.0	C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfTestClient.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\WcfTestClient.exe” “.\”
		C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll	XCOPY /Y “C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.VirtualTreeGrid\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.VirtualTreeGrid.dll” “.\”	HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86
		C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcUtil.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcUtil.exe” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcConfigEditor.	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcConfigEditor.” “.\”
15 Preview	15.0	C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\WcfTestClient.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\WcfTestClient.exe” “.\”	HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86
		C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.VirtualTreeGrid.dll	XCOPY /Y “C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.VirtualTreeGrid.dll” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcUtil.exe	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcUtil.exe” “.\”
		C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcConfigEditor.	XCOPY /Y “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\SvcConfigEditor.” “.\”

Introduction

Before we get started

Your version of Visual Studio dictates what you need to do

How to do this, using a Visual Studio 2015 (v14.0) installation

Supporting example

Downloads

01/28/2020 Update – Visual Studio 2017

Solution

Share this:

Related

9 Replies to “Using the WCF Test Client without Visual Studio”

Leave a Reply Cancel reply