I love LINQPad nearly as much as my wife. For quickly mocking up .NET code, debugging OData services or for general LINQ goodness it’s like a Swiss Army Knife. In C# Statements mode all objects and collections are extended with the Dump extension method. This allows viewing of an object or object hierarchy in a way that you’ll never beat with Debug.Writelines.
Using LINQPad to query a WCF Data Service or OData source looks something like this:
As LINQPad is the first tool I reach for when playing with WCF Data Services I was wondering if there was a way to also use it to access plain old web services. We have both ASMX Web Services and WCF Services that I need to interact with so I started hunting around for an approach for both.
Let’s take a look at using LINQPad to access both types of services…
Accessing ASMX Web Services with LINQPad
First we want to generate the client code for the desired web service. To do this we open a Visual Studio Command Prompt and call WSDL <url>.
Compile the client – run csc /t:library <generated code file from the last step>.
Add a reference in LINQPad to the compiled client and another to System.Web.Services.dll.
Call any method on the web service and use Dump() to show the results. It will automatically expand any nested collections.
Accessing WCF Services with LINQPad
The more complicated scenario is the usage of WCF Services. There are a few more steps involved to correctly access them within LINQPad.
First we want to generate the client code for the desired WCF Service. To do this we open a Visual Studio Command Prompt and call svcutil /config:<path to LINQPad’s config file> /mergeConfig <url>. This will also add the required settings to the LINQPad.config file. Do not specify LINQPad.exe.config as the target file. LINQPad uses a config file named LINQPad.config to store it’s application configuration and will not load settings from the LINQPad.exe.config file. If this is the first time you have executed this command then the LINQPad.config file may not exist and /mergeConfig should be excluded. After its initial creation the /mergeConfig should be included for any subsequent client generation so existing config values are not overwritten.
Compile the client – run csc /t:library <generated code file from the last step>.
Add a reference to the compiled client and another to System.ServiceModel.dll.
Call a method on the web service and attempt to Dump() the results.
In some cases you may receive an error in regards to the System.Runtime.Serialization.dll being required to call the web service. If this occurs then simply hit F4 to open the references for the current query.
LINQPad will detect that F4 was pressed and ask whether you want it to automatically add the missing reference. Select Yes to add the reference.
The resulting references should now look something like this.
Executing a method on the web service and calling Dump() for the results should display the response in an easy to navigate fashion.
As you can see the initial setup for using LINQPad with web services isn’t trivial. In my mind however, the ability to quickly test and visualise the response from these services more than makes up for initial configuration that needs to be performed.
Works like a charm. Many thanks 🙂
LikeLike
Oh, this is beautiful. Trying to work out the poorly documented web services at my current employer. This approach allows me to hook up an play with them in an interactive and visual (go Dump()!) way.
LikeLike
Even better! Use this Linqpad driver:
https://github.com/dylanmei/linqpad-soap-driver
Now you just put in the WSDL url and you can start executing web services calls right inside Linqpad.
LikeLike
I would enter a polygamous relationship with LinqPad. So awesome. Thanks for this tip!
LikeLike