|
|
Surely the most spectacular method to develop and execute logon procedures on Windows Server 2003 is by using the .NET Common Language Runtime. The .NET Framework can be used as a replacement or supplement for Windows Script Host and batch-processing scripts. So how does this work? So far, we have looked at the .NET Framework as a development platform for ASP.NET Web Forms, XML Web Services, and .NET Windows Forms applications. (See Chapter 5.) And how do the previously described script concepts fit into the picture? The answer is very simple: Executing a .NET Framework application using the command prompt is a special variant of a .NET Windows Forms application. .NET Windows Forms applications have their own namespaces in the .NET Class Library. This type of program is named Console Application and has a number of advantages over scripts:
A .NET Console Application is compiled and thus offers advantages of speed over an interpreted script.
The program logic is embedded in a compiled executable and thus helps to protect the developer’s intellectual properties.
It is not easy to change a .NET Console Application without a lot of effort if the source code is unavailable.
How is a console application for Windows Server 2003 created that can be used as logon procedure? Don’t we need a development environment like Microsoft Visual Studio .NET? Naturally, Visual Studio .NET is the preferred development tool for this purpose, but the .NET Framework SDK will work, too.
The .NET Framework SDK can be downloaded for free in different languages from the Microsoft Web site on the Internet. The .NET Framework SDK contains compilers, debugger, help tools, libraries, examples, and a comprehensive documentation—thus, a complete development environment. Installing the .NET Framework SDK is very easy and does not even require selecting a target folder. It does not need to be installed on all target platforms; one development platform is sufficient. The .NET Common Language Runtime for executing the development results is automatically included in each installation of Windows Server 2003.
| Tip |
When you install the .NET Framework SDK, you might receive a message telling you that Microsoft Internet Information Services has not been installed. Just confirm the message with Next. You don’t need the Internet Information Services because you want to develop a console application, not ASP.NET Web Forms. |
Listing 7-13 shows the simplest example of a console application written in Visual Basic .NET. And how do you develop a simple .NET console application? First of all, you need to enter the source code—for example, with the Notepad editor. The most difficult decision is which programming language to use. Options primarily include Visual Basic .NET and C#. Visual Basic .NET is easier for administrators who have some experience with Visual Basic. C#, however, is more appealing to C, C++, and Java programmers. The only difference between the two languages is their syntax. They use the exact same .NET library classes.
 |
Class ConsoleApplication
Shared Sub main()
System.Console.WriteLine(".NET Console Application")
End Sub
End Class
|
Listing 7-14 shows the same simple console application written in C#:
|
Class ConsoleApplication {
Static void Main() {
System.Console.WriteLine(".NET Console Application")
}
}
|
The .NET class library is quite extensive. For this reason, it is not easy in the beginning to gain an overview of the classes that are available. Fortunately, the .NET Framework comes with an excellent documentation, including help files and examples in SDK.
How can a sample application be compiled from source code to an executable program? The command-line compilers handle this task: Vbc.exe for Visual Basic .NET and Csc.exe for C#. In its simplest form, the compiler needs only the name of the source code as an argument. The classes used are included from the Mscorlib.dll default library. The compiler command line at the command prompt looks like this:
Vbc vbConsole.vb
If required classes are located in other library files, they can be referenced through additional compiler arguments. It is also possible to select an alternative output file name if you do not want the file name of the source code to be the name of the executable program. All these options can easily be determined by entering Vbc /? or Csc /?.
A compiled .NET console application is saved in an executable file that can be copied to any platform with the .NET runtime environment. So if you copy the console application to Windows Server 2003 with Terminal Services activated, you can call it up from a script during logon. This might look like this:
|
@echo off echo Calling a .NET Console Application ConsoleApp.exe
|
| Tip |
It is, of course, also possible to reference the .NET console application in a suitable key in the registry to be automatically executed when certain system events occur. (See also Chapter 6.) |
Now that we have laid the foundation for developing a .NET console application, we will briefly look at the namespaces and classes that are relevant for terminal servers.
|
Class |
Description |
|---|---|
|
System.IO.Directory |
Provides static methods for creating, moving, and listing files in folders and subfolders. |
|
System.IO.File |
Provides static methods for creating, copying, deleting, moving, and opening files. This class also supports creating FileStream objects. |
|
System.IO.FileStream |
Allows synchronous and asynchronous read and write processes for files. |
|
Microsoft.Win32.Registry |
Supplies the basic registry keys that access values and subkeys in the registry. |
|
Microsoft.Win32.RegistryKey |
Provides a registry node at the key level. This class represents an encapsulation of the registry. |
It would go beyond the scope of this book to describe the possibilities .NET console applications offer. Therefore, I would like to refer you to Charles Petzold’s book, Programming Microsoft Windows with C# (Microsoft Press, 2002). He describes in detail many of the concepts touched on only briefly here, and much more.
|
|