100% Managed Code

Through my normal routine of reading/responding to Microsoft newsgroups, a question came up about "100% Managed Code" phrases that companies use.  Specifically, the user was asking about a PDF component advertising it as such, and was just wondering if it was possible that they were using the Adobe APIs still.  Well, my response basically stated that since they're advertising it as "100% Managed Code", that it probably doesn't use Interop, and has built on the described api.

This has basically made me start thinking about the term "100% Managed Code", and why companies use this.  As I can see, this may be a nice selling point to business managers and what not, but it really doesn't play into a developers mindframe when they're checking out components (unless there is a defined restriction set forth by their company).  I for one have been seeing "100% Managed Code" for several years now, and always disregard what they're saying, only because I don't care.  So what, its "100% Managed Code", does it work?  If you say yes, and I don't need to purchase anything further I'm sold.

So, why is this a big deal?  Well, I feel that some companies may misuse and overuse the phrase "100% managed code" just because its hip, cool, and "the" thing right now.  Okay, okay...so does that mean I can advertise all my free server controls as "100% managed code"?  Well, sure...I mean, I use C# to build them, they need the .NET framework to run, why not.  Well - DUH - of course my controls are "100% managed code"...otherwise you really wouldn't be able to use them...which is the main reason its implicitly dubbed "100% managed code".

However, the biggest gripe I have, is with those companies that release a new component or tool, and just to add hype, they state "100% managed code" and, lets not forget "Built on the .NET framework!"  Wow, thats amazing...or is it?  In this day in age, you're seeing a lot more applications being built on the .NET framework more and more, but why are companies still overusing and misusing this phrase? I think its a increasing trend that has absolutely no affect on how I look at 3rd party components when determining if they'll work for what I need them.

So whats my point?  Think about your descriptions of components/tools, and how is it going to appeal to the common developer.  Are we going to be amazed that it works - probably. Do we care that its written entirely on the .NET framework, not as long as my previous statement holds true.  Remember that about 95% of the time, its developers that are given the task of finding a tool/component that solves a certain problem, not a business manager - so why do we need the hype?

3 Comments

  • 100% managed code matters quite a bit for me from a development standpoint. It's not uncommon for people to want applications launched via an UNC or even a hyperlink, and unmanaged code is not allowed to run in these situations by default. And I certainly don't want to tell someone to lower the security for their app solely because the toolbar control I'm using needs a Win32 api call or something.

  • You're requirements would fall under my "unless there is a defined restriction set forth by their company" statement.

  • At Xtras.Net we addressed that issue of 100% managed code in our printed catalog (but unfortunately not yet on our website.) We identified that components fall into one of several categories, in order of desirability (IMO):



    1.) Written 100% in a .NET language

    2.) Using unmanaged code in C++ or C#

    3.) Calling an unmanaged DLL (but not COM)

    4.) Wrapping a COM/ActiveX component



    Vendors sometime do #2 or #3 because they need to do something that simply can't currently be done in unmanaged code. #4 is usually done to quickly port a product to .NET.



    I think the benefits of 100% managed code is robustness from type safety, automatic memory management, and other .NET-specific features. A chain is only as strong as its weakest link. Certainly any part of the .NET framework that calls the WinAPI is calling unmanaged code, but a 100% managed code component is highly unlikely to be less robust than a component containing less than 100% managed code.



    For example, COM/ActiveX components are much more likely to have bugs than .NET components because there are simply many more ways to make a mistake when implementing COM than in a .NET language.



    Unmanaged code in general is much less robust because of errors that are possible in C++ that are not possible in C# or VB.NET. For C++, BoundChecker was one of the most necessary and useful 3rd party products sold. There is no (need for a) BoundsChecker in .NET.

Comments have been disabled for this content.