Managed Code Browser Extensions

I love the .NET Framework. I’ve been programming in C# since 2001, I spent much of my free time for a decade building Fiddler on .NET, and I now code in C# for a living. .NET provides a fantastic, highly-productive platform suitable for building a huge range of tools and applications, and as it grows in power and performance, its scope has only grown.

However, there’s one task for which .NET code isn’t suitable: building in-process browser extensions like Toolbars, BHOs, Pluggable Protocols, and ActiveX controls. These COM-based extensibility mechanisms were exposed long before the .NET Framework, and while .NET offers powerful interop with COM, it’s not an appropriate technology to implement browser extensions.

.NET-based browser extensions are responsible for significant performance and reliability problems in the browser. Even now that the .NET Framework version 4 resolved the side-by-side versioning problem, Raymond Chen notes that in-process browser & shell extensions shouldn’t be written in managed code. The Issues Specific to the .NET Framework section of the Guidance for Implementing In-Process Extensions MSDN article explains this topic in further detail.

Of the extension types, Toolbars and BHOs are the most problematic, as they are automatically loaded by every tab upon startup and often perform processing on every page load. The performance impact of such extensions can severely hurt the overall performance of the browser. Managed Pluggable Protocols and ActiveX controls are somewhat less problematic, as they’re only loaded when invoked by web content, but such usage should still be avoided.

Obviously, .NET remains a great choice for out-of-process interaction with browsers (e.g. like Fiddler or applications invoked by Application Protocol url schemes). If necessary, you could even use .NET to do most of the heavy lifting for your BHO or toolbar—just do so by writing a native-code COM extension (using C++, Delphi, etc) that itself uses RPC/named pipes/etc to marshal data to the out-of-process .NET code. That way, the only code running in-process with the browser is native and you avoid loading the framework into the browser process.

Over the years, IE has increased the restrictions and hurdles placed on binary browser extensions, going so far as to block them entirely in the Immersive/Metro mode of the browser. If there’s a new extension model in a future version of IE, I expect it will be based on JavaScript. But who knows, perhaps one day we’ll see a safe, fast, and stable way to build add-ons in managed code that is automatically executed out-of-process.

-Eric Lawrence

Comments (7)

  1. Warren says:

    Hi Eric — Just musing out loud here — but is it possible that the new .NET Native compilation method could help open the door for writing managed browser extensions?

    [EricLaw] Great question; I wondered the same when they made their announcement. I think that native compilation alone doesn't resolve much (and could even make things worse due to how the linking works) but it could be an important step along the path of making such extensions practical in the future.

  2. yuhong2 says:

    What is funny is that IE once supported .NET UserControls.

    [EricLaw] Indeed, .NET UserControls were disabled after it was realized what a nightmare they were.

  3. Chaz Gatian says:

    JavaScript based extensions would amazing.

    [EricLaw] Yes, this is a common request. JavaScript isn't a panacea, however, as the Firefox and Chrome teams have found that a non-trivial number of JavaScript-based extensions suffer from security and performance problems. Also, note that you can already write basic IE extensions in JavaScript today; see for instance.

  4. Vitor Canova (@vitor_canova) says:

    Looks like you are "venting" right here.

    When I started read I thought you were announce you are living Microsoft. After I realized I already did.

    After I wondered you are living IE forever. Thank's god it's not the case too.

    Passed all those freaks I end up with this: Looks like is still very difficult develop IE extensions.

  5. Donnchadh says:

    Hello Eric – does this also include using the System.Windows.Forms.WebBrowser class from a WinForm application, since it is a managed wrapper around the ActiveX web browser control used by IE? Thanks.

    [EricLaw] No, loading the Web Browser Control into a Managed Process does not suffer from the problems described in this post; only going the other way (loading managed code into an IE process) leads to these problems. However, be aware that Web Browsers present a huge attack surface for bad guys, and your managed desktop application will not run with many of the security protections provided by IE itself (AppContainer/LowIL, Feature Controls, SmartScreen, etc) so you should do anything you can to help ensure that it is only loading trustworthy content.

  6. Flux says:

    Please let me get this straight: .NET plugins (semi-interpreted, semi-compiled, bytecodes) have performance impact and yet we should expect JavaScript (uncompiled, interpreted) plugins? Please correct me if I am wrong but I think the performance impact is even heavier.

    [EricLaw] Yes, you're mistaken; it's not just about compilation, but even if it were, JavaScript has been compiled for many years now. For the types of things browser extensions do, JavaScript is generally going to have a significantly lower performance impact.

  7. Argus says:

    Could you please name a handful of its compilers?

    And, if it has higher performance, why bother with .NET? Why not develop Fiddler with JavaScript?

    [EricLaw] Every major browser has included a JavaScript compiler for over 5 years. While performance isn't the only reason to choose a platform, were I to start writing Fiddler today, I would strongly consider doing so atop NodeJS, which uses the V8 compiler.