To program in C#, you’re going to need a way to build C# programs. You can do this with a command-line compiler, VS .NET, or a C# package for a programming editor.
1. The Command-Line Compiler
The simplest way to get started writing C# code is by using the .NET runtime and Framework’s SDK. The SDK contains the .NET runtime and Framework and compilers for C#, Visual Basic .NET, the Managed Extensions to C++, and JScript .NET. You can download the framework from the following site:
http://msdn.microsoft.com/netframework/
Using the SDK is easy; write your code in an editor, compile it using csc, and then run it. But easy doesn’t necessarily mean productive, however. When writing with just the SDK, you’ll spend a lot of time looking at documentation and trying to figure out simple errors in your code. You can find details about using the command-line compiler in Chapter 41.
2. Visual Studio .NET
Visual Studio .NET provides a lull environment to make programming in C# easy and fun. Visual Studio versions are bound to framework versions, with Visual Studio .NET 2002 targeting .NET 1.0, Visual Studio .NET 2003 targeting .NET 1.1, and Visual Studio .NET 2005 targeting .NET 2.0.
Visual Studio .NET provides some real help for the developer.
2.1. The Editor
The most important feature of the Visual Studio .NET editor is the IntelliSense support. One of the challenges of learning C# and the .NET Framework is simply finding your way around the syntax of the language and object model of the .NET Framework. Autocompletion will help greatly in finding the proper method to use, and syntax checking will highlight the sections of code with errors.
2.2. The Form Designer
Both Windows Forms applications and Web Forms applications are written directly in code, without separate resource files, so it’s possible to write either application without Visual Studio .NET.
Doing layout and setting properties by hand isn’t very fun, however, so Visual Studio provides a Form Designer that makes it easy to add controls to a form, set the properties on the form, create event handlers, and so on.
The form editing is two ways; changes made in the Form Designer show up in the form code, and changes made in the form code show up in the designer.
2.3. The Project System
The project system provides support for creating and building projects. There are predefined templates for most types of projects (Windows Forms, Web Forms, Console Application, Class Library, and so on).
The project system also provides support for deploying applications.
2.4. Class View
While the project system provides a view of the files in a project, Class View provides a view into the classes and other types in a project. Rather than writing the syntax for a property directly, for example, Class View provides a wizard to do it for you.
2.5. The Object Browser
The Object Browser provides the same sort of view that Class View does, but instead of looking at the code in the current project, it lets you browse the components in other assemblies that the project is using. If the documentation for a class is incomplete, the Object Browser can show the interface of the class as defined by the metadata for the component.
2.6. The Debugger
The debugger in Visual Studio .NET has been enhanced to provide cross-language debugging facilities. It’s possible to debug from one language to the other, and it’s also possible to debug code executing remotely on another machine.
3. Other Tools of Note
The SDK comes with a number of utility programs, which are detailed in the .NET Framework Tools section of the documentation.
3.1. ILDASM
IL Disassembler (ILDASM) is the most useful tool in the SDK. It can open an assembly, show all the types in the assembly, show what methods are defined for those types, and show the IL that was generated for that method.
This is useful in a number of ways. Like the Object Browser, it can be used to find out what’s present in an assembly, but it can also be used to find out how a specific method is implemented. You can use this capability to answer some questions about C#.
If, for example, you want to know whether C# will concatenate constant strings at compile time, it’s easy to test. First, create a short program:
using System; class Test {
public static void Main()
{
Console.WriteLine(“Hello ” + “World”);
}
}
Second, after the program is compiled, use ILDASM to view the IL for Main():
.method public hidebysig static void Main() cil managed {
.entrypoint
// Code size 11 (0xb)
.maxstack 8
IL_0000: ldstr “Hello World”
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Test::Main
Even without knowing the details of IL, it’s pretty clear that the two strings are concatenated into a single string.
You can find the details of IL in ILinstrset.doc, which is in the SDK install folder, which is a subfolder of the main Visual Studio install folder.
You can use ILDASM on any assembly, which raises some questions over intellectual property. Although having code stored in IL makes disassemblers easier to write, it does create an issue that didn’t exist before: x86 assembly language can also be disassembled and decoded. Various obfuscators exist to address this issue, and an entry-level obfuscator ships with some versions of Visual Studio. Check the Visual Studio Web site for the exact details.
3.2. NGEN
NGEN is a tool that compiles the MSIL code to native code when NGEN is executed. This is different from the standard .NET loading model where conversion to native code happens Just-in-Time (JIT) when the .NET assembly is loaded.
At first glance, this seems like a way to get around many of the disadvantages of the JIT approach; simply PreJIT the code, and then performance will be better and nobody will be able to decode the IL.
Unfortunately, things don’t work that way. PreJIT is only a way to store the results of the compilation, but the metadata is still required to do class layout and support reflection. Further, the generated native code is valid only for a specific environment, and if configuration settings (such as the machine security policy) change, the runtime will switch back to the normal JIT.
Although PreJIT does eliminate the overhead of the JIT process, it also produces code that runs slightly slower because it requires a level of indirection that isn’t required with the normal JIT.
So, the real benefit of PreJIT is to reduce the JIT overhead (and therefore the startup time) of a client application, and it isn’t really terribly useful elsewhere.
.NET 2.0 fixes the problem of needing to load two physical DLLs for each PreJITed assembly and also introduces more optimizations during the PreJIT phase. For developers who tried and rejected NGEN in .NET 1.x, it’s worth reevaluating for .NET 2.0.
Source: Gunnerson Eric, Wienholt Nick (2005), A Programmer’s Introduction to C# 2.0, Apress; 3rd edition.