Building, Packaging, Deploying, and Administering Applications and Types
If, for some reason, you really don’t want the C# compiler to reference the MSCorLib.dll assembly, you can use the /nostdlibswitch.
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs
To build a console user interface (CUI) application, specify the /t:exeswitch; to build a graphical user interface (GUI) application, specify the /t:winexeswitch; and to build a Windows Store app, specify the /t:appcontainerexeswitch.
Response Files
A response file is a text file that contains a set of compiler command-line switches.
Whenyou use the /referencecompiler switch to reference an assembly, you can specify a complete path to a particular file. However, if you do not specify a path, the compiler will search for the file in the following places (in the order listed):
■ Working directory.
■ The directory that contains the CSC.exe file itself. MSCorLib.dll is always obtained from this directory. The path looks something like this: %SystemRoot%\Microsoft.NET\Framework\v4.0.#####.
■ Any directories specified using the /libcompiler switch.
■ Any directories specified using the LIBenvironment variable.
Also, you can tell the compiler to ignore both local and global CSC.rsp files by specifying the /noconfig command-line switch.
A Brief Look at Metadata
Nowwe know what kind of PE file we’ve created. But what exactly is in the Program.exe file? A managed PE file has four main parts: the PE32(+) header, the CLR header, the metadata, and the IL. The PE32(+) header is the standard information that Windows expects. The CLR header is a small block of information that is specific to modules that require the CLR (managed modules). The header includes the major and minor version number of the CLR that the module was built for: some flags,a MethodDeftoken (described later) indicating the module’s entry point method if this module is a CUI, GUI, or Windows Store executable, and an optional strong-name digital signature (discussed in Chapter 3). Finally, the header contains the size and offsets of certain metadata tables contained within the module. You can see the exact format of the CLR header by examining the IMAGE_COR20_HEADER
defined in the CorHdr.h header file.
Themetadata is a block of binary data that consists of several tables. There are three categories of tables: definition tables, reference tables, and manifest tables. Table 2-1 describes some of the more common definition tables that exist in a module’s metadata block.
The metadata created includes a set of reference tables that keep a record of the referenced items.
ILDasm Program.exe
Combining Modules to Form an Assembly
The manifest is another set of metadata tables that basically contain the names of the files that are part of the assembly. They also describe the assembly’s version, culture, publisher, publicly exported types, and all of the files that comprise the assembly.
The CLR operates on assemblies; that is, the CLR always loads the file that contains the manifest metadata tables first and then uses the manifest to get the names of the other files that are in the assembly.Here are some characteristics of assemblies that you should remember:
■ An assembly defines the reusable types.
■ An assembly is marked with a version number.
■ An assembly can have security information associated with it.
An assembly’s individual files don’t have these attributes—except for the file that contains the manifest metadata tables.
To build an assembly, you must select one of your PE files to be the keeper of the manifest. Or you can create a separate PE file that contains nothing but the manifest.
he C# compiler produces an assembly when you specify any of the following command-line switches: /t[arget]:exe, /t[arget]:winexe, /t[arget]: appcontainerexe, /t[arget]:library, or /t[arget]:winmdobj.
In addition to these switches, the C# compiler supports the /t[arget]:moduleswitch. This switch tells the compiler to produce a PE file that doesn’t contain the manifest metadata tables. The PE file produced is always a DLL PE file, and this file must be added to an assembly before the CLR can access any types within it. When you use the /t:moduleswitch, the C# compiler, by default, names the output file with an extension of .netmodule.
Unfortunately, the Microsoft Visual Studio integrated development environment (IDE) doesn’t natively support the ability for you to create multifile assemblies. If you want to create multifile assemblies, you must resort to using command-line tools.
Thereare many ways to add a module to an assembly. If you’re using the C# compiler to build a PE file with a manifest, you can use the /addmoduleswitch.
csc /out:MultiFileLibrary.dll /t:library /addmodule:RUT.netmodule FUT.cs
Using the Assembly Linker
csc /t:module RUT.cs
csc /t:module FUT.cs
al /out: MultiFileLibrary.dll /t:library FUT.netmodule RUT.netmodule
csc /t:module /r:MultiFileLibrary.dll Program.cs
al /out:Program.exe /t:exe /main:Program.Main Program.netmodule
Adding Resource Files to an Assembly
AL.exe /embed[resource]switch /link[resource]switch
CSC.exe /resourceswitch /linkresourceswitch
One last note about resources: it’s possible to embed standard Win32 resources into an assembly. You can do this easily by specifying the path of a .res file with the /win32resswitch when using either AL.exe or CSC.exe.
In addition, you can quickly and easily embed a standard Win32 icon resource into an assembly file by specifying the path of the .ico file with the /win32iconswitch when using either AL.exe or CSC.exe.
Assembly Version Resource Information
Version Numbers
AssemblyFileVersion
This version number is stored in the Win32 version resource.This number is for information purposes only; the CLR doesn’t examine this version number in any way.
AssemblyInformationalVersion.
This version number is also stored in the Win32 version resource, and again, this number is for information purposes only; the CLR doesn’t examine or care about it in any way. This version number exists to indicate the version of the product that includes this assembly.
AssemblyVersion
This version number is stored in the AssemblyDef manifest metadata table. The CLR uses this version number when binding to strongly named assemblies (discussed in Chapter 3). This number is extremely important and is used to uniquely identify an assembly.
Culture
Assemblies that are marked with a culture are called satellite assemblies.
You’ll usually use the AL.exe tool to build a satellite assembly. You won’t use a compiler because the satellite assembly should have no code contained within it.
When using AL.exe, you specify the desired culture by using the /c[ulture]:textswitch, where textis a string such as “en-US,” representing US English. When you deploy a satellite assembly, you should place it in a subdirectory whose name matches the culture text. For example, if the application’s base directory is C:\MyApp, the US English satellite assembly should be placed in the C:\MyApp\en-US subdirectory. At run time, you access a satellite assembly’s resources by using the System.Resources.ResourceManagerclass.
Simple Application Deployment (Privately Deployed Assemblies)
Simple Administrative Control (Configuration)
AppDir directory (contains the application’s assembly files)
Program.exe
Program.exe.config (discussed below)
AuxFiles subdirectory (contains MultiFileLibrary’s assembly files)
MultiFileLibrary.dll
FUT.netmodule
RUT.netmodule
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemasmicrosoftcom:asm.v1">
<probing privatePath="AuxFiles" />
</assemblyBinding>
</runtime>
</configuration>
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs
To build a console user interface (CUI) application, specify the /t:exeswitch; to build a graphical user interface (GUI) application, specify the /t:winexeswitch; and to build a Windows Store app, specify the /t:appcontainerexeswitch.
Response Files
A response file is a text file that contains a set of compiler command-line switches.
Whenyou use the /referencecompiler switch to reference an assembly, you can specify a complete path to a particular file. However, if you do not specify a path, the compiler will search for the file in the following places (in the order listed):
■ Working directory.
■ The directory that contains the CSC.exe file itself. MSCorLib.dll is always obtained from this directory. The path looks something like this: %SystemRoot%\Microsoft.NET\Framework\v4.0.#####.
■ Any directories specified using the /libcompiler switch.
■ Any directories specified using the LIBenvironment variable.
Also, you can tell the compiler to ignore both local and global CSC.rsp files by specifying the /noconfig command-line switch.
A Brief Look at Metadata
Nowwe know what kind of PE file we’ve created. But what exactly is in the Program.exe file? A managed PE file has four main parts: the PE32(+) header, the CLR header, the metadata, and the IL. The PE32(+) header is the standard information that Windows expects. The CLR header is a small block of information that is specific to modules that require the CLR (managed modules). The header includes the major and minor version number of the CLR that the module was built for: some flags,a MethodDeftoken (described later) indicating the module’s entry point method if this module is a CUI, GUI, or Windows Store executable, and an optional strong-name digital signature (discussed in Chapter 3). Finally, the header contains the size and offsets of certain metadata tables contained within the module. You can see the exact format of the CLR header by examining the IMAGE_COR20_HEADER
defined in the CorHdr.h header file.
Themetadata is a block of binary data that consists of several tables. There are three categories of tables: definition tables, reference tables, and manifest tables. Table 2-1 describes some of the more common definition tables that exist in a module’s metadata block.
The metadata created includes a set of reference tables that keep a record of the referenced items.
ILDasm Program.exe
Combining Modules to Form an Assembly
The manifest is another set of metadata tables that basically contain the names of the files that are part of the assembly. They also describe the assembly’s version, culture, publisher, publicly exported types, and all of the files that comprise the assembly.
The CLR operates on assemblies; that is, the CLR always loads the file that contains the manifest metadata tables first and then uses the manifest to get the names of the other files that are in the assembly.Here are some characteristics of assemblies that you should remember:
■ An assembly defines the reusable types.
■ An assembly is marked with a version number.
■ An assembly can have security information associated with it.
An assembly’s individual files don’t have these attributes—except for the file that contains the manifest metadata tables.
To build an assembly, you must select one of your PE files to be the keeper of the manifest. Or you can create a separate PE file that contains nothing but the manifest.
In addition to these switches, the C# compiler supports the /t[arget]:moduleswitch. This switch tells the compiler to produce a PE file that doesn’t contain the manifest metadata tables. The PE file produced is always a DLL PE file, and this file must be added to an assembly before the CLR can access any types within it. When you use the /t:moduleswitch, the C# compiler, by default, names the output file with an extension of .netmodule.
Unfortunately, the Microsoft Visual Studio integrated development environment (IDE) doesn’t natively support the ability for you to create multifile assemblies. If you want to create multifile assemblies, you must resort to using command-line tools.
Thereare many ways to add a module to an assembly. If you’re using the C# compiler to build a PE file with a manifest, you can use the /addmoduleswitch.
csc /out:MultiFileLibrary.dll /t:library /addmodule:RUT.netmodule FUT.cs
Using the Assembly Linker
csc /t:module RUT.cs
csc /t:module FUT.cs
al /out: MultiFileLibrary.dll /t:library FUT.netmodule RUT.netmodule
csc /t:module /r:MultiFileLibrary.dll Program.cs
al /out:Program.exe /t:exe /main:Program.Main Program.netmodule
Adding Resource Files to an Assembly
AL.exe /embed[resource]switch /link[resource]switch
CSC.exe /resourceswitch /linkresourceswitch
One last note about resources: it’s possible to embed standard Win32 resources into an assembly. You can do this easily by specifying the path of a .res file with the /win32resswitch when using either AL.exe or CSC.exe.
In addition, you can quickly and easily embed a standard Win32 icon resource into an assembly file by specifying the path of the .ico file with the /win32iconswitch when using either AL.exe or CSC.exe.
Assembly Version Resource Information
Version Numbers
This version number is stored in the Win32 version resource.This number is for information purposes only; the CLR doesn’t examine this version number in any way.
AssemblyInformationalVersion.
This version number is also stored in the Win32 version resource, and again, this number is for information purposes only; the CLR doesn’t examine or care about it in any way. This version number exists to indicate the version of the product that includes this assembly.
AssemblyVersion
This version number is stored in the AssemblyDef manifest metadata table. The CLR uses this version number when binding to strongly named assemblies (discussed in Chapter 3). This number is extremely important and is used to uniquely identify an assembly.
Culture
You’ll usually use the AL.exe tool to build a satellite assembly. You won’t use a compiler because the satellite assembly should have no code contained within it.
When using AL.exe, you specify the desired culture by using the /c[ulture]:textswitch, where textis a string such as “en-US,” representing US English. When you deploy a satellite assembly, you should place it in a subdirectory whose name matches the culture text. For example, if the application’s base directory is C:\MyApp, the US English satellite assembly should be placed in the C:\MyApp\en-US subdirectory. At run time, you access a satellite assembly’s resources by using the System.Resources.ResourceManagerclass.
Simple Application Deployment (Privately Deployed Assemblies)
Simple Administrative Control (Configuration)
AppDir directory (contains the application’s assembly files)
Program.exe
Program.exe.config (discussed below)
AuxFiles subdirectory (contains MultiFileLibrary’s assembly files)
MultiFileLibrary.dll
FUT.netmodule
RUT.netmodule
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemasmicrosoftcom:asm.v1">
<probing privatePath="AuxFiles" />
</assemblyBinding>
</runtime>
</configuration>
No comments:
Post a Comment