Debugging a WCF service issue

A common scenario is your web service failing, but no application errors occur (assuming that you are catching all exceptions and logging them, that is). This is what I usually try:


Where in the world is WCF Test Client?

I keep myself making that question on a new VS install.

It's tipically here:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\WcfTestClient.exe

Although it will change according to your Visual Studio version (i.e. "10.0") and CPU architecture (i.e. "x86").


Mocking an internal interface with Moq

If by some reason you need to Mock an internal interface using Moq, you might get the infamous exception while running your unit tests:
System.TypeLoadException : Type 'ISomething`1ProxyRandomGuid' from assembly 'DynamicProxyGenAssembly2, Version=, Culture=neutral, PublicKeyToken=YetAnotherGuid' is attempting to implement an inaccessible interface.

Assuming that you already added the InternalsVisibleTo from your library to your unit test project, you'll also need to add an InternalsVisibleTo to DynamicProxyGenAssembly2. However, unlike the author in the blog post, in my machine it only works if I remove the PublicKey, something like:


Trouble with MSMQ

This week I had an interesting issue with a project that used MSMQ. The issue was that I was sending messages using the MessageQueue class, but the messages didn't get there. No exception, no error code, nothing in the Event Viewer. Then I started "mmc", and added the "Computer Management" snap-in, and navigated to Services and Applications > Message Queuing. There I found that all my queues were OK (Private Queues), but no message was getting there. Then I found some errors in the "Outgoing Queues" folder, telling me that the queue did not exist.
So, what was the issue? Well, it happens that the NetBIOS name on my machine did not match my computer name. Our machine names are based on a convention which includes the  user surname, and mine is a little bit longer that most my colleague developers, which goes over the 15 character limit for NetBIOS naming conventions. Probably the administrator that configured my machine just cut the last character from the NetBIOS name, and never looked back again...


Parsing ISO 8601 periods

If you have to deal with ISO 8601 duration periods, such as "P1Y2M10DT2H30M", you can just parse it to a TimeSpan using the XmlConvert.ToTimeSpan() method. I'm not sure why this is isn't supported by TimeSpan directly, so thanks to Stack Overflow.

Unit Testing with WebRequest/WebResponse (and beyond)

The problem

As you work in TDD, you'll find some rough edges for Unit Testing in .NET, particularly with IO, Database and networking. If you are doing Unit Testing right, then you're interested in keeping your tests repeatable, isolated and fast, and you simply cannot read/write files, make SQL queries or send/receive network requests. Typically, you'll avoid this by keeping all your classes decoupled by interfaces, and instantiated them with a Dependency Injection framework (e.g. Castle Windsor), and finally mocking your dependencies in your unit tests with another framework (e.g. Moq). The challenge in .NET is that most of your IO/Database/Network classes do not offer interfaces, are sealed classes, and have static methods. Since this is not a new problem, there are several individuals who have come up with their solutions: build a wrapper library around the original implementations and expose it as interfaces. Two of such solutions are System.IO.Abstractions and SystemWrapper. Unfortunately, neither of these libraries includes the WebRequest/WebResponse classes (nor the FtpWebRequest/FtpWebResponse, the ones I actually needed), so I had to come up with a wrapper of my own. Since I can't share my employer's proprietary code, and I think this can be useful to others (or myself in the future), I decided to come up with my open-source library at github in my free time.

What's available (so far)

System.Net.Interfaces class diagram


Although I tried to make these classes/interfaces close to the original, there a couple of notable changes:
  • Not all methods and properties are exposed (namely asynchronous methods). WebRequest doesn't implement IDisposable.
  • Factory methods (such as WebRequest.Create) are available in an abstract factory: WebRequestFactory.
  • The library is built on .NET framework version 4.0. It could be built on version 2.0...
  • In some situations, WebRequest.GetResponse method will throw a WebException with an inner WebResponse object, instead of just returning the WebResponse object. In my opinion, this was a terrible design decision by the .NET team, but we have to live with it. I could catch that particular exception and return an IWebResponse, but I would be doing more than just wrapping...

  • Add some code samples showing how to use it
  • Extend it with other implementations (the WebClient class is the first that comes to my mind)
  • Make a NuGet package
  • Address some of the points in the "Notes" section
So, what do you think? Have you dealt with this kind of issues before? Do you have a different approach? Is this library useful at all?

Edit (2013-07-01): Unknown to me, Microsoft already solved this a couple of years ago, through the System.Web.Abstractions namespace (included with ASP.NET MVC 3.5), and more recently (.NET 4.0 onwards), included in the System.Web namespace.