Sunday, April 29, 2007

.NET ActiveX

ActiveX controls in the browser have been an interesting concept, especially in the Intranet environment. However their popularity has been on the decline, especially with the kind of apps that can be created with Web 2.0 technologies (mainly AJAX). However, there's still a good no of use cases where ActiveX in the browser seems a really good solution. And especially if that ActiveX component can be written as a .NET control.

One good use of this style of architecture is when a web application needs to interact with connected devices on the client's machine such as paper/check scanners, portable devices etc. Since an ActiveX control can access local resources, interaction with such devices in a web app through the control allows you to post information back to your backend systems for processing. This makes a whole lot of sense, especially since it avoids you to write web services for communication with a backend systems written on a different platform or language (say JEE).

A list of things that one has to remember while writing an ActiveX .NET control:
  • The control has to be coded as a Windows Form control with "Make Assembly COM visible"checked in the Assembly information of the Project's properties.

  • Your OBJECT tag in the HTML page points to the .NET DLL, like so -

    <OBJECT id=”myControl” CLASSID=”http://server:port/MyApp.DLL#MyControl”/>

  • You should load the control with a javascript function for the Eolas Lawsuit workaround that prevents controls from being active on page load. In short the OBJECT tag mentioned above should be written out (using document.write) by a javascript function on a page load.

  • You need to create a security policy that needs to be pushed to the client's machine that is going to run the ActiveX component. Note here that if this is an Intranet application, rights to the control have to be defined under the LocalIntranet_Zone in the .NET Configuration management console.

  • And finally make sure your Internet Explorer policy settings allow for running "ActiveX controls and plugins".
Looks complicated, but there are plenty of articles explaining the details as well as examples to go with it. I also was able to deploy the control to be served off a JEE application server (Weblogic) which allowed the backend to a non-microsoft solution. The tricky part here was that the dll had to be renamed so that the extension of the control was in CAPS ".DLL", and the declared mime type for a "DLL" extension was "application/x-msdownload".

Still have questions on this - just ask here.....:). But this type of system architecture will help you leverage the best of both platforms - mainly .NET(on the frontend) and Java(on the backend).

No comments: