Creating Mock Web Services in .Net

So, a situation arises where your code needs to make a Web Services call out to a different system. Chances are you'll go through the usual stages of adding a Web Reference to your project in Visual Studio, and then use the generated code to make your call. Simple, right?

Well, yes, and Visual Studio goes out of its way to simplify the creation of this client code, so you can get on with calling the service rather than concern yourself with the plumbing that's required.

But what if the service you are calling charges you for every call you make? What if you can't guarantee that you will be online during the development of your code? What if that service is currently under development and you don't know whether it will be available when you are doing your testing?

If any of these apply you need to remove the external call to the web service from your code. In a unit test scenario you would probably use something like NMock and architect your code to use a dependency injection pattern: injecting an NMock created object that matched an expected interface.

In other cases what you can do is create a mock Web Service. One that matches the interface of the live one, but which you control.

You can easily create interfaces that match a WSDL file by using the WSDL.exe program. I have a sneaky suspicion that this tool is used to create the client code from Visual Studio when you add a new Web Reference, but it can also perform the other way around.

First, obtain the WSDL of the Web Service you want to mock up. (If you are calling a .Net Web Service, then the path will probably end .asmx. To get the WSDL, just append ?wsdl to the path and you'll get the WSDL XML). Save this to your local machine.

Open up the Visual Studio Command Prompt and type wsdl.exe. You should get a heap of text explaining the command line switches, but if you don't your paths aren't mapped correctly. The wsdl.exe file should be somewhere on your machine though :)

Once you've found the tool, type

wsdl /language:CS /namespace:Your.Namespace.Here /out:Directory\To\Save\To\ /protocol:SOAP /serverinterface finally-your-wsdl-file-here.wsdl

There are other options too if you need them, like setting proxy username and passwords, but the one shown is what I've used and it works fine.

This will create a .cs file in the /out directory that contains a number of classes that match the object definitions in the WSDL. It will also contain one interface that you must implement in order to complete your mock Web Service.

To do this, create a new ASP.Net Web Application. (I guess you could create a Web Site, but I've not tried that as I don't like them). Add the code file you generated above to the project, then add a new Web Service.

In the code behind for this Web Service, change the class definition so that it implements the interface in the generated code. Visual Studio should help you out by generating method stubs so the class matches the interface.

And there you have it, place code in the method stubs to do what you want.

You now have your mock web service. Run the application to make sure that it works, and then make a note of the address of the new mock service. Enter this as the URL of the web service you want to call in your App/Web.config file in place of the live one, and your application should now call your mock instead of the live one.

A little tip though. I've noticed that (at least Visual Studio 2008) doesn't like attaching to 2 IIS processes for debugging. If you are calling your mock service from an ASP.Net application and you want to debug both, you'll need to start one of the applications up in the Visual Studio Development Server, instead of running under IIS. If you do this, make sure you assign an explicit port value rather than an auto generated one, otherwise your calling code won't be able to call it :)

Refactoring

I've currently got a post on ice about using CLR functions in SQL Server 2005 using LINQ (don't worry Paul, I've not forgotten), but while I mull that over I'll just make a short point about refactoring code.

Regular readers (and Google Analytics tells me that I do have some, at least), might have picked up on a few complaints I've had about VB.Net. Personally I wish I'd never have to use it, but sometimes rewriting an entire app in C# isn't cost effective so... needs must, and all that.

Well, I was recently in the midst of a ton of VB.Net code, thinking "I could do with some IDE refactoring support here," after needing to extract a code block into its own method. Except I can't find any such support in Visual Studio 2008 for such an option.

Using C# in Visual Studio (2005 and 2008), we have a neat little context menu option called Refactoring, and while it doesn't offer the depth of features that something like Resharper offers, it at least allows you to Extract Method, which was the refactoring technique I needed to use.

Long story short, I found this post from the VB.Net Technical Lead:

I’d never even heard of refactoring until C# added the feature to their IDE. I’ve never bought a copy of, much less read, Refactoring: Improving the Design of Existing Code.

I let out an audible sigh after reading that. In a way it explains a great deal about VB.Net.

Refactoring should be something that every professional developer knows about and practices every day of their working lives. It is an integral part of the development cycle, and one which even graduates should at least be aware of.

If we do not refactor we end up repeating code needlessly. Although this might produce a working application that passes all current tests, put yourself 6 months, or 6 years down the line where you have to add a new database table, or a column to a table, or a new page to your web application.

If you've essentially been copy and pasting code, how many places in the code base do you have to change to add that small piece of new functionality? Answer: unknown, especially if you weren't involved in the initial project. How do you know that you've caught all the places without executing every branch of the application?

Answer: you don't, not until you get irate customers yelling at you, and your managers asking why such a small change resulted in the entire app breaking.

And it's such a simple thing that I have difficultly believing that any developer worth their salt wouldn't see the benefits that it gives. So if you don't know, then read up and get using it. Your code can only get better.

IEnumerable to DataSet Extension Method

I recently had a need to create a DataSet from a List<T>, and found this post that did just that. I was happily using that in C# code, but then had a requirement to use it from a VB.Net app.

I'm not even going to attempt to hide my contempt for VB, and one of the things that I quickly tire of is typing the exact same thing multiple times. The Intellisense in VB also doesn't seem as smart as it is in C#, mainly it doesn't help as much when instantiating objects.

So I wanted a simpler way of calling the code that I had from the post above, and I immediately thought of extension methods. If I could create an extension method that made a DataSet from an IEnumerable then I could call that from the VB app with a minimal of fuss.

Kudos must go to Keith Elder for his original code, but if you want it in extension method form, then here it is:

public static class CollectionExtensions
{
public static DataSet ToDataSet<T>(this
IEnumerable<T> collection, string dataTableName)
{
if (collection == null)
{
 throw new ArgumentNullException("collection");
}

if (string.IsNullOrEmpty(dataTableName))
{
 throw new ArgumentNullException("dataTableName");
}

DataSet data = new DataSet("NewDataSet");
data.Tables.Add(FillDataTable(dataTableName, collection));
return data;
}

private static DataTable FillDataTable<T>(string tableName,
IEnumerable<T> collection)
{
PropertyInfo[] properties = typeof(T).GetProperties();

DataTable dt = CreateDataTable<T>(tableName,
collection, properties);

IEnumerator<T> enumerator = collection.GetEnumerator();
while (enumerator.MoveNext())
{
 dt.Rows.Add(FillDataRow<T>(dt.NewRow(),
enumerator.Current, properties));
}

return dt;
}

private static DataRow FillDataRow<T>(DataRow dataRow,
T item, PropertyInfo[] properties)
{
foreach (PropertyInfo property in properties)
{
 dataRow[property.Name.ToString()] = property.GetValue(item, null);
}

return dataRow;
}

private static DataTable CreateDataTable<T>(string tableName,
IEnumerable<T> collection, PropertyInfo[] properties)
{
DataTable dt = new DataTable(tableName);

foreach (PropertyInfo property in properties)
{
 dt.Columns.Add(property.Name.ToString());
}

return dt;
}  
}

It creates a DataSet with one table that has the name you pass in. In my case I didn't need to name the DataSet explicitly so just used a constant, but the code above could easily be updated to pass in a DataSet name if you need it.

Now you should be able to call ToDataSet on any object that implements the IEnumerable interface.

C# Extension Methods Part 2: Extending Log4Net

OK, so after last time's brief introduction I'll share with you a Log4Net extension that I've made. It's nothing really too complicated but I hope it will highlight what I feel are the advantages of this technique.

So, on to business. If you're like me you'll like your logging code. I think logs are wonderful, if only to check that your code is doing what you think it is. Of course, there's always the chance that you'll have too much logging, but that's what log levels are for, right? ;)

The following is a common pattern I use for logging at pretty much every level (I've shown Debug here):

int someValue = 3;
if (log.IsDebugEnabled)
{
 log.DebugFormat("This is a value: {0}", someValue);
}

Here I have a value I want to log, so I check that we should log and then log out the value. In this case I guess the check is superfluous, as the statement won't be output if we're not logging at debug anyway, but I like to get into the habit of checking so that when I need to log something like this:

if (log.IsDebugEnabled)
{
 StringBuilder builder = new StringBuilder();
 for (int i = 0; i < 100; i++)
 {
     builder.Append(GetSomeLogStatement(i));
 }

 log.Debug(builder.ToString());
}

I only go into the long running loop if I'm going to get some logging output from it.

When debugging code I like to have log statements that show where the execution path is going. The easiest way of doing that is to output a log statement when you enter a public method, but if you're doing this a lot then that's a lot of code being reproduced.

That's when I thought about making an extension method to handle all this for me. Here's the code:

public static void LogMethodParameters(this ILog logger, Level level,
string methodName, params object[] parameters)
{
try
{
if (logger == null)
{
throw new ArgumentNullException("logger");
}

if (level == null)
{
throw new ArgumentNullException("level");
}

if (methodName == null)
{
throw new ArgumentNullException("methodName");
}

if (logger.Logger.IsEnabledFor(level))
{
StringBuilder builder = new StringBuilder();
builder.AppendFormat("Method: [{0}]. ", methodName);
if (parameters != null && parameters.Length > 0)
{
 // parameters.Length is at least 1
 builder.AppendFormat("Parameters: (p0: [{0}]", GetParameterDisplayValue(parameters[0]));
 for (int i = 1; i < parameters.Length; i++)
 {
  builder.AppendFormat(", p{0}: [{1}]", i, GetParameterDisplayValue(parameters[i]));
 }
 builder.Append(")");
}

logger.Logger.Log(null, level, builder.ToString(), null);
}
}
catch (Exception ex)
{
log4net.Util.LogLog.Error("Exception while logging exception", ex);
}
}

private static object GetParameterDisplayValue(object param)
{
return param != null ? param : "(null)";
}

public static void DebugMethodParameters(this ILog logger,
string methodName, params object[] parameters)
{
LogMethodParameters(logger, Level.Debug, methodName, parameters);
}

Like I say, it's nothing too complicated, but it allows you to include this line at the top of each of your public methods:

log.DebugMethodParameters("Method", 1, 2, 3);

And you don't need to worry about anything else, your log file will show that you entered the method with those parameters.

What I wanted to do was use reflection to figure out what the current method was and what the parameter values are, but this was just a little side task I had to do while in the middle of something else.

Here are some additions I could make to this method:

• Use reflection to get the method name and parameter names
• Incorporate the Visual Studio 2008 ObjectDumper sample to drill down into complex objects to provide a fuller picture of non-primitive types
• Allow custom formatting of the log output

This is just the start really. Check out extensionmethod.net for some more samples of what else you can do. (Hmm, that site seems to be having a few problems at the moment, but check back later and browse what they have).

C# Extension Methods Part 1: Introduction

Extension methods are a new feature of C# 3.0 with .Net 3.5. They allow you to extend existing classes with new methods without having to create a whole new class that inherits from the class you want to add the method to. First off, why would you want to do this?

Well, as an example LINQ makes heavy use of extension methods to provide the functionality to create new expressions easily. A LINQ extension method might extend IQueryable to apply a custom where clause, for example. In fact, as part of the Visual Studio 2008 samples you'll find a set of extension methods that does just that.

So what does an extension method look like? Here's a very simple example:

public static string Reverse(this string str)
{
 if (str == null)
 {
     throw new ArgumentNullException("str");
 }

 StringBuilder builder = new StringBuilder();
 for (int i = str.Length - 1; i >= 0; i--)
 {
     builder.Append(str[i]);
 }

 return builder.ToString();

}

Here we have a static class StringExtensionMethods that contains a Reverse method, which reverses the order of the characters in a string.

Notice that the parameter being passed into the Reverse method has the "this" keyword preceding it. This tells the compiler that this is an extension method for the string class.

You can now use this method on any string object in any class that uses the namespace that this static class is in. We also get full Intellisense support in Visual Studio 2008:

There are a few things to be aware of though. Consider this piece of code:

string thisIsNull = null;
Console.Write(thisIsNull.Reverse()); 

If Reverse was a standard method on the string object, then we would get a NullReferenceException being thrown when we try to call the method.

However, an extension method on a null object will still be called. It is the responsibility of the extension method to check for null values.

The extension method is pretty much just syntactic sugar around a standard static "helper" style method. So when the method is called it doesn't actually need to be part of an instance.

For this reason, make sure you should still check that the parameter is not null before using it, as you would in a normal method.
As a quick aside, this is a perfectly functional extension method:

public static bool IsNull(this object obj)
{
 return obj == null;
}

It could then be called like this:

string thisIsNull = null;
if (thisIsNull.IsNull())
{
 Console.Write("Was null");
}

So we can create extension methods that easily provide some additional functionality to a class. Next time, I'll show how I've implemented a simple extension method to Log4Net.

Beginning Lambda Expressions in C#

I think I've been using LINQ to SQL for about a week now, and one of the (many) things to conquer on that particular learning curve are lambda expressions.

Lambda expressions are a new feature of C# 3.0 using .Net 3.5, and look something like this:

t => t.Contains("hello")

When starting out this expression can look very strange, but once you get your head around it they are pretty simple... well, in most cases.

Lambda expressions are like anonymous delegates, they have input parameters, and an output result, and the new => syntax ties them both together. What the example above means is that there is a parameter "t" (in this case a string), and it returns a bool (the return type of the string.Contains method).

But how do we know what these types are? They can be inferred from the type declaration. The above example would be meaningless on it's own, but when put together like this:

// delegate that takes a string and returns a bool
public delegate bool CheckString(string arg);

// create an instance of the delegate using a lambda expression
CheckString newDelegate = s => s.Contains("hello");

// use the delegate to show the expression works
Console.WriteLine("Value: {0}", newDelegate("hello world"));

We can see that the types are inferred from the fact we are creating a CheckString delegate. The delegate would return true when called with this string.

So how does this help us with LINQ? Well, in LINQ queries you'll often see that you need to specify parameters that have types that contain something like this:

Func<T0, TR>

And what the hell does that mean? Well, as part of the framework we have the following generic delegates already defined for us:

public delegate TR Func<TR>();
public delegate TR Func<T0, TR>(T0 a0);
public delegate TR Func<T0, T1, TR>(T0 a0, T1 a1);
public delegate TR Func<T0, T1, T2, TR>(T0 a0, T1 a1, T2 a2);
public delegate TR Func<T0, T1, T2, T3, TR>(T0 a0, T1 a1, T2 a2, T3 a3);

These delegates simply say that given the types specified, the delegate should return a type. In an abstract way, that's all a delegate is really: so don't worry that it can look a bit crazy.

Using this I could rewrite the previous example like this:

// create a lambda expression
Func<string, bool> newDelegate = s => s.Contains("hello");

// use the delegate to show the expression works
Console.WriteLine("Value: {0}", newDelegate("hello Mr Coupland"));

I don't have to define a CheckString delegate any more, and can just use the inbuilt generics to specify what the delegate interface is.

So what does this all mean? Well, if you need to pass in delegates to a method call, instead of having to define the delegate's interface, then structuring an anonymous delegate to match it, you can just use one of the Func delegates and a lambda expression, like in this really contrived example:

// create a boring method that doesn't do much
public bool StringConditionCheck(string str, Func<string, bool> exp)
{
  return exp(str);
}

// call the method from somewhere else
public void MyOtherMethod()
{
  Console.WriteLine(StringConditionCheck("sjdl", s => s.StartsWith("s")));
}

That example's probably a little too simple, but it shows what you can do with a lambda expression passed in to another method.

This is nothing new in itself, you can do all of that with anonymous delegates in .Net 2.0 (and with normal delegates before that), but now there's less code to write.

And when you can create delegates so effortlessly, it makes creating generic Expressions for our LINQ expression trees really simple, but that's for another post.

More on goto in C#

Akidan's posted a comment back on my old "goto" post from October last year, and it's got me thinking about it again. The original post was prompted by seeing gotos in .Net Framework code using Reflector, but what we were actually seeing was an optimised version of the code.

The real question comes down to code readability. A high level language like C# has constructs that make a goto statement superfluous, and a compiler which is able to recognise when a goto can replace some branching code. So from the perspective of writing high performance code, we don't need to worry: we can let the compiler figure out how best to structure the internal workings for us.

And here is the crux of the matter. If we don't need to worry so much about execution speed, then surely we should write code with an eye towards maintainability?

Now, I'm not saying that gotos make code inherently unmaintainable or unreadable: I'm willing to accept that there could be situations where they can be used, but only then used with caution.

I still stand by my belief that gotos should be avoided in code that you write yourself. Using Akidan's two methods as an example: the non-goto one is certainly more readable. It's clear that the "if" is comprised of 2 checks that results in the same outcome, and having them together like that makes it difficult to separate them later on by mistake.