Nbsp;   Building Types into a Module

In this section, I’ll show you how to turn your source file, containing various types, into a file that can

be deployed. Let’s start by examining the following simple application.

public sealed class Program { public static void Main() {

System.Console.WriteLine("Hi");

}

}

This application defines a type, called Program. This type has a single public, static method called Main. Inside Main is a reference to another type called System.Console. System.Console is a type implemented by Microsoft, and the Intermediate Language (IL) code that implements this type’s meth- ods is in the MSCorLib.dll file. So our application defines a type and also uses another company’s type.

To build this sample application, put the preceding code into a source code file, say, Program.cs,

and then execute the following command line.

csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs

This command line tells the C# compiler to emit an executable file called Program.exe

(/out:Program.exe). The type of file produced is a Win32 console application (/t[arget]:exe).

When the C# compiler processes the source file, it sees that the code references the System.Console type’s WriteLine method. At this point, the compiler wants to ensure that this type exists somewhere, that it has a WriteLine method, and that the argument being passed to this method matches the parameter the method expects. Because this type is not defined in the C# source code, to make the C# compiler happy, you must give it a set of as- semblies that it can use to resolve references to external types. In the preceding command line, I’ve included the /r[eference]:MSCorLib.dll switch, which tells the compiler to look for external types in the assembly identified by the MSCorLib.dll file.

MSCorLib.dll is a special file in that it contains all the core types: Byte, Char, String, Int32, and many more. In fact, these types are so frequently used that the C# compiler automatically references the MSCorLib.dll assembly. In other words, the following command line (with the /r switch omitted) gives the same results as the line shown earlier.

csc.exe /out:Program.exe /t:exe Program.cs

Furthermore, because the /out:Program.exe and the /t:exe command-line switches also match what the C# compiler would choose as defaults, the following command line gives the same results too.

csc.exe Program.cs

If, for some reason, you really don’t want the C# compiler to reference the MSCorLib.dll assembly, you can use the /nostdlib switch. Microsoft uses this switch when building the MSCorLib.dll assem- bly itself. For example, the following command line will generate an error when CSC.exe attempts to compile the Program.cs file because the System.Console type is defined in MSCorLib.dll.

csc.exe /out:Program.exe /t:exe /nostdlib Program.cs

Now, let’s take a closer look at the Program.exe file produced by the C# compiler. What exactly is this file? Well, for starters, it is a standard portable executable (PE) file. This means that a machine running 32-bit or 64-bit versions of Windows should be able to load this file and do something with it. Windows supports three types of applications. To build a console user interface (CUI) applica- tion, specify the /t:exe switch; to build a graphical user interface (GUI) application, specify the

/t:winexe switch; and to build a Windows Store app, specify the /t:appcontainerexe switch.

Response Files

Before leaving the discussion about compiler switches, I’d like to spend a moment talking about response files. A response file is a text file that contains a set of compiler command-line switches. When you execute CSC.exe, the compiler opens response files and uses any switches that are speci- fied in them as though the switches were passed to CSC.exe on the command line. You instruct the compiler to use a response file by specifying its name on the command line prepended by an @ sign. For example, you could have a response file called MyProject.rsp that contains the following text.

/out:MyProject.exe

/target:winexe

To cause CSC.exe to use these settings, you’d invoke it as follows.

csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs

This tells the C# compiler what to name the output file and what kind of target to create. As you can see, response files are very convenient because you don’t have to manually express the desired command-line arguments each time you want to compile your project.

The C# compiler supports multiple response files. In addition to the files you explicitly specify on the command line, the compiler automatically looks for files called CSC.rsp. When you run CSC.exe, it looks in the directory containing the CSC.exe file for a global CSC.rsp file. Settings that you want applied to all of your projects should go in this file. The compiler aggregates and uses the settings in all of these response files. If you have conflicting settings in the local and global response files, the settings in the local file override the settings in the global file. Likewise, any settings explicitly passed on the command line override the settings taken from a local response file.

When you install the .NET Framework, it installs a default global CSC.rsp file in the %SystemRoot%\ Microsoft.NET\Framework(64)\vX.X.X directory (where X.X.X is the version of the .NET Framework you have installed). The latest version of this file contains the following switches.

# This file contains command­line options that the C#

# command line compiler (CSC) will process as part

# of every compilation, unless the "/noconfig" option

# is specified.

# Reference the common Framework libraries

/r:Accessibility.dll

/r:Microsoft.CSharp.dll

/r:System.Configuration.dll

/r:System.Configuration.Install.dll

/r:System.Core.dll

/r:System.Data.dll

/r:System.Data.DataSetExtensions.dll

/r:System.Data.Linq.dll

/r:System.Data.OracleClient.dll

/r:System.Deployment.dll

/r:System.Design.dll

/r:System.DirectoryServices.dll

/r:System.dll

/r:System.Drawing.Design.dll

/r:System.Drawing.dll

/r:System.EnterpriseServices.dll

/r:System.Management.dll

/r:System.Messaging.dll

/r:System.Runtime.Remoting.dll

/r:System.Runtime.Serialization.dll

/r:System.Runtime.Serialization.Formatters.Soap.dll

/r:System.Security.dll

/r:System.ServiceModel.dll

/r:System.ServiceModel.Web.dll

/r:System.ServiceProcess.dll

/r:System.Transactions.dll

/r:System.Web.dll

/r:System.Web.Extensions.Design.dll

/r:System.Web.Extensions.dll

/r:System.Web.Mobile.dll

/r:System.Web.RegularExpressions.dll

/r:System.Web.Services.dll

/r:System.Windows.Forms.Dll

/r:System.Workflow.Activities.dll

/r:System.Workflow.ComponentModel.dll

/r:System.Workflow.Runtime.dll

/r:System.Xml.dll

/r:System.Xml.Linq.dll

Because the global CSC.rsp file references all of the assemblies listed, you do not need to explicitly reference these assemblies by using the C# compiler’s /reference switch. This response file is a big convenience for developers because it allows them to use types and namespaces defined in various Microsoft-published assemblies without having to specify a /reference compiler switch for each when compiling.

Referencing all of these assemblies could slow the compiler down a bit. But if your source code doesn’t refer to a type or member defined by any of these assemblies, there is no impact to the re- sulting assembly file, nor to run-time execution performance.

Of course, you’re welcome to add your own switches to the global CSC.rsp file if you want to make your life even easier, but this makes it more difficult to replicate the build environment on different machines—you have to remember to update the CSC.rsp the same way on each build machine. Also, you can tell the compiler to ignore both local and global CSC.rsp files by specifying the /noconfig command-line switch.

Date: 2016-03-03; view: 627