Developing with Microsoft .NET

Developers building applications with the Microsoft .NET platform are no doubt aware that a CLR (Common Language Runtime) is necessary in order for the .NET bytecode to execute.

In essence, C# and VB.NET produce a intermediate representation of a computer program that requires an interpreter to run. One of the great benefits here is that the same program can run on Windows using the Microsoft .NET framework, and when it is copied to UNIX the Mono runtime can interpret it there. The only source of contention is the reliance on poorly defined platform dependent libraries, such as the Windows.Forms that use the native Win32 API’s to render windows onscreen.

Unfortunately, Microsoft chose to produce output that purports to be executable when in fact the resulting code must use a CLR to be interpreted. This has happened because the final program is given a .EXE file extension and some header information is prefixed to the bytecode output that makes it look very much executable.

Imagine if Java produced .EXE files instead of .CLASS files… how confusing would that be! Joel Spolsky questions why Microsoft fails to include a linker in MS .NET, if the output is suppose to be an executable then it would seem logical that a developer should be able to link the resulting executable to have it run without a CLR.

The simplicity of the Java solution is elegant, when examining a file with a .class extension it is immediately apparent that this requires another program to run. Developers familiar with the JVM will be further able to recognize that a Java runtime is required and will be able to take appropriate steps.

On the other hand, Microsoft .NET developers will not be able to recognize that a file with a ubiquitous EXE extension may also require a runtime. You would think that Microsoft would have learned a lesson from the awkward Visual Basic runtimes (VBRUNxxx.DLL) that caused untoward compatibility issues. At least a linker can tell you what DLL files your dynamically linked application depends on, the .NET platform should be taking advantage of similar functions to inform the user what version of the CLR they should be running. More importantly, the user should not be presented with a non-executable executable.

What is even more unfortunate is that without using the resource fork available in NT filesystems, a developer cannot even rename their output (eg: PROGRAM.EXE to PROGRAM.NET) without rendering it unusable. There is clearly a lot of work left to be done with MS .NET, maybe in a few years it will be on par with other bytecode interpreted languages like Java.