Custom HyperLinks Using a Generic Protocol Handler

• Download demo project - 213 KB
• Download source code - 237 KB

Introduction

The idea of posting this article on Protocol Handler is to introduce a new architectural solution which allows the (protocol handler) implementation architect to implement a far more robust and scalable solution than the ones currently available. The goal is to provide a generic solution for the Asynchronous pluggable protocols implementation.

Recommendations

Before moving ahead with this article, if the reader is not well versed with the concept of Protocol Handlers or unknown to the existing available solutions/implementations of asynchronous pluggable protocols, than I humbly request the reader to first go through the following links on the currently available asynchronous pluggable protocols implementation logic articles at Custom-URL-Protocol-for-Invoking-Application and Custom-Hyperlinks-Using-Asynchronous-Pluggable-Pro and also a detailed explanation of the concept is available at Microsoft-Knowledge-Base for a detailed understanding and official documentation of Asynchronous pluggable protocols.

Motivation

The motivation to create this architectural solution came from the implementation overheads in the existing Protocol Handler's implementation approach. Below mentioned are the few points that explains the same:

• Firstly the currently available approach requires new entries to be registered (injected) into the systems registry for every newly introduced protocol. This registering of entries in the systems registry is suited for implementation and demonstration on a single PC or organization with small no of PC's, but definitely lacks the flexibility and operational maintainability of implementing the solution on large organizational networks (1000 + terminal). For instance sectors like Finance, Banking, Insurance...so on, require the architecture to be scalable and be implemented on terminals in access of 10's of 1000's (+ 10k terminals) across the organizational network with ease and minimal maintenance overheads. And to register the entries would surely require creation or separate registering and unregistering applications and be run on PC across the organization, where the new Protocol needs to be implemented.
• Secondly I have also noticed (on some forums) that implementation architects of asynchronous pluggable protocol have (rarely but) complained about version compatibility issues of newly registered protocols, not being recognized as a clickable link on old versions of Web-Browsers, Outlook, MS-Office. So there stands a clear need of implementing asynchronous pluggable protocol with a reusable and more scalable architectural solution.

Assumptions

The article assumes that the reader has in-depth understanding of the following below mentioned technologies:

• Object oriented programming concepts
• C# programming language
• Microsoft ClickOnce technology
• Win and Web based application development
• Query String parameter of ASP.NET
• Basic knowledge of Hyper Text Transfer Protocol (HTTP)
• Hosting in Microsoft IIS (Internet Information Server)

Development Environment Configuration

• Visual Studio 2008
• Windows 7
• IIS 7.5.7600 (Internet Information Server 7.5)

Goals

Following are the main goals to be achieved by the new design of Protocol handler:

1. Link should be recognized (clickable) by all common software's (like Web-Browsers, Outlook, MS-Office....so on) that support embedding of links, irrespective of the versions of the host software that has the link embedded.
2. System Registry edits should be eliminated, There should be no registering and unregistering logic required for the (protocol) link to be recognizable.
3. Successful passing of parameter to the Handler application for which the embedded link is clicked.

Synopsis

This new approach relays on creating a Handler application, which is nothing but a Windows console based ClickOnce application. The ClickOnce Handler application will acts as an interceptor between the Host (a web page or outlook or anything that can embed the link) and the Target app. The Handler application will be invoked on the click of the embedded link in the host application. The Link is nothing but a http url that will hold the information in the querystring parameter. Since the handler application is ClickOnce deployed so it allows itself to be publish to a Web server. The embedded link (HTTP URL) will invoke the handler application and then handler application will parse the received query string parameters and finally invoke the relevant target application. Handler application can be thought of as a Click Once Deployed parser application. The first step requires deployment of the Handler application to the Deployment Server, then the client machine requests the deployment manifest and Handler application is downloaded as shown in the below diagram.

Once the Handler application is installed on the client machines, then the link can be embedded into any Host (like iExplorer, Outlook, Google Chrome.....so on etc.) and on the click of the link, the handler application will be passed the query string parameter and finally the target application will be invoked. Following is the diagram showing the flow.

1. Host application: The Host application contains the embedded link. This application could be any Web Browser, MS-Word, MS Outlook or any valid application that can contain the embed link.
2. Clickable link: The biggest challenge is to make a array of characters into a link and so the concept of wrapping the information in the hyper text markup protocol (HTTP) was coined. The clickable link is a http link which is a URL of the ClickOnce Handler application deployed on the Web Server. The http link holds query string parameters, which contains the actual information required by the Target application and the handler application is responsible of passing the information (query string parameters) to the target application after parsing it from the http link.
3. Deployment server: The Web server on which the ClickOnce handler application is deployed.
4. Handler application: The parser application that will be hosted in a Web Server (IIS) and downloadable to local terminal. The handler application will be responsible for processing the Query string parameters and decides which Target app needs to be invoked on the users' terminal. This Window's handler application will be installed on the each terminal using ClickOnce deployment technology. The Click once deployment relay mainly on two manifests, a deployment manifest and an application manifest.
5. Target application: The target app is the final software app, that will be launched with the specified parameters.

Using the Generic Protocol Handler Demo

1. Download the Demo project from the link at the top of the article.
2. Open the TargetApplication folder.
3. Place the TargetApplication1.exe in C:\ drive location (like C\:TargetApplication1.exe).
4. Place the ProtocolHandler folder under C:\inetpub\wwwroot\ location (like C:\inetpub\wwwroot\ProtocolHandler).
5. Create a Virtual Directory with alias name ProtocolHandler and map it to the location C:\inetpub\wwwroot\ProtocolHandler.
6. Copy and paste the following link in Web Browser http://localhost/ProtocolHandler/ProtocolHandler.application (here localhost has been used to deploy the application, but any deployment server can also be used for the same).
7. On Hitting Enter, a pop up will appear to install the ProtocolHandler application. Click on Install.
8. Double click on the HostWebPage.htm webpage and click on the Link in the Web Page.
9. The TargetApplication1.exe will be launched with the parameters embedded in the link of the HostWebPage.htm webpage, as shown in the diagram below

Understanding the Generic Protocol Handler Code

The code base has three major components the ProtocolHandler project, the TargetApplication project, and the HostWebPage. The ProtocolHandler application contains the main parsing logic and is responsible for receiving the parameters from the Host. The below mentioned function GetQueryStringArgument() is responsible for receiving the query string parameter

public string GetQueryStringArgument()
{
    string queryStringParameter = null;
    try
    {
        if (ApplicationDeployment.CurrentDeployment.ActivationUri != null && 
                    ApplicationDeployment.IsNetworkDeployed)
        {
            string queryString = ApplicationDeployment.CurrentDeployment.ActivationUri.Query;
            if (!string.IsNullOrEmpty(queryString) && queryString.StartsWith("?"))
            {
                queryStringParameter = queryString.Substring(1);
            }
        }
    }
    catch (Exception ex)
    {
        //exception handling logic
    }
    return queryStringParameter;
}

The Target Application is a WinForms based application which receives parameters from the ProtocolHandler in the form of arguments in its main() function and then parses the argument and passes it to the relevant TextBox for display. Any Target Application that needs to be invoked from the ProtocolHandler needs to incorporate the basic argument handling functionality, like the one mentioned below

static void Main(string[] args)
{
    string applicationArguments = null;
    if(args.Length > 0)
    applicationArguments = args[0].ToString();
    //Use these string array values
    string[] parameters = Regex.Split(applicationArguments, "-");
}

The Host needs to embed the clickable link. This clickable link is nothing but a HTTP URL with query string parameters that needs to be passed to the ProtocolHandler application and finally to the Target Application. Following is the sample link:

http://localhost/ProtocolHandler/ProtocolHandler.application    //This is the URL of the Handler Application
+
Trg1                            //This is the Target Application Code
+
Trg1&TestName-17-280MarinBlvd                //This is the parameters that needs to be passed to the TargetApplication

http://localhost/ProtocolHandler/ProtocolHandler.application?Trg1&TestName-17-280MarinBlvd

Points of Interest

The whole idea of writing this article was to demonstrate the new architectural solution for implementing asynchronous pluggable protocols using Generic Protocol Handler. Few important factor to keep in mind while publishing the ProtocolHandler package on the deployment server using the code is to make sure that the ProtocolHandler package is always network deployed by going to the "Properties->Publish->Publish Now" of the project and make sure that the Publishing Folder Location is a web site. Secondly the "Allow URL parameter to be passed to the application" is always checked to true under the "Properties->Publish->Option" section. There are a lot of additional features that can be added to various sections of the project like making the HandlerApplication UI less, having if else conditions in the InvokeTargetApplication() function of the HandlerApplication to invoke more Target Applications, having a check in HandlerApplication to invoke target app only when it’s not open, if target app is already open then just change the parameters...etc

History

• Initial release 1.0.