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?