Please read my blog's comment policy here.
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.
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.
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. http://blogs.msdn.com/b/ieinternals/archive/2009/10/09/dotnet-usercontrols-do-not-load-in-ie8-internet-zone.aspx
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.
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.
Could you please name a handful of its compilers?