Redhead - Jacob Slusser’s Blog

Asynchronous Pluggable Protocols–that’s a mouthful. I came across this last night as I was doing some research on the Windows Forms WebBrowser control. First let me explain my motivation.

I have a situation at work where we’re using the WebBrowser control to window in our own company website because we never had the time to build a native Windows Forms application. The application we wrote allows our internal users a chance to review the data submitted by users on the website. Our internal analysts are presented with a window showing the web page with the user’s entered data and some additional data in the native application to help them in their analyses. This mixing of native UI and web UI has worked fine for a while, but doing that has had some drawbacks. For one, there is resource contention between the native UI which gathers additional data for the analysts to use and the website we’re windowing in. Both share the same database resources. That also introduces some concurrency issues–again because it’s like two entirely separate processes are reading and writing to the same place (one is the native application itself and the other is the website windowed in).

Some other less concerning, but still annoying drawbacks, are that we’re taking a performance hit. Having to window in a website that makes database calls through a DMZ and remoting/webservices to a database that we have direct internal access to in the native application is silly to say the least.

So why haven’t we written a native UI? Aside from the above mentioned lack of time, the web pages that we’re windowing-in are very complex data entry forms with as many as 700 input elements. Replicating and maintaining these as both web forms and Windows forms would be a maintenance headache.

I’ve floated the idea of building a UI framework that could render our data entry forms as both HTML and as Windows controls. That’s easier said than done though. They are very different beasts and usually when you build a UI framework that targets multiple platforms, one of those platforms suffers. In this case, our forms don’t translate very well to a Windows UI. Have you every tried to put 700 text boxes on a form before? It’s not pretty.

Another option I’ve considered is to continue to use the WebBrowser control, but instead of windowing in our website, we could window in some HTML pages created in memory. This would look/behave similar to a website, but instead of actually making HTTP calls to some server, the pages would be directly served up from within the application hosting the WebBrowser control. This has the added benefit that I might be able to reuse some of the HTML code we’ve labor over in the web application.

There are plenty of places on the Internet that will show you how to set the DocumentText property of the WebBrowser control, but that’s woefully inadequate for what I need. For starters, setting just the HTML of the control doesn’t allow you to load images or linked CSS files from memory.

I then read about using the “res” protocol which allows URLs that are redirected to a resource file on the file system instead. This was encouraging because it meant that if I substituted res as the URL scheme instead of say http I could then pull additional resources from memory instead of a remote server. This is a little more difficult to do in .NET because it uses the older style Win32 resource format, but it is doable.

Unfortunately, that still falls short of what I need. I would like to get the whole browsing experience. Page-to-page navigation, images, linked CSS and script resources, postbacks, etc…. I was hoping to find a way to hook into the WebBrowser control so that it would think it’s accessing a remote server, but in actuality, everything was coming from the local process memory.

Then I read about Asynchronous Pluggable Protocols and I think I might have my answer. Based on what I’ve read on MSDN, it would seem that I could register a protocol that when processed will call my code instead of the remote server. For example, I could register the protocol “in-proc” and use it in a URL like this: in-proc://some/identifier. Then when the browser encounters the in-proc protocol and has no built in handler for it, it will ask my code to handle it. I can then do whatever processing I want for that URL, whether it’s get an image out of a resource file, generate HTML, etc…. and return the result to the WebBrowser control. At least that’s my understanding of it.

I think if I could register a custom protocol and then make sure my generated pages use that protocol instead of HTTP, I could use the WebBrowser control as a reliable and robust UI but without the overhead of doing actual network IO.

I’ll let you know how it goes.

UPDATE: I found an article on CodeProject that accomplishes most, if not all, of what I’m hoping to do.

Programming .NET, APP, IE, WebBrowser

At work I was given the unusual task of automating a process to log-in to a partner’s website and submit data through several forms. I say it was an unusual task because our partners usually have integration points like web services that we communicate through, however, this partner provided no such mechanism. Up until now we’ve been keying in data to their site manually, but after the code I wrote gets deployed it should be a fully automated process.

That brings me to why I love HttpFox so much. It’s right up there with Firebug as one of my essential Firefox add-ons. With HttpFox I was able to easily capture all the HTTP traffic from my browser to the site and back. I could see each post variable and name as raw data or formatted. Sure there are other tools that could do that, but none that make it so easy.

I was then able to essentially copy and paste the form data from HttpFox into the application I wrote which use a HttpWebRequest to perform the same action that the browser does. In just three hours I was able to reverse all the relevant portions of our partner’s site, create a XML file describing the form data to use as input, and them automatically submit it.

Tools .NET, Firefox, HttpFox

I find that I constantly have to write code to first check for an item in the ASP.NET cache and if it is not found then create the item for the first time and insert it into the cache for subsequent look-ups. I began to wonder if I could simplify that process and came up with the following code:

public delegate object Create();
 
public static T GetOrCreate(string key, Create create)
{
        Cache cache = HttpRuntime.Cache;
        object value = cache[key];
 
        // If there is no object in the cache run the create delegate
        if (value == null && create != null)
        {
                value = create();
                if (value != null)
                    cache.Insert(key, value);
        }
 
        // Cast the return object
        return value == null ? default(T) : (T)value;
}

You could then make a single call to either get the item in cache or create it for the first time like this:

DataSet ds = GetOrCreate<DataSet>("users", delegate()
{
    DataSet ds = new DataSet();
    // Get data from database...
    return ds;
});

Using an anonymous delegate the syntax is pretty easy to either get the item if it’s already cached or create it for the first time. It has the added benefit of placing the code that creates the cache item right next to the code that gets it from the cache to make comprehending the code easier for other developers.

So my question is, is this a clever approach to an old problem, or am I going overboard?

Patterns .NET, ASP.NET, Caching

After a couple tries I was able to use the .NET Mass Downloader to get all the .NET reference source code at one time. Before that, if I wanted to look at some source I would have to setup a test project that calls the code I’m interested in so that I could debug into it. Now I can just search all the files at once for what I’m looking for.

As an added bonus I was able to follow the instructions to get symbols setup on Visual Studio 2005 (which I still use at work). Besides the downloader, I don’t know of any other way of doing that.

Tools .NET, Visual Studio