Monday, May 21, 2007

.NET and ActiveX

Wow, what a lot of trouble it can be to just get some ActiveX going in ASP.NET. Some may ask why you would want to even incorporate this technology which is only supported in Internet Explorer and which opens up a can of security worms. Well sometimes you gotta do what you gotta do and this is the best thing to use for some situations. The project I'm currently working on is a web based customer service type application and one request from one of our customers is that they would like our application to respond to their phone IVR. So that when employees receive calls, our web app will automatically respond by loading the customers info before the agent answers the phone. Hey it's nice to be greeted by 'Good morning Mr. Wilson what can I help you with". This is a situation where we kinda needed to use ActiveX. Well the good news is is that you can do this in .NET, the bad news is is that it can be very picky sometimes and it seems there isn't a whole lot of info out there about this topic (There is on Win32, but not .NET).


Okay, so here's the good stuff you came here for :)
First - you're gonna want to create a custom control that you can drop somewhere on your ASP page. We kept ours out of our existing solution and made a new solution just for our ActiveX stuff. (new class library solution -> new user control)
Second - If you're gonna want to be able to call methods / set variables etc AND respond to events (like mouse click, or custom events like the IVR is sending you a call) you MUST create two interfaces. One for events only and the other for methods/properties etc. These interfaces will be exposed to COM and will be the things your web page / other applications will communicate with. (example of all this will be on the next post)
Third - You will need to give all of your events [DispId(some unique int)] attributes
Fourth- You need GUIDs for your interfaces and custom control class/object. If you're using VS2005 it's easy just do 'Tools -> Create GUID'. (You don't HAVE to have GUIDs if you're making a plain jane control.. But if you want to use it over SSL and hook up events in JavaScript then you're gonna need to use them for sure)
Fifth - Right click on your the project your custom control is within and select 'Properties', go the the 'Build' settings and check the 'Register for COM interop' box. If you wanna be able to respond to COM you gotta set it.
Sixth - Register your new dll created when you compiled your new custom control. The old way, Win32 way, to do this was with 'regsvr32.exe'. The way you do it in .NET is to open up the VS Command Prompt, navigate to your .dll and type 'regasm /codebase customControl.dll'. Regasm is short for 'RegisterAssembly'. The '/codebase' will set the codebase in the registry. (Now you don't HAVE to do this step either... But again, if you wanna use it over SSL and respond to events and things your gonna need to register. Otherwise you don't have to)
Seventh - Add your new custom control to your ASP page. '<object id="Bob" classid="clsid:00000000-0000-0000-0000-000000000000"></object>'. Replace the 000... GUID with the one you used for your custom control. If all went well you should be able to see your custom control on your page. There is another approach to this, you could use 'classid="customControl.dll#namespace.classname' but then the dll has to reside in your ASP site, AND the KICKER is that this will NOT work if you plan on using SSL. So it's just easier to use the GUID :)... (But you don't HAVE to do it this way, you can use the second way 'dll#namespace.class' but.. it just wont work with SSL :)
Eigth - To wire up your events there are also two approaches. The first '<script for="Bob" event="yourEvent(args)"> some script </script>' is the the approach that seems to work the best. This will also not throw JS exceptions if it doesn't hook/sink correclty. The second approach which may let you know there are problems is '<script> function Bob::yourEvent(args) { } </script>'. I would recommend the first since it seems to work a little more often.
Ninth - Okay the last step is to strong name your assembly. This is pretty easy. Just right click on your project -> properties. Go to the bottom tab 'Signing' and check the box 'Sign the assembly'. Then in the drop down select 'New'. This will bring up a pop-up. Type in a name for your key file (this can be anything you'd like) and you can supply a password or uncheck the 'Protect my key file with password' if you don't want a password. Click 'okay' and you're done!
So there are the basics. Now we'll do some code examples in the next post, if you're a visual kinda person like me :)

Also check out Eber's blog to. We both worked on many of the ActiveX problems so we'll both be posting about some of the issues. So if I don't answer you question he may have it in his blog :)

No comments: