Microsoft .NET

.NET is Microsoft®'s software platform for future generations of their applications and development tools. It's code will eventually be included with all versions of Microsoft® Windows™ and they've proclaimed since at least 2003 that all of their current applications will be rewritten to use it. Microsoft recommends the use of .NET's runtime environment and APIs for all software development on Windows. .NET's benefits are debatable and its use has potentially negative implications for all computer users. See their marketing material for more information on what it is and Microsoft's vision of its potential.

C# is the flagship programming language promoted by Microsoft for .NET development. This language and the .NET run-time are intentionally designed with limits to help prevent developer errors, such as memory leaks and buffer overflows. But as Bjarne Stroustrup observes in The C++ Programming Language, "The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous."

C# and .Net began their existance as a project called "Cool" in the late 1990's. It was a set of extensions to the C++ programming language designed to compete directly with Java. Microsoft saw many developers flocking to Java and refused to comply with the Java license from Sun Microsystems, leading to Microsoft's loss in a related lawsuit. Microsoft took some of the benefits of the Java language, first attempting to add them to C++, then eventually releasing a "new" language called C#, which Microsoft denies is the Cool-Java-killer. The many obvious technical similarities and the [marketing] strategy of directly tarketing Java developers makes it clear C# and .Net are business tools with the intention of pulling users from Sun to Microsoft. As opposed to creating an innovative platform of great value Microsoft mimicked what they saw as their greatest threat and leveraged desktop market dominance to retain developers.

Alienating Developers

In a move particularly frustrating to .NET developers Microsoft broke version compatibility between versions 1.0 and 1.1. It's an unwritten standard that major changes to code, such as to interfaces which would break compatibility for platform developers, be given a new major version number (e.g. 2.0). This particular decision by Microsoft, in my opinion, fosters the belief that the product was rushed to market long before it was ready for use.

Also frustrating .NET developers is the lack of source code for the framework. Without the ability to directly see what's happening "under the hood" it's very difficult, if not impossible, to do many advanced things. For example, to create some advanced user controls never invisioned by Microsoft requires an understanding of the system's handling of controls, which can't be directly seen. Instead, developers are forced to work around such limitations. By this method Microsoft limits the creative abilities of developers and closes the framework to expansion by anyone not working for the corporation.

For its first two years of existance the WinForms libraries were pushed by Microsoft as the method by which all applications should create and manage their [user interface]. Developers are just starting to use it, but already this is being deprecated in favor of a whole new user interface library called Avalon. Developers are left creating applications using the WinForms library which they know will disappear, forcing them to rewrite their user interfaces later.

.NET and the C# language have been standardized by an international organization (see below). Consequently Miguel de Icaza began the Mono project, an open source implementation of .NET. With Microsoft's decision that their future will rely on .NET, it seems a healthy way to promote competition and compatibility across operating systems. However, with his continued communication with Microsoft, Miguel de Icaza asks "Is .NET on the Way Out?":

So now it's April 2003 and I'm hearing that .NET is dead... The 64-bit versions of Windows Server 2003 (once called Windows .NET Server, by the way) contain absolutely no .NET bits at all: No .NET Framework and no ASP .NET. Exchange Server 2003, the company's next major messaging server, contains no .NET. Office 2003, the premier office productivity suite, contains XML functionality only in the high-cost business versions and contains few native .NET features. In the biggest year ever of new product introductions from Microsoft, few if any of its products promote .NET, its supposed vision for the future... Frankly, I'm as confused as you probably are.

In 2006 Microsoft is already more than 5 years into promoting .Net. Yet in those 5 years few client applications have been released by the company. If .Net's "the future" why haven't the major applications, like Microsoft Office and Exchange, been rewritten on the .Net platform? They've made releases of all of their major applications since the release of .Net. Many companies - Microsoft customers - which have long used Visual Basic 6 or Win32 custom applications have already rewritten or begun the process of migrating to .NET. Yet Microsoft hasn't done the same. The obvious explanation would be that Microsoft's programs have a huge code base to migrate. But that doesn't explain why the first two versions of Visual Studio .Net weren't written on the .Net platform. They're native (Win32 API) Windows applications, yet they were created after .Net itself, so obviously no code migration would have been involved. Complete integrated development environments are complex applications with a wide array of necessary functionality. Not all of the necessary features can be written .Net. Native Windows libraries are required because in 5 years .Net still isn't robust enough to support feature-rich applications. If .Net isn't good enough for Microsoft to use, why should anyone else?

Standards and Lock-In

The Common Language Infrastructure (CLI) of .NET and the C# programming language are standards of the ECMA and ISO. Being controlled by [patents], however, means Microsoft's (explicit or assumed) permission is required for non-Microsoft implementations. The majority of libraries, such as WinForms for Windows™ client interfaces, are not part of any [standard]. Libraries that are not part of the standard are required for any useful development. In fact, the implementation of these often required libraries are tied to the Windows platform. These libraries can be changed at a whim without Microsoft breaking with the standards. If any competition gains ground they can change their implementation to break compatiblity yet still be considered standards compliant. This promotes further [lock-in] to Microsoft. Those choosing to use Microsoft's implementation of .NET will likely find that in the [future] they will not be able to migrate their software to another .NET compliant platform.

As for [standards] created outside of Microsoft, .NET still ignores many, choosing to re-implement its own methods instead. .NET's HTML output isn't HTML compliant. The Avalon user interface API could have used standards such as SVG, bringing along many advantages for all, but it's also proprietary, possibly to continue the policy of developer lock-in.

Bloat

Visual Studio® .NET™ 2003 Enterprise Architect takes up about 1.5 Gb of hard disk space, not including documentation (MSDN) or a modern version control system. It seems to be a rediculously oversized suite of applications. The installation routine can take 20 minutes just to perform the step "Creating installation script." After a few hours of waiting for the 16 CDs to install you can count on over 100 Mb of RAM being used to run the integrated development environment (IDE). It appears Visual Studio is created with disregard to any limit of system resources.

Not only is the development environment excessively large, but the APIs and object models of .NET are very cumbersome and complicated as well, causing bloat for all subsequent applications. For example, simple items such as the Button class are very far down the inheritance chain of the Avalon GUI API.

Microsoft ASP.NET Vs. PHP and LAMP

PHP is a very popular HTML-embedded scripting language designed for rapid web development. The syntax is similar to C and Java. PHP is relatively mature, has complete online documentation, and has a very active online community.

PHP 4 and 5 are more efficient and faster than ASP.NET due to less overhead and less platform code to execute. ASP.NET pages compile, as opposed to running directly as scripts, but are on top of a large runtime environment. As with the rest of .NET the developer is forced to use an object oriented design, creating extra code for simple applications. With PHP object oriented development is optional and new OO features are added with each major release.

PHP is free and available for Windows, Unix, and Linux with the Apache and IIS web servers (and possibly others). Microsoft's ASP.NET is free, but has the platform costs of Windows and security weakness of IIS. PHP is also [open source], bringing many other benefits. Combined with other open source software, the Linux-Apache-MySQL-PHP (LAMP) platform is a very scalable and flexible system on par or better than .NET for most situations.

See also:

Hull, Sean. "PHP and ASP.NET Go Head-to-Head." Oracle Technology Network 2004 (Note Oracle is a direct competitor to Microsoft in the database server market)

Microsoft ASP.NET Vs. Sun J2EE

One major selling point of Java™ has been portability. Java applications are supposed to run on any platform for which a runtime (JVM) exists. On top of that exists a certification called the Java 2 Enterprise Edition (J2EE). Any application written for J2EE is in theory portable across any J2EE certified server. To retain portability the application must be written solely to the J2EE specifications without use of any vendor extensions. As J2EE is becoming a mature platform the need to use non-standard extensions is dying. J2EE servers exist for all operating systems supporting Java, currently various flavors of Unix, Linux, Windows, and Mac OS X.

As with Microsoft ASP.NET, J2EE provides developers with an object oriented framework for web development. J2EE also provides methods for created client applications which are richer than HTML pages and still accessible through web browsers. Just as .NET was based on Java, ASP.NET is almost identical to J2EE for web development except it's lacking the years of maturity and support from developers outside Sun Microsystems. Java has had a large head start and therefore applications and supplemental libraries from a wider array of vendors are available.

While Microsoft and possibly the Mono project are the only sources of ASP.NET servers, J2EE certified servers are available from BEA, IBM, the JBoss Group, and others. Development environments are available from Sun, BEA, IBM, Borland, Eclipse, and others.

When choosing a software platform for all things web services, the choices which first come to mind are usually Java and .NET. Java's web services features are defined in the Java 2 Enterprise Edition (J2EE) standard and have been in use for years. The primary reason .NET is recognized as a viable option (in general) is due to the fact it's a child of Microsoft, a platform onto which they are migrating all of their software and betting their future. The promise of using the J2EE standard is multiple hardware and software choices from multiple vendors. As of now .NET is still a proprietary system of Microsoft. Choosing among the J2EE industry leader IBM and formidable competition, such as JBoss.org, provides leverage for customers to bargain for services and prices. .NET, for the forseable [future], leaves you with one vendor option. [Open source] competition, such as Mono and DotGNU, will continue to lag far behind in features. Based on past experience, Microsoft can not be trusted to stick with industry [standards] and remain compatible with these alternatives. Therefore the only logical choice between Java and .NET for web services is simple: Java. Developers and companies choosing .NET are limiting their current choices, their future options, and their ability to expand. A commentary on ZDNet supplements this opinion quite well.