Writing a simple HTTP proxy using WCF

I ran into a situation with the following network topology: The intranet server served PDF documents via IIS, but was only accessible from the WCF server - which, for technical and political reasons, could not run in IIS but had to be a Windows Managed service that hosted a WCF service. Yet I needed to be able to download files from the intranet server via an ordinary URL. It turns out that you can write a WCF service mimicking a HTTP server pretty easily. If you can utilize .NET 3.5SP1, that is. 1. Data contract There are few key points to the contract:

• Make a reference to System.ServiceModel.Web.dll
• Add a "using System.ServiceModel.Web"
• Define a method returning a Stream
• Decorate that method with a WebGet attribute

Your datacontract could look like this:

using System.IO;
using System.ServiceModel;
using System.ServiceModel.Web;

namespace ProxyService
{
    /// 

    /// Service contract for a proxy that forwards a http request
    [ServiceContract]
    public interface IHttpProxy
    {
        [OperationContract, WebGet]
        Stream GetProxyRequest(string target);
    }
}

2. Implementation class This is basically a modified version of a solution based upon an ASP.NET page I described before.

using System.IO;
using System.Net;
using System.ServiceModel.Web;
using System.Web;

namespace ProxyService
{
    /// 

    /// A proxy that forwards a http request
    /// 
    public class HttpProxy : IHttpProxy
    {
        public Stream GetProxyRequest(string target)
        {
            var urlToLoadFrom = HttpUtility.UrlDecode(target);
            HttpWebRequest webRequest = 
               HttpWebRequest.Create(urlToLoadFrom) as HttpWebRequest;

            // Important! Keeps the request from blocking after the first
            // time!
            webRequest.KeepAlive = false;
            webRequest.Credentials = CredentialCache.DefaultCredentials;
            using (var backendResponse = 
              (HttpWebResponse)webRequest.GetResponse())
            {
                using (var receiveStream = 
                  backendResponse.GetResponseStream())
                {
                    var ms = new MemoryStream();
                    var response = 
                      WebOperationContext.Current.OutgoingResponse;
                    // Copy headers
                    // Check if header contains a contenth-lenght since IE
                    // goes bananas if this is missing
                    bool contentLenghtFound = false;
                    foreach (string header in backendResponse.Headers)
                    {
                        if (string.Compare(header, 
                          "CONTENT-LENGTH", true) == 0)
                        { 
                          contentLenghtFound = true;
                        }
                        response.Headers.Add(header, 
                          backendResponse.Headers[header]);
                    }

                    // Copy contents
                    var buff = new byte[1024];
                    var length = 0;
                    int bytes;
                    while ((bytes = receiveStream.Read(buff, 0, 1024)) > 0)
                    {
                        length += bytes;
                        ms.Write(buff, 0, bytes);
                    }

                    // Add contentlength if it is missing
                    if (!contentLenghtFound) response.ContentLength = length;

                    // Set the stream to the start
                    ms.Position = 0;
                    return ms;
                }
            }
        }
    }
}

3. Configuration settings To get it all to work, you will need some configuration settings in the App.config of the hosting application:

<system.serviceModel>
  <services>
    <service name="ProxyService.HttpProxy" >
      <endpoint address="" binding="webHttpBinding"
                behaviorConfiguration="WebHttpBehavior"
                contract="ProxyService.IHttpProxy" >
      </endpoint>

      <host>
        <baseAddresses>
          <add baseAddress="http://localhost:8002/ProxyService.HttpProxy" />
        </baseAddresses>
      </host>
    </service>

  </services>
  <behaviors>
    <endpointBehaviors>
      <behavior name="WebHttpBehavior">
        <webHttp />
      </behavior>
    </endpointBehaviors>
  </behaviors>
</system.serviceModel>

Notice the endpointBehaviors section: this is really important to get the stuff to work. 4. Using the proxy You can now simply enter "http://yourhost:8002/ProxyService.HttpProxy/GetProxyRequest?target=urlencodedurl" in your browser, and the WebGet attributes will automatically make the GetProxyRequest method get called with the value of target as value for the target parameter. The code of the proxy expects target to contain an URLEncoded URL (use HttpUtility.UrlEncode to encode the actual url to something that can be passed as a parameter on an URL). Concluding remarks The magic of the WebGet attribute is barely scratched by this example, but it makes creating REST services with WCF a real piece of cake. I am not sure if it was intended to be used this way, but it sure works like hell ;-)

Turning off WCF security

Unlike ye goode ole ASMX web services, WCF comes by default with security enabled. That's a good thing: Microsoft now believes in security being integral part of the solution, so in stead of slapping it on later, it is turned on by default. This is fine of course in distributed production environments but may be a real PITA while testing or deploying in a simple point-to-point enviroment, especially when machines are not in the same domain. Fortunately, turning all these gizmos off is quite easy. The catch is that settings on server and client must exactly match You host the service like this (provided it is hosted in IIS)

<system.serviceModel>
  <services>
    <service name="MyService">
      <endpoint contract="IMyService" binding="wsHttpBinding" bindingConfiguration="wsHttpBindingConfiguration"/>
    </service>
  </services>
  <bindings>
    <wsHttpBinding>
      <binding name="wsHttpBindingConfiguration">
       <security mode="None">
          <message clientCredentialType="None"/>
          <transport clientCredentialType="None"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
</system.serviceModel>

and you configure the client like this

<system.serviceModel>
  <client>
    <endpoint name="MyDataPortal"
              address="http://someserver:2000/MyRoot/MyService.svc"
              binding="wsHttpBinding"
              contract="IMyService"
              bindingConfiguration="MyBinding"/>
  </client>

  <bindings>
    <wsHttpBinding>
      <binding name="MyBinding">
        <security mode="None">
          <message clientCredentialType="None"/>
          <transport clientCredentialType="None"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
</system.serviceModel>

I emphasized the important parts. Be advised: these settings should only be used in either development environments or enviroments that are inherently safe by themselves, i.e. closed networks.

Shared code development and easy unit testing with Compact Framework

Microsoft made developing for the Compact Framework relatively easy. Everyone with experience in .NET development can easily take the plunge into mobile development by downloading the Windows Mobile SDK 6.x and go on as if you are just working in the full framework. You will notice some restrictions, not everything you might want to use is available, programs running on mobile device face some very specific challenges, but then again, the development experience is quite seamless.

Some things remain a bit cumbersome. Unit testing can be a real PITA, and you cannot binary reuse code, so if your shop (like mine) uses some utilities that are distributed as binary components, they will have to be recompiled specifically for the Compact Framework and someone has to keep the CF and Full version in sync.

Fortunately Visual Studio sports an almost hidden feature that can make life a lot easier for Mobile developers. The following procedure assumes that you have Visual Studio 2008 professional edition and the Windows mobile 6 SDK installed. For unit testing I use NUnit and Testdriven.NET to launch it from Visual Studio, but you can of course use anything you like

1. Make a new empty solution
Let's call it "SharedCode"

2. Add a new Smart Device application
Select Add/new project/Smart Device
Use "MyMobileApp" as name
Select Smart Device, Windows Mobile 6.0 professional SDK, and Compact Framework 3.5 although for this sample only the first option is really important.

3. Add another Smart Device application
Select Add/new project/Smart Device
Use "MyMobileLib" as name
Select Class Library, Windows Mobile 6.0 professional SDK, and Compact Framework 3.5

4. Add two Windows Class library projects
These must be full framework projects, not mobile projects.
Call the first one "MyLib" and the second one "MyLib.Test". Select .NET framework 3.5 as target framework

5. Add a new class to the MyMobileLib assembly
For this example, we will use a trivial calculator class:

namespace MyMobileLib
{
    public class Calculator
    {
        private int Num1;
        private int Num2;

        public Calculator(int num1, int num2)
        {
            Num1 = num1;
            Num2 = num2;
        }

        public int Add()
        {
            return Num1 + Num2;
        }

        public int Subtract()
        {
            return Num1 - Num2;
        }
    }
}

6. Add as link to the MyLib library
Go to the MyLib library and remove the default generated "Class1.cs" file.
Then right-click the project and select "Add/Existing Item".
And now for the piece the resistance:
Browse one directory up, then down into the MyMobileLib directory, and select the Calculator.cs file.
Now look carefully to the "Add" button down right. It will sport a hard-to-spot small arrow pointing downwards:
If you click that, you will get two options: Add and Add as link. That is what I mean by "an almost hidden feature". Select "Add as link" and you will see that "Calculator.cs" is added to the MyLib project, but that the document icon has a shortcut arrow overlay:







7. Add references
Right-click the MyMobileApp project
Select "Add Reference", click Tab "projects" and select the "MyMobileLib" project

Right-click the MyLib.Test project
Select "Add Reference", click Tab "projects" and select the "MyLib" project

8. Define unit test in de MyLib.Test project
Rename the default Class.cs file in MyLib.Test to "TestCalculator.cs".
Since I use NUnit, I have to make a reference to the nunit.framework.dll which sits somewhere on my system. Then I can create the world shocking ;-) test

using MyMobileLib;
using NUnit.Framework;

namespace MyLib.Test
{
    [TestFixture]
    public class TestCalculator
    {
        [Test]
        public void TestCalc1()
        {
            Calculator c = new Calculator(3,2);
            Assert.AreEqual(5, c.Add());
            Assert.AreEqual(1, c.Subtract());
        }
    }
}

which will undoubtly work. But my point is: you can simply run units tests out of the Windows Mobile scope, inside Visual Studio

9. Test the library on the mobile device
For the sake of brevity: drag a label onto the form.
Open the Form1.cs, and add to the code on the form:

using System.Windows.Forms;
using MyMobileLib;

namespace MyMobileApp
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            Calculator c = new Calculator(3, 2);
            label1.Text = "3 + 2 = " + c.Add();
        }
    }
}

If you run this, open pops the Windows Mobile emulator and the form will show the 'surprising' message "3 + 2 = 5".

Conclusion
While the sample was trivial, it showed two things:

• For general purpose classes, you can develop code and generate binaries for both Compact and full framework using a single code file


• Unit testing of general purposes classes can be done outside a Windows Mobile emulator and becomes a lot easier this way

Complete code downloadable here.

Don't ever use backslashes in Silverlight 2 image URLS!

I had a great time today and yesterday at the Microsoft Developer Days 2008 in Amsterdam, where they shared quite a bit of data on Silverlight 2.0. I have been hacking along with it for some time now and I would like to share a bit of hard-won information I stumbled across. That piece of information is quite simple: If you programmatically set an URL to an Image, do not ever let the URL contain a backslash, not even when it is URLEncoded So, suppose your XAML looks like this:

<usercontrol class="SilverMapLoader.Page" 
  xmlns="http://schemas.microsoft.com/client/2007" 
  x="http://schemas.microsoft.com/winfx/2006/xaml" 
  width="700" height="500">
  <canvas name="LayoutRoot" background="Gray">
    <img height="460" src="" width="700" name="map" top="0" left="0" />
  </img>
  </canvas>
</usercontrol>

You can set the URL to the image in your Page.xaml.cs like this:

string URL = "http://www.someadress.org/image.jpg";
map.Source = new System.Windows.Media.Imaging.BitmapImage(new Uri(URL));

Now I was trying to show images that came from some cache mechanisme that effectively needed URLs like this:

http://localhost:2872/SilverMapLoaderClient/MapLoaderCache.aspx?CacheFileData=C%3a%5cMapLoaderCache5cMapLoaderCache.png"

Silverlight simply does not show the image. It does not even give an error message. I suppose this is a bug, but this is more or less how I programmed around it:

string newURL = URL.Replace("\\", "/").Replace("%5c", "%2f").Replace("%5C", "%2F");

Effectively I am replacing all backslashes by forward slashes. And modified the page that actually loads the images so that it understands that forward slashes need to be translated into back slashes before the actual path is picked. It does not win a beauty contest, but it works, and in the end, that's all that counts It took me the better part of a rainy Saturday to find this out, while I was actually on planning on finding out a lot of Silverlight, and I reported it as a bug on Silverlight.net. Maybe this post will save some poor sod from repeating my experience ;-) Update: obviously my report helped, since I just installed SilverLight 2.0 release, upgraded and recompiled the project, deleted the workaround code, and it still works as a charm.

JSON services revisited: using a Dictionary as a generic parameter

Somebody at Microsoft deserves a Nobel Prize. Well, that is maybe a bit strong, but I ran into the problem that I wanted to create JSON scriptserver that would accept a 'parameter bag' of unknown size and type. I expected problems in the serialization, since Javascript typing is at best a bit lax, but it turns out that when you define a web service with a parameter of type Dictionary<string, object> dict, the JSON serializer automatically derives the object types from the javascript data! It works like this: suppose we define the following method:

[WebMethod]
public string DictMethod(Dictionary<string, object> dict)
{
  StringBuilder b = new StringBuilder("C# reports<BR/>");
  foreach( string s in dict.Keys )
  {
    b.AppendFormat(string.Format("{0}:{1}={2}<BR/>", s, dict[s].GetType(), 
                   dict[s]));
  }
  return b.ToString();
}

We can call this method from javascript like this

<script type="text/javascript">
  function LoadDict()
  {
    dict = new Object();
    dict["test1"] = "Joost";
    dict["test2"] = 21;
    dict["test3"] = true;
    dict["test4"] = 9999999999;
    dict["test5"] = new Date(2008,09,12,13,14,00);
    DictService.DictMethod( dict, ProcessResult );
  }

  function ProcessResult( WebServiceResult )
  {
    document.write( WebServiceResult );
  }
</script>

If you attach the LoadDict javascript function to some client side event (The OnClientClick of a button for example) and launch it, you will see the following output: C# reports test1:System.String=Joost test2:System.Int32=21 test3:System.Boolean=True test4:System.Int64=9999999999 test5:System.DateTime=12-10-2008 11:14:00 So you can see, the javascript string converted into a true .NET string, the value 21 into an Int32 - but the value 9999999999 is too long for an int and is converted into a Int64, a.k.a. long - I really like that one, for it shows true craftmanship of the programmer ;-). The "true" javascript value is converted into a Boolean finally, the javascript Date is converted into a neat DateTime. And presto, all your stuff is converted into real .NET objects. Of course, you should always used typed parameters when possible, but for some generic solutions this may come in very handy. Complete code downloadable here.

Running and debugging a Windows Managed Service directly from Visual Studio.NET

Developing a Windows Managed Service (i.e. a service written in .NET ;-) ) is a lot easier than it used to be, still it can be a real PITA to debug, especially in the early stages, and even more so when the service is a kind of server and something goes wrong with the communication. You are continually running in circles:

1. Stop running service
2. Replace binaries
3. Start services
4. Attach Visual Studio debugger to process
5. Launch your client process
6. Find bug
7. Fix bug
8. Repeat until no more bug.

Life could be so much easier if you could launch the service from Visual Studio and see how it behaves. And the fun thing is, you can.

1. Create a new service project in your solution
If you already have a service project you can skip this step. I'll add a service project DemoService with a Service MyService in it with not too complicated functionality:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.ServiceProcess;
using System.Text;

namespace DemoService
{
  public partial class MyService : ServiceBase
  {
    public MyService()
    {
      InitializeComponent();
    }

    protected override void OnStart(string[] args)
    {
      Console.WriteLine("OnStart");
    }

    protected override void OnStop()
    {
      Console.WriteLine("OnEnd");
    }
  }
}

2. Change the application output type
Right-click the DemoService project, choose "Properties", click tab "Application". Default this says "Windows application" - change this to Console application

3. Add debug mode methods to your service class

#if DEBUG

  public void StartService()
  {
   OnStart(null);
   Console.WriteLine("MyService started, press >ENTER< to terminate");
   Console.ReadLine();
  }

  public void StopService()
  {
   OnStop();
  }
#endif

4. Add debug mode code to the Main method
Open the "Program.cs" file in the service project, and change it so it looks like this

using System;
using System.Collections.Generic;
using System.ServiceProcess;
using System.Text;

namespace DemoService
{
  static class Program
  {
    /// 

    /// The main entry point for the application.
    /// 
    static void Main()
    {
#if DEBUG
      MyService s = new MyService();
      s.StartService();
      s.StopService();

#else
      ServiceBase[] ServicesToRun;

      ServicesToRun = new ServiceBase[] { new MyService() };

      ServiceBase.Run(ServicesToRun);
#endif
    }
  }
}

And that's it. You can now run the 'service' as a program in debug mode - it will pop-up a console window in which the 'service' runs and says OnStart MyService started, press >ENTER< to terminate

If you hit enter, you will just be able to see "OnEnd" passing by before the window closes. Of course, normally you will launch a thread of some kind in the OnStart method, or you will start a WCF service, and then you can see the dynamic behaviour of the 'service' while it runs by adding more "Console.WriteLine" calls - or, since it is already a process inside VS.NET, see it hit breakpoints or the exception you have been hunting all week now. And by setting the solution to "Multiple Startup" you can start both 'service' and client in one go.

And if you make a release build, all this stuff will be left out and the service will be compiled as a proper service which can be installed and will run in the usual way.

CAVEAT: be aware that the 'service' is running with your login credentials when it runs in a console window, and not as 'System'. This method is therefore not applicable when debugging access releated problems.

Simplyfying refactoring by making things obsolete

A very simple one I ran into today - when you are refactoring things, sometimes old methods are no longer required, but for the sake of backward compatiblity your want to retain them. To make sure your own code no longer calls the deprecated method, simply use the ObsoleteAttribute:

[ObsoleteAttribute("Warning you want the compiler to give")]
public void ObsoleteMethod()
{
  // ....
}

If you now recompile your program, every call to ObsoleteMethod displays the message "Warning you want the compiler to give" in the output window - you might want to change that message to something more useful ;-).