After ten years of .NET do we know what we are doing? It is time to reflect on where we are and how we got here - just in case it might give us a clue as to where we are going.

On July 11 2000, the first developers left the Microsoft Professional Developers Conference with, not only the news that .NET was the next big thing, but the first beta of Visual Studio .NET and the .NET Framework.

The fact that .NET existed had already been announced the week before at TechEd Forum 2000.but PDC was the first time it was released into the wild.

So around ten years ago you could say that .NET hit the fan and real programmers got to find out what it was all about. Its time to look back, take stock and tell stories of the early days...

The original press release of the announcement is still available on the Microsoft web site  and what might surprise you is that from this early stage Microsoft was emphasising .NET as a platform for building web applications.

Also interesting is that the .NET Compact Framework was announced as a way of creating programs for handheld devices. Microsoft still hasn't managed much in the way of domination in this market.

At the time most programmers were deeply puzzled by the whole .NET idea. Many just saw it as a way for Microsoft to absorb Java technologies without being allowed to use Java - which indeed it was. Many new buzz words were introduced at the time - managed code, manifest, intermediate language, sharp, XML, assembly . Exciting times - but how did it all pan out?

Assassination of VB

No matter what you think of .NET you should never forget that Microsoft didn't give the developer community a choice. It forced .NET on us and killed Visual Basic 6. Anyone with a VB 6 application suddenly had a legacy application on their hands and was forced to migrate or enter a maintenance only mode.

In case you don't remember, at the time VB 6 was the most popular programming language ever and represented the largest single programming community. It is arguable that .NET was obviously better from the word go but this wasn't something that was allowed to prove itself by market adoption. You either moved to .NET or moved away from Microsoft technologies.

In retrospect this was a huge gamble on Microsoft's part and you have to admit that it was brave.

COM v the Manifest

At the same time as VB 6 was killed off so was COM. Arguably just at the point that DCOM was about to reach a working and useful state the whole complex edifice was torn down and replaced by... well what exactly?

Can it be that we never needed binary components at all? 

.The basic idea of COM was simple and elegant even if it was just a formalisation of the C/C++ calling convention with a few rules for finding out what methods were available. The big trouble with COM was the way that it grew additional technologies that were increasingly complex and difficult to use to the point were the whole thing became a black art.

Today we have the manifest and the idea of introspection - although if it is being done from alien code it probably should be called extrospection. You can pick up a compiled assembly, find out what objects it contains and what properties and methods they support. You can then proceed to use the objects, methods and properties without having access to the source code - but how many people do? Component writers do and that's about it. Overall the impact of binary reusable objects just isn't that great

On the other hand while the majority of developers have indeed given up on COM Microsoft's insiders still make use of it to the point where trying to use many Microsoft technologies means using less than satisfactory Interop facilities with COM. New APIs are often more or less inaccessible to .NET programmers simply because they are COM based. This is still all a bit of a mess but overall it's because the technology hasn't gone fast enough. 

SOAP

What is worse is that, just at the time we were managing to sweep the overly complex COM technology out of the Windows, for some unknown reason we had SOAP forced on us. Web services aren't rocket science, as proved by REST or almost any simple alternative, but SOAP wasn't about simplicity. It was a display of unnecessary cleverness. It might have been able to work with almost any transport and almost any interaction model, but trying to make it work at all was a time-consuming distraction from the real job. Today SOAP hangs around because Microsoft doesn't feel quite able to commit to killing it off but support for REST is on the up and when you do meet SOAP as part of a web service it is well hidden.

<ASIN:0470548657>

<ASIN:0672330814>

<ASIN:0071668950>

<ASIN:0321533216>