Fewer Crashes

Code that runs on a .NET platform is less likely to crash, and it is virtually impossible for managed code to take down the system or affect other applications.

This is due to two factors:

1. .NET restricts what applications can do, what they can access, and how they manage memory.
2. .NET forces developers to use modern languages with modern programming practices. .NET forces developers to abandon old habits and techniques designed for computer systems of the 1970's era.

C++ developers are also quick to reply that �Modern C++ has warnings for X and Y, or compiler option Z can prevent that.�. The problem with warnings is that C++ issues so many warnings, and C++ developers often want to override them anyways that on each compile, a C++ program issues hundreds if not thousands of such warnings. Finding the important ones is not a quick or easy task. Compiler options are problematic too. Since C++ developers are typically speed freaks, nearly all such safeguards are turned off in releases, no matter if the code runs sufficiently fast or not. Since release code is used by a much larger user audience, the releases encounter situations never encountered in the debug releases and simply crash. .NET forces these checks to always be on, providing for better applications by properly handling exceptions instead of merely corrupting memory or other.

Debunking Myths

.NET has invoked fear in the minds of many developers. Some of the fears are based on facts but surrounded by misunderstandings, while others are based on pure misinformation, and in some cases, even religious beliefs. Let's examine a few of the more common ones with a logical approach.

• .NET has a Big Runtime.

.NET has a 20 megabyte runtime. That's too big for a normal application.

First of all it is not a run time library. The .NET framework is a complete platform similar to how Win32, DOS, Unix, and Java are platforms. Currently, .NET runs on top of Windows and thus must be installed.

The install for the 1.1 version of the .NET framework is approximately 20 megabytes. However, the Windows XP Service Pack 1 CDs include this runtime as part of their installation, and many users already have the framework installed. In the future, the .NET framework will gain wider and wider acceptance just as other Microsoft components have such as DirectX, etc. Most games rely on DirectX installation and install it without trouble or complaints of a run time.

Future versions of the Windows operating system will ship with the .NET framework installed as part of the native operating system.

20 megabytes is also not a very large distribution in the scheme of things. Most software are several megabytes or even larger. The .NET runtime only needs to be installed by those users who do not already have it, and thus is optional. Adding a 20 megabyte install to a CD distribution and installing if needed will not negatively impact deployment.

20 megabytes is more measurable in the world of electronic downloads. However, electronic downloads over the Internet are normally performed by technical savvy users who likely already have the framework installed, or have a DSL or better Internet connection.

The 20 megabytes also refers to the complete framework. When your application loads, it will not link to a 20 megabyte runtime that loads into memory, just as a standard Win32 application today does not load 200 megabytes of Windows support for each run.

• .NET is Slow.

Some .NET applications do in fact run slower. Compression and encryption routines are one example that often run slower. Such functions should be written using unmanaged code anyways because of the security implications and need to directly manipulate structures in specific ways that encryption requires.

However, such applications occupy a very small minority of the average development need. Most developers are developing either server side objects, or desktop applications. Such tasks when written properly will execute just as fast in Win32, or faster.

Faster? Yes faster. This is because the .NET framework implements and provides so many more services than what a Win32 application has available to it, and also because of how IL code is actually optimized and executed.

But I ported my application and it's 100 times slower!

That's a very common scenario. Many applications when ported do run 100 times or more slower than the original Win32 application. But I said they should run faster, right? So, how is this that so many applications run slower after porting?

The answer is simple - the applications were ported, but the design remained the same. That is, a straight port was performed without using the new techniques in development.

It's certainly possible to take a large engine from a 1960's hot rod and put it into a modern car and make it run. However, powering it on unleaded fuel, and integrating it in with the car system and bodies designed 40 years later will not yield the expected results. When porting to .NET, you need to take into account that it works differently in several key areas.

Do you have to redesign your application from the ground up? No. But you should look at some key areas and consider altering them to operate under the new paradigms so that they will run properly, and efficiently.