iFinity Blogs 

Happy 10th Birthday .NET Framework–the little platform that could

Feb 13

Written by:
Monday, February 13, 2012 8:35 AM  RssIcon

The 13th February, 2012, marks 10 years since the .NET Framework 1.0 was released, well, according to Wikipedia, anyway.  I don’t recall the specific date, but I remember the general period vividly.

This little point of achievement will probably pass most people by as they spend another day creating new software based on this platform, or use one of millions of websites that the platform provides, or any number ways of interacting what has become an incredibly successful framework by any standard to measure.  But I thought it might be fun to just pause for a minute and reflect back on the last decade.

Is ten years such a long time?  Realistically, in computer industry years, it’s an absolute eternity.  The internet has really only been around for most people since the late ‘90s. The Windows 95 platform only lasted for 5 or so years before being dropped.  Visual Basic (the original version) went from 1.0 to 6.0 in 7 years, before being shelved to make way for .NET.  Many programming languages have come and gone in less time than a decade.

The way we were

It’s all too easy to take for granted the powerful tools we software developers have at our disposal.   It’s very easy to forget the kind of world Microsoft-technology developers had 10 years ago.   But let’s just cast our minds back to the late 1990’s and early 2000’s.    If you wanted to build a website using Microsoft kit, you’d probably have been using:

- Either C++ or VB6 to build back end components.

- SQL Server 6.5, or, if you were lucky, SQL Server 2000.

- Windows NT 4.0 server, or, if you were lucky, Windows 2000 Server

- Microsoft IIS 4.0 or IIS 5.0 running ASP pages.

In reality, in any fair comparison with alternative web development tools at the time, it wasn’t ideal.  In fact, many frustrating times, frankly, it was painful to get things done.  You’d spend half you day producing something, peppered with thoughts like ‘there has to be a better way’.

The Genesis of .NET

I was working on a large development project for a financial services company at the time.   It was a sophisticated setup, where VB6 components plugged into a business layer which was all based on DCOM, written in C++ and somehow connected it all up and made sure it scaled.  I say somehow, because it really was an obscure black box of dark arts, and there was only one guy on the floor who really knew what was going on.  He was brilliant in the way an older developer with a bushy beard can be.  But he wasn’t good at explaining what was going on in that layer.  You just had to take it on faith that it all worked, which it did, most of the time. 

The problem was in deploying to production.  In those days, IIS had a tendency to eat up a pile of memory and then freeze up.  The notion of automatically dropping an application pool on a periodic basis hadn’t happened yet.  And all those COM/DCOM components had to be installed on the server.  I don’t mean sent via FTP to the \bin directory, I mean, create an installer package, log onto the server, and run the installer.  And hope over all hopes that someone didn’t include a bad reference and send the entire team to “DLL Hell”, as it was known.

And that’s just the deployment part.  I was employed as a VB6 programmer, which I knew well, having come up through the VB ranks from 16bit Visual Basic 3.  While you’d never find me defending VB in an online forum, it wasn’t a bad way to quickly build software. But the not-quite-OO patterns in VB6 really made a developer do some unsavoury things.  And if you had a friend who was programming on the hot-new-language ‘Java’ they’d always guffaw, and talk about the language purity of Java.  Yes, never sit around with a bunch of developers discussing programming languages.

As the company I was working at was quite a large one with a substantial IT budget and a pure Microsoft technology platform, it got very good treatment from the Redmond HQ.  And one of those things was an early look at what was called ‘Next Generation Windows Services’.

This sounded like the answer to the frustrated VB/IIS developers requests.  This was going to be an entirely new programming platform, one that you could get enthusiastic about.   Gone would be COM/DCOM – although you could still use it if you wanted to (I didn’t ever want to, again).   Gone would be the VB6 platform, gone would be the VB IDE.   In would be an entirely new programming language called C# as well as a total rewrite of VB to make it a proper language.  This was going to be a proper object oriented language in either the less-verbose C style, or in the more verbose VB style.  Funnily enough, on first inspection C# looked exactly like Java.  Hardly a coincidence, one would suspect.   All new was a event-driven web page programming style, which smelled a lot like VB forms.  There was to be ‘xcopy deployment’ so you could just copy the program up to the server.  DLL Hell was to be banished forever by keeping the component metadata in the component itself, rather than in the operating system registry.

Funny thing – in true Microsoft style – they had a melange of names for it.   When I first heard of it,  the new version of ASP was going to be called ASP+.  And that’s why it has the .aspx extension – you couldn’t have a + in a Url, so they rotated it 45 degrees, and you had an ‘x’ on the end of the old .asp extension.    And C# itself, was basically C++,+ – with another ‘+’ thrown in for good measure.  Arrange 4 + in a square and you get #.  And thus C# was named.

I don’t remember when I officially heard the name .NET – it was probably closer to the launch – by that time I no longer worked at that company, and so lost access to the stream of new announcements from Microsoft.  It’s hard to believe today, but back then Microsoft didn’t do a lot of public BETA testing.    But at some point it was announced, then released.   And the .NET world was born.

.NET Leads the Microsoft Developers out of the Wilderness

It’s hard to understate the difference this change made in my life and career.  At the time, a lot of developers (and companies) I knew were jumping ship, and moving across to Java.  This generally meant a change in web server, programming tools and probably database platform for good measure.  And none of those were provided by Microsoft.  I’m sure the board reports at Redmond had some metric for measuring this.   One of the biggest secrets of success for Microsoft has always been the support of developers.  Having an operating system without third-party developer buy-in means failure.    The original success of Visual Basic was the ease in which people could build ‘GUI’ apps quickly, in an era when DOS based programs and mainframe terminals were still the norm in companies.  Users would have fits of delight when they could use drop-down boxes and update buttons instead of command line driven programs.

But the sea change from Windows GUI to Web was fast, and the tide was running away from Microsoft.   The challenge was on – how to take all those experienced and Microsoft-trained VB developers and turn them into web developers?

The answer was ASP.NET Webforms.  Now, to some web purists, the way in which this was solved still makes them go cross-eyed with indignation, but the simple matter was that it not only worked, but it did so in which it didn’t take a massive retraining for an efficient VB developer (or even a C++ developer, for that matter) to start being productive.

Of course, some of the bloated buggy and run-at-a-crawl sites that resulted are probably not excusable, as too many desktop developers didn’t really take the time to learn that programming for the web really did require a new mindset.  But, for Microsoft, it worked.  Within a short time, websites with the now-familiar .aspx extension were popping up all over the web.   The flow of companies and developers to Java was stemmed.   People like myself stayed on board.  It wasn’t necessarily that someone like myself couldn’t see the faults in Microsoft – clearly I could – but it’s crazy to pretend that no platform or environment is free of shortcomings.   As always, it’s about getting something that works, to market, in the quickest possible time.  By 2005/6, it was very common to find jobs looking for ‘3 years C# experience’ – which meant you had to be on board from the get-go.  Having conducted interviews around this time myself, I found that many people were being quite liberal with the truth on their experience, but .NET was here to stay, and anyone looking for a future in Microsoft platforms had to start collecting experience, fast.

.NET grows and grows

Despite the busting of the ‘internet bubble’, in reality, web developers were about to enter a golden age.  The truth of it was that the cost of building websites and launching them was falling quickly.  Part of that was cheaper hardware, and part of that was the growing stack of frameworks that added layer upon layer, each abstracting away a previously difficult and troublesome task, and making it a simple job.  Open source was, and remains, a huge part of this.   Of course, the leading web server, Apache, has always been an open source product.  But little by little, Open Source made it’s way into Microsoft as well.  But even without Open Source, there were plenty of free things that were getting added to the .NET family.   

Of course here is the appropriate point to mention DotNetNuke.  This is not to belittle other open source .NET projects, but it’s the one I work on and know most about.   Given that ‘.NET’ is part of the name, it should be obvious to all how intertwined these two things are.  DotNetNuke was (and remains) an open source framework which allowed you to quickly create websites, without having to build all the associated messy bits like authentication, logging, not to mention the killer app of DotNetNuke which was the ability to easily install third-party modules to infinitely expand the site with new functionality.

It sounds so simple and expected now, but this was such a massive jump in productivity it is hard to believe the old way of working.  In the heady days of the ‘internet bubble’, if you did find someone building an ASP based site, they would have had a team of developers working for 6 months to produce an approximation of what you could get from a DNN install in 6 minutes.  And it probably would crash too frequently, especially at dreaded upgrade time when it was time to release new code and find out if a trip to DLL Hell had been unwittingly scheduled.

I worked on one project that was building a social network site.  This was just before Facebook exploded out of it’s college niche and out to the greater public.  This was a sophisticated site that had blogs, forums, chat, video and photo uploads, and all the social features you’d expect including friends, groups and all the rest.   I’ve never know the exact figure, but my guess is that a 7 figure sum was spent in an 18 month period with developers to create this site, myself being one of them.   And without a shadow of doubt, I could build that same site today in DotNetNuke with a few third-party modules for more like $7000 and 18 days, and most of the money would probably go to a talented designer.

It’s easy to nod your head and say ‘yeah, that’s true’, but in few industries does this type of productivity leap occur.  Of course, this is nothing special with regards to a Microsoft platform – indeed many open source advocates would argue that anything built on a Microsoft platform is not truly open source.  But for a person who is tasked with producing a website that matters little.  But what shouldn’t be skipped over is that DotNetNuke wouldn’t exist without the .NET platform.  And I don’t mean that obviously because of the inclusion of the name, but more that the old VB6/IIS 5/ASP era was just not a good enough design to produce a modular masterpiece like DotNetNuke.  It just wouldn’t have been possible.

.NET Did it Right

The reason that great solutions like DotNetNuke can be built is because of the inherent correctness of the .NET platform.  It’s a true object-oriented platform.  The way the programming languages were designed dumped out all the nasty workarounds and hangabouts caused by trying to maintain backwards compatibility.   This was a true masterstroke of Microsoft, and one which they copped a lot of criticism for.  To build a good .NET application, you had to build it from scratch, you couldn’t upgrade your old code (well, you could, but the results were usually awful).  But by forcing people to start from scratch, everyone could start with a clean sheet of paper.  And, as anyone who has accidentally deleted a first draft will know, the second draft is not only better, it’s written faster as well.

From the in-built memory management to the well-executed ability of .NET code to ‘reflect’ upon itself, .NET was a really good platform to build with.  It’s like the difference between a toolbox full of half-broken, unsuitable tools, and a toolbox full of shiny tools designed exactly for purpose.   Having the ability to select the right tool for each little job, no matter how trivial, means that the finished product always comes out better, with fewer rough edges, and always with a more elegant feel.

And we can tell .NET has been a success.  Not because Microsoft tells us so, but because they’ve never changed the name (well, not since it was released, project names and working titles notwithstanding).    The easiest way to detect a floundering Microsoft product is to look for frequent name changes.    We all can rattle off several products that go through a series of names before quietly being shelved (the various old versions of Microsoft phone operating systems being a prime example).   But .NET is still there, still being used, not being tinkered with.  Visual Studio is still Visual Studio, C# is still C#, with most people being blissfully unaware of how the name came about.  The true measure of developer stickiness, however, is a quick peruse of a jobs site.  And there are still plenty of jobs to be had working in .NET.  Sure, there are newer, ‘hotter’ platforms out there, I’m not a one-eyed Microsoft supporter in the least.  But can I still deliver a cost effective solution to someone who has chosen to use Microsoft based operating systems?  I sure can.  Are there still plenty of people choosing Microsoft Operating systems?  There sure is.  IIS is still the second-highest Web serving platform on the internet, and the best way to deliver websites through IIS is by building an ASP.NET website.

The next 10 years

10 years ago a lot of people I knew were either moving, or seriously considering moving from Microsoft products into Java as a platform.   I haven’t heard someone say that in years.  In fact a couple of the Java people I know are starting to dabble in other platforms and languages, and they tell me that they feel Java has lost its way.  I couldn’t say myself – I’ve been deep into the .NET stack for a decade and haven’t spent much time exploring outside of that.  There has never been a shortage of opportunities for me, there has never been a point where I’ve felt that the platform was going nowhere.   In fact, every time I look up, I find lots of new and interesting stuff coming down the road.

There’s an entirely new Windows version coming along which is destined to bust out of the traditional desktop and onto other devices, there’s lots of new ways of building traditional ASP.NET websites,  there’s Azure cloud services to build, as well as plenty of traditional desktop applications.   The next 10 years is going to see the explosion of web-enabled mobile platforms, either through on-device apps or mobile-optimised website apps.   There’s still a long ways to go in terms of building websites on platforms like DotNetNuke.   Yes, it’s fair to say I still feel the same level of optimism about the future as I did 10 years ago.   I guess I’ll see you in a decade!

What do you think?  Did .NET get it right 10 years ago?  Will it still be around in 10 years time?  What’s your experiences in the last 10 years – please feel free to share in the comments.

Tags:
Categories:
Location: Blogs Parent Separator Crafty Code

2 comment(s) so far...


Gravatar

Re: Happy 10th Birthday .NET Framework–the little platform that could

Thanks, Bruce, this is the best explanation I have seen of the origins of .NET.

I started selling Windows apps in 1995, targeting Windows 3.1 (still very popular at the time). Unfortunately, Microsoft never explained to developers like me the benefits of .NET. All I knew is that I had to ship the framework in my installation package (we were still using diskettes then). How could I trust a component that Microsoft wouldn't even include in its O/S installation?

I had heard horror stories of PCs not rebooting after installing the .NET framework. Try explaining that to a little old lady 3,000 miles away? For a $29 product?

I have written C# DLLs to interface with a third-party .NET app. I still can't get the GAC to work, I have to copy all their DLLs to my installation directory. Whenever they ship a new version, I have to re-compile and re-publish my program. Ugh. This is productivity? Give me old-fashioned DLLs any day :o)

However, I do respect the benefits that other programmers have experienced, and I try to keep an open mind. I can understand that in a big shop with its share of average journeymen, Java and C# prevent you from shooting yourself in the foot.

By Pierre Clouthier on   Monday, February 20, 2012 7:28 AM
Gravatar

Re: Happy 10th Birthday .NET Framework–the little platform that could

@pierre - you raise some very good points. One thing I skipped over in my post was the windows development side of things. In many cases, while the environment might be better to develop in, distributing the .net framework with a small windows app was a difficult choice to make for downloadable apps. It's much better now (particularly if you target earlier .net versions - not many Windows 3.1 installs around nowadays), but still will always require the VM to be downloaded and installed.

The GAC is the way that Microsoft decided to get out of DLL hell, but I've learnt from experience to avoid it all costs. I've always found that boiling down the code to as little to ship as possible, and avoiding built in wizards, helpers and add-ons is the best way forwards. This is true if you're doing a consumer grade program or one for a locked-down corporate environment. Still, the distribution of Windows still makes it easire for .NET developers to target the environment than Java developers, who have it much worse in this regard.

By Bruce Chapman on   Monday, February 20, 2012 4:39 PM

Your name:
Gravatar Preview
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel 
Bruce Chapman
Hi, I'm Bruce Chapman, and this is my blog. You'll find lots of information here - my thoughts about business and the internet, technical information, things I'm working on and the odd strange post or two.

 

Share this
Get more!
Subscribe to the Mailing List
Email Address:
First Name:
Last Name:
You will be sent a confirmation upon subscription

 

Follow me on Twitter
Stack Exchange
profile for Bruce Chapman at Stack Overflow, Q&A for professional and enthusiast programmers
Klout Profile