Interviews Visual Studio .NET was released on February 13th 2002, marking the moment when Microsoft’s Java alternative was declared ready for business.
Screengrab from the announcement of Microsoft .NET at its Professional Developers Conference in 2000. Score?
Dates are difficult. The .NET Framework 1.0 and Visual Studio .NET 2000 were first made available to developers on 15 January 2002, but only to subscribers of Microsoft’s developer network (MSDN). The official launch though was at the VSLive! 2002 conference in San Francisco, where then CEO Bill Gates described it as “the first fully integrated development environment for building XML Web services and next-generation internet applications.”
Visual Studio .NET 2002: released 20 years ago
The .NET Framework was first previewed 18 months earlier, in July 2000. We cast our minds back. Windows 2000 was released in February of that year. Microsoft’s development platform at the time was formed by Visual Studio 6.0, a bundle of separate IDEs including Visual C++, Visual Basic (VB), FoxPro, Visual InterDev and Visual J++. Visual C++ aside, all of these languages had issues.
VB was wildly popular but not object-oriented, complex and intricate for advanced use with COM and the Windows API, and bested in nearly every respect by Borland’s Delphi. FoxPro was brilliant in its way, but its DBF database format was not, and Access (part of Office rather than Visual Studio) was more popular and better aligned with SQL and SQL Server. Visual InterDev was Microsoft’s first go at web development using Active Server Pages (ASP), a sort of VB version of PHP, but without its simplicity or cross-platform capability.
Visual J++, designed by Delphi’s architect Anders Hejlsberg who had jumped ship to Microsoft in 1996, was Microsoft’s version of Sun’s Java and rather good for Windows development, but it did not conform to the Java specification and was the target of righteous litigation from Sun.
At the time, the .NET Framework was just one component in a new strategy. “It’s our task to introduce you to a new generation of technologies from Microsoft,” said Paul Maritz, then group VP of platforms strategy, speaking at the company’s Professional Developers Conference (PDC) in July 2000.
Maritz likened its significance to that of the Win32 API, introduced with Windows NT eight years previously. Originally called NGWS (Next Generation Windows Services) while under development, Maritz said that “we finally alighted on the name .NET because it represents the set of technologies designed to contribute to making the internet into a true distributed computing platform.”
Microsoft’s idea was for a programmatic web driven by XML web services using SOAP (Simple Object Access Protocol), an XML standard for exchanging data over the internet. “We call this a web services architecture… our .NET platform is designed to make it easier to build those types of applications,” said Maritz.
The strategy was intended to put the company at the heart of the internet with its Passport directory and a set of first-party XML services codenamed Hailstorm, unveiled the following year, but soon abandoned thanks to anti-competitive concerns.
This was the big picture into which the .NET Framework was introduced. “This has been a long time goal for us, to get Visual Basic, Visual C++, and our other languages onto a common footing … we have today the first true general-purpose multi-language modern object-oriented runtime environment,” said Maritz.
His wording was an attempt to differentiate the .NET Framework from Java, with which it seemed to have a lot in common. The pitch was that Java was just one language, but the .NET Framework had the “common language runtime” (CLR) that would run all kinds of languages. That seems an odd distinction today, when the notion of JVM languages is commonplace, and most .NET development is done in C#, but it was important at the time.
Microsoft also played the open source card. “It is our intent to take the full intellectual property in this common language runtime and these class libraries and offer them to standards bodies so they can become a truly open set of standards,” said Maritz.
In practice the company was not wholehearted about open source .NET. ECMA-335 for the Common Language Infrastructure (CLI) was published in December 2001, but this was far from being the complete specification for the .NET Framework.
It was not until 2014, with the forking of .NET to become .NET Core, that Microsoft really got behind open source .NET and made it cross-platform. And even last year decisions were made and revoked that would have damaged the open source release.
Maritz also referenced a new framework for web applications, then called ASP+. “We need to do for web development what the industry did for GUI development,” he said.
ASP+ web forms had a drag and drop visual interface builder that worked, brilliant for enabling VB programmers to build web sites, though with architectural limitations that became apparent later.
Java and .NET
The influence of Java on .NET is complex. Sun’s Java was a conscious attempt to undermine Microsoft’s de facto monopoly on business computing at the time, and both Visual J++ and later .NET were key to the company’s riposte.
That said, the technology in .NET came from the Visual Basic team according to Mark Anders, co-inventor of ASP.NET with Scott Guthrie, who spoke to this author in 2007 about “Project Cool,” an early codename for the CLR, while also revealing that early prototypes of ASP.NET were written in Java. “I loved Java as a language and Scott did too,” he said.
“The VB team was working on developing a new runtime, what became the Common Language Runtime. It was not as complicated as COM, and it had a nice object system, it was garbage collected. So we made a decision that we would write our thing, which at the time was called XSP, in this new runtime. So we were the first ones to commit to writing anything on it,” said Anders.
Hejlsberg was also a key creator of .NET. When he joined Microsoft he architected Visual J++ 6.0 and the Windows Foundation Classes (WFC), including a Delphi-style two-way visual design tool so that changing code updated the visual design and vice versa. Hejlsberg designed the C# language for .NET, drawing on his experience with Object Pascal at Borland, and adapted the WFC to become the Windows Forms class library.
“The step from WFC to Windows Forms is almost a mechanical one. We use different conventions, and we now have a language that properly supports properties and events, and therefore certain things have a different syntax. It’s evolved to the next logical step, but it is a direct descendant of WFC so there’s nothing really structural that would have to change about the code,” said Hejlsberg in 2001.
Hejlsberg acknowledges that “Java served as an inspiration” for .NET, but alongside Delphi and VB.
Mono: .NET for Linux
A curious truth about .NET is that its position today owes much to an open source project developed outside the company, called Mono, instigated by Miguel de Icaza who is also well known for starting the GNOME desktop environment for Linux.
We spoke to de Icaza for this anniversary. His interest in .NET was driven by the search for better programming tools for GNOME applications.
“When we started GNOME, there was a move in the Unix world in that era based around the power of higher level languages to reduce complexity,” he tells us. “A guy called John Ousterhout built a language called TCL and a UI toolkit called TK, and it was fun building applications, the problem was that TCL wasn’t a great programming language.
“But he made his point that you want to raise the abstraction level… there were many different efforts, we tried to use Java at some point but the Java JITs (Just in time compilers) were not far along, the toolkits were not good enough. We ended up with a toolkit for building GUI applications written in C, fully open source, called GTK. It fitted the bill but it was programming in C, and we really wanted to make this available for multiple languages,” says de Icaza.
This was done and the GNOME team created bindings for languages including Objective-C, ADA, Perl, Python, C++ and Scheme. “The idea was to keep programming at a high level of abstraction,” says de Icaza, but there were performance issues. “When .NET came along it checked a lot of the boxes. It was a high level language, it was compiled, it didn’t suffer from some of the downsides of the scripting languages at the time.
“The other thing that was interesting was that the bytecode was easier to JIT compile. It was a little more work in some areas than Java, but it had capabilities like structs that were super nice, delegates, interfaces. DLL import was a big component of what really mattered to us, because we had this big asset in the form of C libraries that we could talk to.”
Mono was originally based on “just the ECMA subset” of .NET, says de Icaza, supplemented with its own stack, but “people flooded it with contributions, to get pieces of ADO.NET and ASP.NET and Windows Forms, the whole thing.”
It became an open-source, cross-platform alternative to Microsoft’s .NET Framework. Parts of Microsoft were supportive, parts were wary, but Mono co-existed, right up to the point in 2016 when the company realised that it needed Mono and acquired Xamarin, a company co-founded by de Icaza, to enable C# coding for mobile platforms. What did that feel like?
De Icaza does not answer this directly but says that the improved relationship with Microsoft “started with Mobile, and with Unity, Unity was a huge success on mobile.” Unity is a game development engine which uses Mono for scripting.
“Mobile changed those dynamics,” says de Icaza, and there were already “all kinds of different partnerships” with Microsoft. The need for .NET on mobile brought the business side of the company on board with Mono, and there had always been good relationships on the technical side, says de Icaza.
Remembering Longhorn and Silverlight
At Microsoft’s PDC in 2003, the company introduced Longhorn, a radically different new version of Windows built on three “pillars”: “Avalon”, based on .NET and DirectX, for the shell; WinFS for the file system based on relational data; and “Indigo” for a new web services communication subsystem again based on .NET code.
In mid-2004 Longhorn was in so bad a state that Microsoft had to re-start development based on the Windows Server 2003 code, a crisis known as the development reset.
The redone Longhorn reduced the dependence on .NET, with Avalon, which became Windows Presentation Foundation, becoming just another application framework rather than being an integral part of the shell.
The apparent role of .NET in causing this costly reset seemed to have a long-term effect on the Windows team within Microsoft, and may have been a factor in Windows 8, years later, using a new framework for its “modern” applications rather than using .NET.
What went wrong? We spoke to Scott Hunter, currently director of Program Management for .NET, who joined Microsoft back in 2007.
“Longhorn had a couple of crazy ideas, that the file system was going to be based on SQL Server, the desktop was going to be built on .NET,” says Hunter. “It was before its time. Computer hardware just wasn’t ready for most of the ideas in Longhorn. What’s cool is that many of those concepts do map over to today, so we did built the Start menu on .NET, on modern Windows, so there are remnants of that stuff around.”
Another bad moment for .NET was in 2010 when, at another PDC, it became apparent that Silverlight, a cross-platform browser add-on that was also used in Windows Phone, was sidelined in favour of HTML and JavaScript. Then Server and Tools president Bob Muglia confessed that “our strategy has shifted,” since Silverlight had previously seemed a key part of the company’s future platform. Both Silverlight and Windows Phone were eventually canned.
When, you think about Silverlight, realise Silverlight is alive today. NET 6.0 is built on Silverlight
“When, you think about Silverlight, realise Silverlight is alive today,” counters Hunter. “.NET 6.0 is built on Silverlight. When we did .NET Core in 2014, the beginning of the .NET Core journey, that was taking the runtime from Silverlight, the cross-platform .NET that we already built, so that tech does live. None of that history matters today,” he says.
Coming next for .NET: MAUI
Hunter tells us that .NET 6.0, released late last year, was a huge moment for the technology because it “was the unification, suddenly you could build all the types of apps, desktop, mobile, web, on the same BCL [Base Class Library], the same runtime, all the same compilers.”
The missing piece at launch was cross-platform desktop applications, but that is soon to be addressed with the release on MAUI (Multi-platform App UI), based on Xamarin.
“At Build we’re going to RTM [Release to Manufacturing] MAUI.” Build is Microsoft’s developer conference, dates are not yet announced for 2022 but the event generally happens in May.
Hunter clarifies the thinking behind MAUI. “One of the things we don’t want to do is to build new UI stacks. So MAUI is a wrapper around existing UI stacks. Our days of trying to make UI stacks are over.
“If you’re on Windows it wraps WinUI, if you’re on Mac it wraps the Catalyst tech which lets you build an app that runs on the Mac and iOS, and on Android it wraps native Android. In the future, if we wanted to, we could wrap Flutter or whatever. MAUI is an abstraction on top of all the UI stacks.”
Hunter’s comments are interesting because Google’s cross-platform Flutter, recently made ready for Windows desktop applications, is perceived as competition for MAUI. It may be better to think of it as an alternative philosophy, picking a side in the long-standing debate about whether cross-platform GUI frameworks should draw their own controls (such as Silverlight, Flutter, or Java’s Swing and JavaFX) or wrap native controls (such as Xamarin, or Java SWT).
“You could build your own UI control set that does not use native UI,” Hunter tells us, “but we are currently going down the path of native UI.
MAUI: spot the Mono runtime still in use
“We’ve all seen this explosion of Electron-style applications, whether is Slack or Teams or Visual Studio Code. We wanted to make sure that .NET had a place in that story as well, so you can put a Blazor control inside of MAUI and now you’ve got a mix of web and native tech, all written in .NET.”
.NET Futures
Hunter observes to us that according to StackOverflow surveys, .NET is top in one of the “most loved” categories and has been three years in a row. The number of active users is growing, he claims. “We’re over 5.4 million. We assume Java is 10-ish million.”
“As we were shipping .NET 6.0 we were the number one highest velocity open source project,” says Hunter, referencing data from the CNCF (Cloud Native Foundation). “We fell down to about 3 or 4 after the coding milestone,” he said, “but we’ve been consistently in the top 30 since 2017.”
It’s also notable that .NET applications are increasingly deployed on Linux. “Sometime this year Linux will be half of .NET 6.0 and below usage,” says Hunter, referring to web applications.
Despite this optimism, there are shadows over .NET. It remains mainly dependent on a single company, and the .NET Foundation’s own survey shows how developers are skewed towards Windows, Microsoft’s platform, and more experienced developers, suggesting that its appeal to new programmers is limited.
Looking back on .NET history, it is also apparent that the multi-language aspect has been only partially successful, with most .NET development using C#, VB in decline, and F# a small though important niche.
It is also obvious, though, that introducing official cross-platform .NET in 2014 was the right thing to do, both technically and for the future of the platform.
Things have not panned out in the way that Maritz hoped over 20 years ago, but C# and the .NET platform have been a remarkable success. ®
Source link
