Real World Computing
Starting .Net
The installation program for the .NET Framework and the SDK writes an information event log entry to the computer's Application Log after completing the installation. For a successful installation, this entry's Source will be MsiInstaller and the Event ID will be 11707. Note that this is a generic MSI Installer success event, and you'll need to look at the Event Description to check that it was indeed the Framework or the SDK that was installed. Similar event log entries are written by MSI if you remove these packages, the event ID then being 11724.
If you plan to install either or both of these packages using a Software Distribution Group Policy object, first extract the relevant MSIs using the /T and /C switches to a temporary folder. DOTNETFX.EXE expands into INSTALL.EXE, INSTMSI.EDE, INSTMSIW.EXE, NETFX.MSI and NETFX1.CAB and, in most cases, you'll need to deploy the last two of these.
Most serious developers are probably going to want Visual Studio on their computers. While you *don't * have to buy and use Visual Studio to create .NET applications, it is pretty much the best development tool in the business, and it really does contribute a lot to developer productivity. But it's not free.
The .NET Frameworks ships with both C# and VB.NET command-line compilers, which means you could use Notepad (or your favourite programmer's editor) to create your source and then compile it using the command-line compiler CSC.EXE or VBC.EXE. In future articles, I'll be looking a bit deeper at the built-in development tools in the SDK and framework, and some of the examples in this column are ones you can compile using these tools.
When you compile some .NET source code, the compiler produces output similar to that from a conventional compiler: you can compile to either a DLL or to an executable. In Figure 2, you can see the results of compiling and running the following simple 'Hello World' program written in C #:
using System;
public class HelloWorld
{
public static void Main()
{
Console.WriteLine("Hello World");
}
}
This is a simple .NET program that just displays the traditional greeting on the command line. Figure 2 shows the source file HELLO.CS and the compiled output HELLO.EXE. If you can compile this source file and run the program, you've got the .NET Framework loaded. A question I often get asked is whether administrators really need to be able to write code, and I answer that these days it certainly helps - with lower-level API tools like WMI and ADSI, being able to write scripts in C# or VB.NET (or any other .NET Language for that matter) is very useful.
One thing to remember: the Framework and SDK tool folders aren't automatically added to your Path statement, so you'll need to deal with this - adjust the Path variable from the Environment Variable dialog in System Properties.
So What's The Big Deal?
The HELLO.EXE in Figure 2 doesn't look anything special, just like any old unmanaged application, so what's the big difference? We need know a bit more about how .NET programs run. In the .NET world, the output of the compiler is known as an Assembly, which contains a Manifest (metadata about the assembly), the MS Intermediate Language code representing the application itself, and optionally any resources that the application might need, such as a bit map or font. As explained above, .NET language compilers emit an intermediate language (MSIL) rather than native machine code that can be directly executed as a conventional C compiler does. This MSIL gets compiled at runtime by the JIT compiler (or Jitter) into machine code executable by the target computer's CPU. The assembly's manifest contains details like what classes are defined in it, and their detailed module identifiers. This metadata, also known as evidence, can be used at runtime - by the security subsystem, for example, to enforce code access security.
