The rise of .NET
.NET was created to solve many of the type mapping problems of COM that I described in Part 1. Microsoft really wanted to improve the developer productivity – and thus decided to invent a new programming language – the birth of C#. What a beauty for a seasoned C++ developer. It was consistent, a well designed blend between C++ and Java. We developers had to write considerably less code than in C++. Less code means less errors. The migration from C++ to C# just felt right.We C# developers got to love a better exception handling, huge libraries with lots of functionality and more consistent coding guidelines than ever before. .NET V1 missed a template mechanism with type-safe, generic collections. But the language designers were so bright, that the introduction of generics in v2 was no big pain. .Net and C# rose in popularity – and that had one major reason: .NET and C# could be used everywhere: You could use it for plain algorithms, UI, Server side code, web pages, web services and even the higher layers of embedded systems. And even more important: Microsoft constantly reshaped its own, freshly acquired Server-side products (like Biztalk or Sharepoint) to build an ecosystem around .NET. That increased the trust of many customers into the growing ecosystem. Especially in Germany it was quite a hard fight to establish C# and .NET as relevant and proven technologies into the Architecture Blueprints of bigger companies and use them as a foundation for mission critical systems. But .NET became more and more attractive for enterprises because of its reach, breadth and continuity.
Many developers joined in, the component market was booming – yet there was one problem: Microsoft itself never used .NET in its major client products: No .NET in Windows, no .Net in the core Office products. The teams of those very important Microsoft cash cows never joined in. That meant Microsoft never “dogfooded” WinForms or WPF for its own big developer teams in Redmond. Something was wrong regarding internal adoption, but not many noticed…
In 2003 I had joined my current employer Zühlke and changed from the software product development to the project development and consulting side. I saw many different project scenarios in a short time and got to learn all the different areas of the .NET framework. I was kind of an evangelist for .NET technologies in many different projects, helping our costumers to adopt these brilliant technologies. It was in 2005 when I faced the first serious problems with .NET loading performance. One of our ISV customers had built a big WinForms solution with our help and had problems with startup performance. The end customer was a well known German car producer and didn’t accept application “boot times” of over 40 seconds. This only happened when the computer was freshly booted – but at the time nobody suspended their machines into standby. Every user freshly booted in the morning, so we had a real problem. We analyzed the problem. Result: It took 38 seconds to hit a breakpoint at the beginning of main()! 2 seconds left for us to optimize. It wasn’t our problem. It was a .NET problem. We had many DLLs and the .NET runtime was simply extremely slow in loading and precompiling - whatever. Nobody in Redmond could help us on these problems. Microsoft hadn’t noticed these fundamental problems, because they mostly built Hello world examples with their frontend technologies. By that time I had an idea, why the Windows and Office teams didn’t want to join the .NET train… Nevertheless, we built great apps based on .NET, but the UI story had limitations for bigger applications with many screens.
More on this in part 3 and 4….
