HTTP Web Requests in .NET

For whatever reason, when Microsoft developed the HttpWebRequest.GetResponse() method, if the status code of the response is 4xx or 5xx (for example a 404 not found response), it actually throws a WebException and you have to retrieve the Response object from the exception to test the status code of the response:

   1: try {
   2:     HttpWebResponse response = (HttpWebResponse)request.GetResponse();
   3:     ...
   4: } catch (WebException e) {
   5:
   6:     HttpWebResponse response = (HttpWebResponse)e.Response;
   7:     HttpStatusCode status = response.StatusCode;
   8:     ...
   9: }

In creating a custom client, I have found occasion where I would rather threat a 404 not found response, or a server error response like any other response. For example, it might be common in my application to get a 404 not found response returned by the web server, and I may be simply passing the response to the user. In this case, I would always have to catch the exception.

Ideally, I would like to derive a class from the HttpWebRequest and override the GetResponse() method to automatically handle WebExceptions associated with 4xx and 5xx responses. It appears that this is not possible. HttpWebRequest derives from the WebRequest class and provides additional properties and methods that enable interaction with servers using the Hypertext Transfer Protocol (HTTP). Instances of the HttpWebRequest class are automatically created by the WebRequest class. For example, an instance is created when the WebRequest.Create(uri) method is called and a Uniform Resource Identifier (URI) beginning with http:// is specified. Yet again, static methods are evil.

Plan B is to create a lightweight wrapper like so:

   1: using System;
   2: using System.Net;
   3: using System.Runtime.Serialization;
   4:
   5: namespace WebRequestTest {
   6:     // Class that wraps a HttpWebRequest object
   7:     public sealed class MyHttpWebRequest {
   8:
   9:         // The underlying HttpWebRequest object
  10:         private HttpWebRequest _request;
  11:
  12:         // The constructor takes a HttpWebRequest object
  13:         public MyHttpWebRequest(HttpWebRequest request) {
  14:             this._request = request;
  15:         }
  16:
  17:         // This method returns a HttpWebResponse object
  18:         public HttpWebResponse GetResponse() {
  19:             try {
  20:
  21:                 // If the response can be retrieved from the
  22:                 // underlying request, return it
  23:                 return (HttpWebResponse)this._request.GetResponse();
  24:             } catch (WebException e) {
  25:
  26:                 // Get the response from the WebException object
  27:                 HttpWebResponse response =
  28:                     (HttpWebResponse)e.Response;
  29:
  30:                 // If the exception is because of the status being
  31:                 // 4xx or 5xx, return the exceptions response object
  32:                 if ((int)response.StatusCode >= 400) return response;
  33:
  34:                 // otherwise rethrow the exception
  35:                 else throw;
  36:             }
  37:         }
  38:     }
  39: }

And now we can use the wrapper’s GetResponse() method to get an HttpWebResponse object regardless of the status code:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Text;
   4: using System.Net;
   5:
   6: namespace WebRequestTest {
   7:     class Program {
   8:         static void Main(string[] args) {
   9:
  10:             // Request a valid web resource
  11:             HttpWebRequest request =
  12:                 (HttpWebRequest)HttpWebRequest.Create("http://www.yahoo.com");
  13:
  14:             // Create instance of wrapper for the
  15:             // purpose of getting the response
  16:             MyHttpWebRequest myrequest =
  17:                 new MyHttpWebRequest(request);
  18:
  19:             // Get the response object and display the 
  20:             // status description
  21:             HttpWebResponse response = myrequest.GetResponse();
  22:             // This will display "OK"
  23:             Console.WriteLine(response.StatusDescription);
  24:
  25:             // Request a non-existent web resource
  26:             request =
  27:                 (HttpWebRequest)HttpWebRequest.Create("http://www.yahoo.com/thgy.html");
  28:
  29:             // Create instance of wrapper for the
  30:             // purpose of getting the response
  31:             myrequest = new MyHttpWebRequest(request);
  32:
  33:             // Get the response object and display the 
  34:             // status description 
  35:             response = myrequest.GetResponse();
  36:             // This will display "not found"
  37:             Console.WriteLine(response.StatusDescription);
  38:
  39:             Console.ReadLine();
  40:         }
  41:     }
  42: }

Testing Regex

Going through an entire compile / debug cycle only to find that a Regex is not behaving as intended is not a good use of a developer’s time (well, it’s not a good use of my time anyway). There is a better way.

The Problems with Regex

Regex, or regular expressions, represents a formal language that provides an extremely concise way to parse strings of text. To be honest, there are no problems with Regex itself. The problem is you need a Ph.D. to understand it. Ok, maybe it’s not quite that difficult, but the syntax can be annoying to say the least. It may appeal to some, but I imagine these as diehard coders who would prefer to write novels in assembler. I would, however, hazard to guess that the conciseness of a Regex is very appealing to almost anyone whose alternative is to write lines and lines of string parsing code.

Test Regex Outside of Debug Cycle

Since Regex can be interpreted by any regular expression processor,  regular expressions in your code can be tested outside of your code, and before you ever compile. It’s ideal, in my opinion, to test and validate specific regular expressions as part of the development process, as opposed to relying on the (unit) testing process. Don’t get me wrong, my regular expressions would still be tested indirectly as past of my unit tests, but I don’t want to endure multiple compile cycles as I debug the regular expressions themselves. Here are a couple of alternatives:

  1. Testing Online: JavaScript 1.2 and later has built-in support for regular expressions. There are a number of excellent expression processors that take advantage of this support. For example, this Regular Expression Tester.
  2. Testing within the IDE: If online is not your sort of thing, maybe something built into your IDE would work better. For Visual Studio, you can use the Regular Expression Explorer addin.

Ideas That Spread Win

Great talk by Seth Godin at a Business of Software conference:

He’s recycled some material from earlier talks, but of course it remains entertaining. His message: even in the software industry, we are in the idea business as much, or more than we are in the business of building function. To a great extent, software markets itself and therefore one should build marketing into software (he uses the analogy of BMW spending money on engineering where Ford spends it on advertising).

A Better Way To Call A .NET Assembly From COM

In my previous post Call a C# Assembly From VB6 I mentioned that there was a better way to pull off the interop required for using a .NET assembly in VB6. You can think of the technique used in that article as the “quick and dirty” approach. It works, but leans heavily on .NET’s ability to automatically specify the settings in the generated COM interface. That’s ok, but there is a cost: you have to recompile your COM clients every time you recompile your .NET component, and you cannot use late binding which, for example, is required for use by scripting clients. For just a little extra effort, you can exercise a greater level of control, and not have to pay these costs.

The technical background for what follows is covered very nicely in many places. I’m just going to provide a “how to” in what follows. For background on why it is done this way, you can check out COM Interop Exposed, or another similar resource on the web.

I’ll reengineer the Reverser class from the Call a C# Assembly From VB6 article to use this better approach.

Create an Interface

Create an interface for the methods you want to expose in COM. The interface for the Reverser class would be defined like so:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Text;
   4: using System.Runtime.InteropServices;
   5:
   6: namespace String.Utilities {
   7:     [Guid("F60865B6-D2D7-4435-8B0B-D2A09D88548C")]
   8:     [ComVisible(true)]
   9:     public interface IReverser {
  10:
  11:         string Reverse(string str);
  12:
  13:         string BetterReverse(string str);
  14:     }
  15: }

Notice that we have added a GUID. We have done this to control versioning. In the prior article we noted that  you should recompile your COM clients every time the .NET component is changed. By specifying a GUID for our interface and classes, we will be able to change the implementation of our .NET component without requiring a recompile of our COM clients. See COM Interop Exposed for more details.

Implement the Interface

Our new Reverser class will implement the new IReverser interface:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Text;
   4: using System.Runtime.InteropServices;
   5:
   6: namespace String.Utilities {
   7:
   8:     [Guid("80705AFF-708F-46f9-BA50-D69A96753A57")]
   9:     [ComVisible(true)]
  10:     [ClassInterface(ClassInterfaceType.None)]
  11:     public class Reverser : IReverser {
  12:
  13:     // Types must have a public default constructor   
  14:     // to be instantiated through COM. Managed public  
  15:     // types are visible to COM, but without a public  
  16:     // default constructor (a constructor without   
  17:     // arguments), COM clients cannot create an   
  18:     // instance of the type.  
  19:     public Reverser() {
  20:     }
  21:
  22:     #region IReverser Members
  23:
  24:     public string Reverse(string str) {
  25:         // This method is from Mladen Prajdić's   
  26:         // I want some Moore blog:  
  27:         // http://weblogs.sqlteam.com/mladenp/
  28:         // archive/2006/03/19/9350.aspx  
  29:
  30:         char[] charArray = str.ToCharArray();
  31:         int len = str.Length - 1;
  32:
  33:         for (int i = 0; i < len; i++, len--) {
  34:             charArray[i] ^= charArray[len];
  35:             charArray[len] ^= charArray[i];
  36:             charArray[i] ^= charArray[len];
  37:         }
  38:         return new string(charArray);
  39:     }
  40:
  41:     public string BetterReverse(string str) {
  42:         // This method is from Mladen Prajdić's   
  43:         // I want some Moore blog:  
  44:         // http://weblogs.sqlteam.com/mladenp/
  45:         // archive/2006/03/19/9350.aspx  
  46:
  47:         char[] charArray = new char[x.Length];
  48:         int len = x.Length - 1;
  49:         for (int i = 0; i <= len; i++)
  50:             charArray[i] = x[len - i];
  51:         return new string(charArray);
  52:     }
  53:
  54:     #endregion
  55:     }
  56: }

Notice that this class also defines a GUID. As noted for the IReverser interface, this is also done for the actual class to control versioning. Also, the ClassInterfaceAttribute specifies that no automatic interface is to be generated. In this case, the first interface implemented by the class will be the default interface in COM. This allows us to support late binding as well as early binding in COM clients (previously, only early binding was supported).

Notes

You will still have to set the project to register for COM interop. Note however that there is no need to change the ComVisiible setting in the AssemblyInfo.cs file:

   1: [assembly: ComVisible(false)]

In fact, by leaving it false, we can control exactly which interface methods are visible by overriding this setting with the [ComVisible(true)] attribute on an interface by interface, or method by method basis.

Using .NET To Access Google Data

Google Data includes the data used in Google services, data which is stored on the web. This includes Google Analytics data, Google Apps data (such as spreadsheets and documents), Blogger posts, Picasa Web Albums, Google Calendar data and much more. Google provides an API for accessing this data. Lately I’ve been working on how to access and modify Google Data using .NET. The obvious place to start is  the Google Data .NET client library. There is a nice guide for setting yourself up and getting started with this library, as well as developer guides for accessing Google data, such as spreadsheet data, using the .NET client library.

While the .NET client library provides an object oriented, programmatic interface to data stored in Google, the basis for the object model is based on Atom and the Atom Publishing Protocol. For example, the object model for accessing Google Spreadsheets is similar in many ways to the Excel object model, but in certain respects very different. While I don’t think one necessarily has to have intimate knowledge of the low level internals of Atom to use the .NET client library, I have found it helpful to understand them. What follows is the material I used to educate myself.

Lesson 1: The Atom Publishing Protocol

The Google Data API is based on the Atom Publishing Protocol (”AtomPub”), which in turn is based on the Atom syndication format. The following video provides a nice introduction:

Further Reading:

Since AtomPub is a RESTful protocol, you may also enjoy an introduction to REST, although I don’t think this is strictly necessary for understanding the Google Data API:

Lesson 2: How The Google Data API Uses AtomPub

The following explains how the Google Data API is implemented using AtomPub, providing some good examples at the AtomPub level, including the concepts of a service, a query and a feed:

Lesson 3: Getting Starting With The .NET Client Library

At this point, I find that it is now easier to understand the concepts behind the object model in the .NET client library. This final video gives an introduction to the .NET client library where you will see the concepts of authentication, services, queries and feeds being used:

Call A C# Assembly From VB6

I have had to figure this out twice now, so I will write it down this time: how to call and debug a c# assembly from VB6 in a development environment. The first thing you have to do is set up your c# assembly so that it is exposed as a COM object. This is more or less covered here, and I am sure elsewhere, but by way of an example, let’s create a .NET assembly that reverses strings (For this purpose, we will use some techniques outlined by Mladen Prajdić at his I want some Moore blog).

I will create a String.Utilities project with a single public Reverser class. This class is implemented as follows:

   1: using System;  
   2: using System.Collections.Generic;  
   3: using System.Text;  
   4: using System.Runtime.InteropServices;  
   5:   
   6: namespace String.Utilities {  
   7:       
   8:     // ClassInterfaceType.AutoDual allows early-bound  
   9:     // COM clients and compile-time checking. Note that  
  10:     // it completely ignores COM versioning, and that   
  11:     // you should recompile your COM clients every time  
  12:     // this .NET component is changed.  
  13:     [ClassInterface(ClassInterfaceType.AutoDual)]  
  14:     public class Reverser {  
  15:   
  16:         // Types must have a public default constructor   
  17:         // to be instantiated through COM. Managed public  
  18:         // types are visible to COM, but without a public  
  19:         // default constructor (a constructor without   
  20:         // arguments), COM clients cannot create an   
  21:         // instance of the type.  
  22:         public Reverser() {  
  23:         }  
  24:   
  25:         // We use this attribute to specify which public  
  26:         // methods will be visible to COM.  The default   
  27:         // value is true for public methods, so this is  
  28:         // not really necessary!  
  29:         [ComVisible(true)]  
  30:         public string Reverse(string str) {  
  31:             // This method is from Mladen Prajdić's   
  32:             // I want some Moore blog:  
  33:             // http://weblogs.sqlteam.com/mladenp/archive/2006/03/19/9350.aspx  
  34:               
  35:             char[] charArray = str.ToCharArray();  
  36:             int len = str.Length - 1;  
  37:   
  38:             for (int i = 0; i < len; i++, len--) {  
  39:                 charArray[i] ^= charArray[len];  
  40:                 charArray[len] ^= charArray[i];  
  41:                 charArray[i] ^= charArray[len];  
  42:             }  
  43:             return new string(charArray);  
  44:         }  
  45:   
  46:         [ComVisible(true)]  
  47:         public string BetterReverse(string x) {  
  48:             // This method is from Mladen Prajdić's   
  49:             // I want some Moore blog:  
  50:             // http://weblogs.sqlteam.com/mladenp/archive/2006/03/19/9350.aspx  
  51:   
  52:             char[] charArray = new char[x.Length];  
  53:             int len = x.Length - 1;  
  54:             for (int i = 0; i <= len; i++)  
  55:                 charArray[i] = x[len - i];  
  56:             return new string(charArray);  
  57:         }  
  58:     }  
  59: }  

Code is interop ready, now we just need to set up some project settings. First, we have to update (or add) the ComVisible setting in the c# project’s AssemblyInfo.cs file (this is the thing I always forget to do):

   1: // Setting ComVisible to false makes the types in this assembly not visible  
   2: // to COM components.  If you need to access a type in this assembly from  
   3: // COM, set the ComVisible attribute to true on that type.  
   4: [assembly: ComVisible(true)] 

Next, open the project’s properties and click on the Build tab. Ensure the Register for COM interop option is selected:

buildoption

In order to be able to debug this while running the VB6 client from the development environment, you want to go to the Debug tab and select the Start external program option specifying the path to the VB6.exe.

Now we can build the assembly. When we debug, as specified in the debug options, VB6 will start. You can then open an existing project (or create a new one) that you want to use as a client for the .NET service. Click on the (VB6’s) project references and select the .NET assembly (which is now exposed as a COM object):

vb6ref

Here is my VB6 client code for calling the .NET assembly:

   1: Private Sub cmdReverse_Click()  
   2:   
   3: ' Notice how the dot (".") came across as  
   4: ' an underscore!  
   5: Dim aReverser As String_Utilities.Reverser  
   6: Dim reversed As String  
   7:   
   8: ' Instantiate the .NET Reverser object  
   9: Set aReverser = New String_Utilities.Reverser  
  10:   
  11: ' Call a method in the assembly  
  12: reversed = aReverser.Reverse(txtString.Text)  
  13:   
  14: ' Show the user the text in reverse  
  15: lblReverse.Caption = reversed  
  16:   
  17: End Sub

Running the VB6 client and clicking the button gives the following:

revsample

Of course, within the VB6 environment you can fully debug the client (set breakpoints, add watches, etc.). Now, run the VB6 project again, but this time set a breakpoint at public string Reverse(string str) in the Reverser class in VS2005. When you click the button, you will break at the Reverse method in the .NET debugging environment:

debugsample

Therefore we can call an assembly from a VB6 application and debug both sets of code at the same time. A couple things: (1) the assembly is only registered as a COM object for the lifetime of the debugging session initiated from VS2005. So you cannot open VB6 and debug on its own without building and registering the assembly as a COM object (you use the regasm utility). (2) there is a better way than using ClassInterfaceType.AutoDual to expose the class in COM which I will cover another day.

Testability Guide

testing Miško Hevery works at Google and is responsible for maintaining a culture of automated testing. He has recently published a Guide to Writing Testable Code. It is available on his site and as a pdf download. Besides making code more testable, I believe that the guidelines also represent coding best practices in general and I urge you to get a copy of the guide.

I first discovered Miško through Google’s Clean Code talks. My favourite talk is the one on Inheritance, Polymorphism & Testing:

 

Here are the others…

Unit Testing:

 

Don’t Look For Things:

 

Global State and Singletons:

 

 

Photo Credit: Matthew Venn

Abstract Factory Or Factory Method

hatFactory The Gang of Four, in their seminal work Design Patterns: Elements of Reusable Object-Oriented Software, describe several creational design patterns. First off, you should be convinced that it is a best practice to separate the classes that actually do stuff from the classes that create the objects that do stuff. If you are, then these patterns are important. These patterns include the factory method and abstract factory patterns. It has often confused me as to when you should use either. I found a rather good overview in some computer science course notes. Let me quote the relevant section:

Sometimes it is difficult to differentiate between abstract factory and factory method. Solution?

  • In the factory method, your class looks down (inheritance) for help in creating the object of specific type.
  • In abstract factory, it looks to the left or right (association) for that help.

So use factory method if:

  1. your class depends on a subclass to decide what object to create.
  2. inheritance plays a vital role.

However, if your class depends on another class, which may be abstract and you are associated with it, then use abstract factory.

Alright, that’s kind of helpful. Here is how I think about it. You use the abstract factory when you have different families of similar things you need to create. You use the factory method when you have one family of things you need to create.

For example, you have one store that creates several different kinds of pizza (cheese, pepperoni, vegetable): use the factory method. You have two pizza store chains that each produce different kinds of pizza (cheese, pepperoni, vegetable): use the abstract factory.

 

Photo Credit: Sara Richards

BugzReport v0.2.5

bug Hot on the heels of v0.2.0, we’ve released version 0.2.5, an update which is now available for download. You can read more about what BugzReport is here, here and even here!

This update includes a few new features:

  • Added support for exporting cases to tab delimited files.
  • HTML code in the case fields will be decoded nicely in the client and the export.
  • Made it easier to select (click on) fields to include in the queries.

There were also a bunch of bug fixes. I’d also like to thank Nick and Christian for their valuable feedback. Enjoy!

Photo Credit: _big_mouth_

BugzReport v0.2.0

BugzReport v0.2.0 is now available for downloadbugzReportQuery

BugzReport is a Windows desktop client application that can be used to generate reports on cases logged in a FogBugz installation or a FogBugz On Demand hosted installation. BugReport allows you to export these reports to files that can be used by other applications such as Microsoft Excel.

FogBugz, a product of Fog Creek Software, is a web based solution that helps organizations make better software. It allows organizations to track feature requests, customer email, bugs, and other artifacts. It’s a pretty great application that I use in my work.

v0.2.0 includes the following updates:

  • added the area field, as well as the "opened by", "resolved by" and "closed by" fields to the query options.
  • changed the query options dialog so that all the fields are checked by default (I found
    I was checking most of them every time I ran a query).