Difference between COM DLL and ActiveX control

ActiveX controls are simply COM objects that, at a minimum, implement IUnknown. Recent versions of IE have started to also require the object to implement IObjectSafety. To do anything useful, the object needs to implement some other Ole interfaces as well, such as IDispatch, IOleObject, etc. The object needs to be create-able via CoCreateInstance() which means you have to register it in some way with the registry. You don't have to use a guid in the tag, you can also use the AppId if you register one.

You can also write some managed code and get that running inside IE as well. The way that works is the CLR registers a MIME filter when it is installed. Then when IE sees you're sending down something of the proper mime type, it hands the code off to the CLR to handle. The CLR does sandbox the code to the extent that it is only granted Internet permissions, so it can't do everything the framework exposes. You'll have to check specific documentation for what can and can't be done in this security zone.

Some trade-offs:

Ease of Installation: ActiveX controls require you to pack everything up into a .CAB file with an .INI file that describes the installation requirements in a fairly cryptic manner. If you have to install additional dependencies with your modules (such as ATL/MFC dlls, or other third party modules) it gets pretty tricky. With the .net module, you just send it down with the right MIME type, but you have to make sure your users have the right version of the framework (which you can check via user agent string on your website).

Security: ActiveX controls are just native code running on the users system, so in theory they can do whatever they want. In practice LoRIE limits it in many cases and you have to do a bunch of special casing of things like Registry and File System access (see Understanding and Working in Protected Mode).

Threading: Since ActiveX controls run on the browsers UI thread, you have to make sure you don't do long blocking operations on that thread, so you have to do the threading yourself. If your long blocking operation manipulates the DOM, you have to Marshal the IHTMLxxx interfaces yourself, either using the GIT or COM Marshalling functions. I'm not sure if the .net applets run on the browsers UI thread or not, but it's easier to handle in C# I'm sure.

Browser Objects: If you want to use IE / Shell objects in your managed extension, you have to write the interop yourself most of the time since the Framework doesn't do a great job of wrapping those interfaces in managed objects. See http://pinvoke.net to get a little help getting started.

Compatibility: There are issues with hosting different versions of the runtime in the same process. Until recently it wasn't possible at all, but I think with the 3.x versions it has started to become possible to an extent. The upshot is if you target .net 2.0 and someone else already loaded .net 1.0 as part of their browser extension, you lose. In general IE and the Windows Shell don't support managed extensions. This .net app MIME filter stuff may be a notable exception, but be aware that there may be potential issues.

Win32 is still heavily based on decisions made in the DOS days, for backward competability. After investing so much in COM, Microsoft will probably keep that spirit supporting COM interop until .NET dies. Having that said, they will just maintain what they have, without any further development.

The ActiveX vendor, OTOH, doesn't have that kind of commitment (or at least they don't feel they do). So regardless of Microsoft's support, they can just drop the ActiveX interface if they like. And they are definitively right saying people hardly ever use COM anymore.