Home > C# > Managed code isnt always the best solution

Managed code isnt always the best solution

Managed Code isnt always the best solution

January 15th | 2009

Managed code isn’t always the best solution

Managed code is cool. In fact most of the code I write at work is managed code in C#. In one case our product team needed to write some unmanaged code as a Log On credential provider. Throughout Microsoft’s documentation on this, it was strictly mentioned that Managed Code is a bad idea. Well, why? It’s not just for performance.

.NET inherently was designed to be version-independent, meaning an application that targets the .NET 1.1 Framework CLR cannot run on 2.0, and 2.0 CLR projects will not be able to run on the 4.0 CLR, when it’s released. This is why extensions for Windows can rarely be written in managed code. It is possible to write a Log On credential provider in managed code since .NET can be exposed to COM and vice-versa. It will even work. But assuming you write a credential provider that is built in .NET 2.0, and another vendor tries to provide one in .NET 1.1, or any version other than 2.0, the logon.exe process will attempt to load both versions of the .NET Framework. This will ultimately fail and the user will not be able to boot without going into safe mode.

The same applies to context menus for Explorer and Add-Ons Internet Explorer. They can both be extended using Managed Code, but all it takes is a version conflict to kill them off.

So, as much as we love our managed code, there are scenarios where it isn’t a good idea to use it. Ultimately, if you are trying to extend any application that uses COM (or any other unmanaged code solution) as its extension method, rather than Managed Code, then stick with Unmanaged Code.

Kevin Jones is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Kevin

Categories: C#
  1. googly
    January 17, 2010 at 5:23 am

    Might be worth mentioning that starting with .NET 4.0, you actually can run CLR 2.0 and 4.0 side-by-side in-process?

  2. January 18, 2010 at 2:45 am

    But with CLR 4 we do get InProc SxS and from then on we should not be affraid that another runtime has been loaded in the process already (for assemblies that are targetting v4 or higher).

    (http://blogs.msdn.com/clrteam/archive/2009/06/03/in-process-side-by-side-part1.aspx)

  3. January 18, 2010 at 4:49 pm

    That’s abolsutely true – but until the .NET Framework 4.0 is RTM I did’t want to mention it (I know I have been talking about C# 4 and .NET 4 recently). There are several other reasons why managed code isn’t the best solution all of the time either, but I recall that being a big one for many developers years back when 2.0 was released.

    Our new Product, Password Reset Server, could not wait for the .NET Framework 4.0 to be released.

    Other reasons why managed code isn’t the best option:

    1. Performance is sometimes an aguement. There are cases where native code will execute faster, but for the most part the difference is negligable. If you are trying to develop a real-time application, the .NET Framework may not be the best solution (then again Windows may not be the best operating system for a real-time system).

    2. You still depend on the CLR. If you were to write a shell extension that depends on the CLR 4.0, and that person doesn’t have the .NET Framework 4.0 installed, they now have to install a 50 MB (minimum) package just to have a toolbar or context menu. If it gets installed anyway, that process will now start crashing (like explorer) because it can’t find the proper version of the CLR.

    You would either have to install the 4.0 Framework for them, adding a hefty size to the installer, or tell them how to install it themselves.

    It’ll probably be a good while before the .NET Framework 4.0 has a solid adoption and shows up in Windows Update.

    3. And Frankly, while COM Interop and P/Invoke are neat – sometimes it’s just plain easier to write it in native code than write a large unmanaged wrapper.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: