Microsoft .NET Framework provides many tools to help developers make the best use of the Framework. In the following sections, we document the commonly used subset of .NET tools that we’ve used throughout this book:
al.exe is generally used to generate assemblies with manifests. Table D-1 shows some of the common uses of the Assembly Generation Utility.
Option |
Description |
|
Specifies a value for the Flags field in the assembly.
|
|
Use to get help for this command. |
|
Use to create shared components.
|
|
Use to create shared components.
|
|
Specifies the entry-point method name when converting a module to an executable. |
|
Specifies the output filename. |
|
Specifies the file format of the output file ( |
|
Specifies version information for the assembly. The default value is 0. |
You can use gacutil.exe to install and uninstall an assembly, as well as to list the content of the GAC. Table D-2 shows some of the common uses of the Assembly Registration Utility.
Option |
Description |
|
To list the content of the GAC. |
|
To list the content of the downloaded files cache. |
|
To clear the content of the downloaded file cache. |
/i |
To install an assembly with file named
|
/u |
To uninstall an assembly from the GAC by specifying the assembly
name. If multiple versions of the same assembly exist, all of them
will be removed unless a version is specified with the
|
|
To display command syntax and options. |
This tool takes MSIL as input and generates a portable executable (PE) file containing the MSIL and the metadata required to run on the .NET Framework. This is most useful to vendors who would like to create MSIL-compliant compilers. All they have to do is write the compiler to translate the source language to MSIL. Ilsam.exe will take the second step to put the MSIL content into the PE format where it can be executed on the .NET Framework. The general syntax for MSIL assembler is:
ilasm [options] MSILfilename
Table D-3 shows some of the common uses of the assemblers.
Option |
Description |
|
This option ensures that the output PE contains debugging information such as local variables, argument names, and line numbers. This is useful for debug build. |
|
This option produces a |
|
This option produces an |
|
This option produces a listing of the output on STDOUT. |
|
|
|
This option is used to obtain command-line help. |
This tool extracts the MSIL code from a PE file targeted for .NET Framework. The general syntax for this tool is:
Ildasm [options] PEFilename
Table D-4 shows some of the common uses of the disassembler.
Option |
Description |
|
This includes references to original source lines. |
|
The output goes to a file instead of in a GUI dialog box. |
|
This shows original source lines as comments. |
|
The output goes in a console window. |
|
This shows metadata tokens of classes and members. |
Table D-5 shows some of the common uses of the C++ compiler.
Option |
Description |
|
This option flags the compiler to compile .NET-runtime managed code. |
|
For C++ managed code, this link setting should point to the main entry-point function. |
|
This option combines the compile and link steps. |
|
This link option specifies the type of output. |
|
This option allows for the output filename. |
Table D-6 shows some of the common uses of the C# compiler.
Table D-7 shows some of the common uses of the Visual Basic compiler.
Option |
Description |
|
With this option, the compiler will emit debugging information in the output file. |
|
Use this option to define preprocessor symbols. |
|
This option shows the command-line help for the Visual Basic compiler. |
|
|
|
|
|
If there is more than one Main entry in different classes, you will have to specify the Main entry in which class you want the entry point of the application. |
|
This option represents the output filename. |
|
Turn on or off |
|
Turn on or off |
|
This option allows single or multiple libraries be included with this compilation. For multiple libraries to be included, use a semicolon as the delimiter. |
|
This option allows you to specify the type of the output:
|
dumpbin is not a new utility. However, since .NET Framework stores the IL inside the extended PE format, this old utility is still very useful for examining the structure of executable or DLLs, as well as listing import and export entries of the binaries. The general syntax for this utility is:
Dumpbin [options] PEFilename
Table D-8 shows some of the common dumpbin uses.
Option |
Description |
|
Displays all information from the PE file. |
|
Displays all exports from the PE file. |
|
Displays the header information from the PE file. |
|
Display the .NET Framework header information for an image built with /clr (see CL.exe). |
|
Displays all imports for the PE file. |
Type library exporter and importer are the two tools necessary for COM interop. The exporter generates a type library for a .NET Framework assembly so that other COM components can interop with .NET components. The general syntax for tlbexp.exe is:
tlbexp AssemblyName [options]
Table D-9 shows some of the common uses of tlbexp.exe.
Option |
Description |
|
This option suppresses the logo of the |
|
|
|
This option suppresses all messages from the
|
|
This option displays extra information while converting the component. |
|
This option displays the help information for the tool. |
Because it is the reverse tool of the type library exporter, the importer generates a .NET proxy component for a COM component so that .NET components can use legacy COM components. The general syntax for tlbimp.exe is:
tlbimp PEFile [options]
Table D-10 shows some of the common uses of tlbimp.exe.
Option |
Description |
|
This option signs the resulting assembly with the private key in the
|
|
This options signs the resulting assembly with the private key in the
|
|
This option suppresses the logo of the |
|
|
|
This option suppresses all messages from the
|
|
This option produces interfaces without .NET Framework security checks. |
|
This option displays extra information while converting the component. |
|
This option displays the help information for the tool. |
XML Schema Definition (XSD) is useful when working with XML schemas that follow the XSD language. With XSD, you can perform the following transformations:
XDR to XSD
XML to XSD
Classes to XSD
XSD to Classes
XSD to DataSet
To convert an XDR-formatted file to XSD, use the following syntax:
xsd [options] file.xdr
Note that the file extension .xdr dictates the conversion from XDR to XSD.
To convert an XML-formatted file to XSD, use the following syntax:
xsd [options] file.xml
Note that the file extension .xml dictates the conversion from XML to XSD.
You
can convert classes to XSD by specifying
the runtime assembly file (.exe or
.dll extension) as the filename to the utility.
You can also specify a particular type within the assembly you want
to convert to XSD using the /type
flag. The
typename
can be a wildcard match. If you omit the
/type
flag, all types in the assembly will be
converted. The syntax follows:
Xsd [/TYPE:typename
] assemblyFile
or:
Xsd [/T:typename
] assemblyFile
To convert XSD back to classes, use the /classes
or /c
flag. You can specify a particular element
in the XSD schema to be converted to a class. You can also specify
the language for the class source file. The general syntax follows:
xsd /CLASSES /ELEMENT:element
/NAMESPACE:namespace
/LANGUAGE:language
/URI:uri file.xsd
or:
xsd /C E:element /N:namespace /L:language /U:uri file.xsd
Note that namespace
, language
,
and uri
can be specified only once.
The Strong Name Utility (sn.exe) guarantees unique names for shared components because these components will end up in the GAC. Each shared component is signed with a private key and published with the public key. Table D-11 shows some common uses of sn.exe.
Option |
Description |
|
This option displays more command-line help. |
|
This option is used to remove the
|
|
This option reads the key pair in |
|
This option generates a new key pair and writes it to
|
|
This option is used to verify the shared name in an
|
wsdl.exe helps create ASP.NET web services and proxies for their clients. The most common usage of wsdl.exe is to generate proxy classes for Web services:
wsdl /language:language
/namespace:namespace
/out:output
/protocol:protocol
path
The path parameter is a local path to a service-description file or URI where the SDL file can be retrieved. The language parameter specifies the language for the output-proxy source file. It can be C#, VB, JS or VJS. The generated class will be in the specified namespace. The output source file is controlled by the output option. The protocol controls which protocol the proxy will use to communicate with the Web Service. The choices of protocols provided by the .NET Framework are SOAP, SOAP12, HttpGet, and HttpPost. You can also have your own protocol here if you’ve extended the WebClientProtocol or HttpWebClientProtocol class.
For short names options, use the following:
wsdl/l:
language
/n:namespace
/o:output
/protocol:protocol
path
The rest of the syntax can be obtained with wsdl /?.