Previous Section  < Day Day Up >  Next Section

1.4. Working with the .NET Framework and SDK

The .NET Framework Software Development Kit (SDK) contains the tools, compilers, and documentation required to create software that will run on any machine that has the .NET Framework installed. It is available as a free download (100 megabytes) from Microsoft that can be installed on Windows XP, Windows 2000, Windows Server 2003, and subsequent Windows operating systems. If you have Visual Studio.NET installed, there is no need to download it because VS.NET automatically does it for you.

Clients using software developed with the SDK do not require the SDK on their machine; however, they do require a compatible version of the .NET Framework. This .NET Framework Redistributable is available as a free download[3] (20+ megabytes) and should be distributed to clients along with applications that require it. This redistributable can be installed on Windows 98 and ME, in addition to the ones listed for the SDK. With minor exceptions, .NET applications will run identically on all operating system platforms, because they are targeted for the Common Language Runtime and not the operating system. There are some system requirements such as a minimum Internet Explorer version of 5.01. These are listed at the download site.

[3] http://msdn.microsoft.com/netframework/downloads/updates/default.aspx

Updating the .NET Framework

Unlike many development environments, installing a new version of the framework is almost effortless. The installation process places the updated version in a new directory having the name of the version. Most importantly, there is no file dependency between the new and older versions. Thus, all versions are functional on your system. Although it varies by operating system, the versions are usually in the path


\winnt\Microsoft.NET\Framework\v1.0.3705

\winnt\Microsoft.NET\Framework\v1.1.4322

\winnt\Microsoft.NET\Framework\v2.0.40607


The installation of any new software version raises the question of compatibility with applications developed using an older version. .NET makes it easy to run existing applications against any framework version. The key to this is the application configuration file (discussed in much greater detail in Chapter 15). This text file contains XML tags and elements that give the CLR instructions for executing an application. It can specify where external assemblies are located, which version to use, and, in this case, which versions of the .NET Framework an application or component supports. The configuration file can be created with any text editor, although it's preferable to rely on tools (such as the Framework Configuration tool) designed for the task. Your main use of the configuration file will be to test current applications against new framework releases. Although it can be done, it usually makes no sense to run an application against an earlier version than it was originally compiled against.

.NET Framework Tools

The .NET Framework automates as many tasks as possible and usually hides the details from the developer. However, there are times when manual intervention is required. These may be a need to better understand the details of an assembly or perform the housekeeping required to prepare an application for deployment. We have encountered several examples of such tasks throughout the chapter. These include the need to

  • Add a file to an assembly

  • View the contents of an assembly

  • View the details of a specific class

  • Generate a public/private key pair in order to create a strongly named assembly

  • Edit configuration files

Many of these are better discussed within the context of later chapters. However, it is useful to be aware of which tools are available for performing these tasks; and a few, such as those for exploring classes and assemblies, should be mastered early in the .NET learning curve.

Table 1-3 lists some of the useful tools available to develop and distribute your applications. Three of these, Ildasm.exe, wincv.exe, and the .NET Framework Configuration tool, are the subject of further discussion.

Table 1-3. Selected .NET Framework Tools

Tool

Description

Al.exe

Assembly Linker

Can be used for creating an assembly composed of modules from different compilers. It is also used to build resource-only (satellite) assemblies.

Fuslogvw.exe

Assembly Binding Log Viewer

Used to troubleshoot the assembly loading process. It traces the steps followed while attempting to load an assembly.

Gacutil.exe

Global Assembly Cache tool

Is used to install or delete an assembly in the Global Assembly Cache. It can also be used for listing the GAC's contents.

Ildasm.exe

MSIL Disassembler

A tool for exploring an assembly, its IL, and metadata.

Mscorcfg.msc

NET Framework Configuration tool

A Microsoft Management Console (MMC) snap-in used to configure an assembly while avoiding direct manual changes to an application's configuration file. Designed primarily for administrators, a subset, Framework Wizards. Available for individual programmers.

Ngen.exe

Native Image Generator

Compiles an assembly's IL into native machine code. This image is then placed in the native image cache.

Sn.exe

Strong Name tool

Generates the keys that are used to create a strong梠r signed梐ssembly.

wincv.exe

Windows Forms Class Viewer

A visual interface to display searchable information about a class.

Wsdl.exe

Web Services Description Language tool

Generates descriptive information about a Web Service that is used by a client to access the service.


Many of these tools are located in an SDK subdirectory:


c:\Program Files\Microsoft.NET\SDK\v2.0\Bin


To execute the tools at the command line (on a Windows operating system) while in any directory, it is first necessary to place the path to the utilities in the system Path variable. To do this, follow these steps:

1.
Right click on the My Computer icon and select Properties.

2.
Select Advanced ?Environment Variables.

3.
Choose the Path variable and add the SDK subdirectory path to it.

If you have Visual Studio installed, a simpler approach is to use the preconfigured Visual Studio command prompt. It automatically initializes the path information that enables you to access the command-line tools.

Ildasm.exe

The Intermediate Language Disassembler utility is supplied with the .NET Framework SDK and is usually located in the Bin subdirectory along the path where the SDK is installed. It is invaluable for investigating the .NET assembly environment and is one of the first tools you should become familiar with as you begin to work with .NET assemblies and code.

The easiest way to use the utility is to type in


C:\>Ildasm /adv


at a command-line prompt (the optional /adv switch makes advanced viewing options available). This invokes the GUI that provides a File menu you use to select the assembly to view. Note that it does not open files in the Global Assembly Cache.

Figure 1-9 shows an example of the output created when an assembly is opened in Ildasm. The contents are displayed in a readable, hierarchical format that contains the assembly name, corecsharp1, and all of its members.

Figure 1-9. View assembly contents with Ildasm.exe


This hierarchy can then be used to drill down to the underlying IL (or CIL) instructions for a specific member. As an example, let's consider the Conversion class. The figure shows that it consists of three methods: MeTRic, conversion, and metric. The original source code confirms this:


public class Conversion

{

   public double Metric( double inches)

   { return (2.54 * inches); }

   [CLSCompliantAttribute(false)]

   public double metric( double miles)

   { return (miles / 0.62); }

   public double conversion( double pounds)

   { return (pounds * 454);}

}


Double clicking on the MeTRic method brings up a screen that displays its IL (Figure 1-10).

Figure 1-10. View of the IL


Ildasm can be used as a learning tool to solidify the concepts of IL and assemblies. It also has some practical uses. Suppose you have a third-party component (assembly) to work with for which there is no documentation. Ildasm provides a useful starting point in trying to uncover the interface details of the assembly.

Core Suggestion

Ildasm has a File ?Dump menu option that makes it useful for saving program documentation in a text file. Select Dump Metainfo to create a lengthy human-readable form of the assembly's metadata; select Dump Statistics to view a profile of the assembly that details how many bytes each part uses.


Ildasm and Obfuscation

One of the natural concerns facing .NET developers is how to protect their code when a tool such as Ildasm梐nd other commercially available disassemblers梒an be used to expose it. One solution is to use obfuscation梐 technique that uses renaming and code manipulation sleight of hand to make the contents of an assembly unreadable by humans.

It is important to understand that obfuscation is not encryption. Encryption requires a decryption step so that the JIT compiler can process the code. Obfuscation transforms the IL code into a form that can be compiled using the tools of your development environment (see Figure 1-11).

Figure 1-11. Obfuscation conceals the original Intermediate Language


The obfuscated code is functionally equivalent to the assembly's IL code and produces identical results when run by the CLR. How does it do this? The most common trick is to rename meaningful types and members with names that have no intrinsic meaning. If you look at obfuscated code, you'll see a lot of types named "a" or "b," for example. Of course, the obfuscation algorithm must be smart enough not to rename types that are used by outside assemblies that depend on the original name. Another common trick is to alter the control flow of the code without changing the logic. For example, a while statement may be replaced with a combination of goto and if statements.

An obfuscator is not included in the .NET SDK. Dotfuscator Community Edition, a limited-feature version of a commercial product, is available with Visual Studio.NET. Despite being a relatively unsophisticated product梐nd only available for the Microsoft environment梚t is a good way to become familiar with the process. Several vendors now offer more advanced obfuscator products.

wincv.exe

WinCV is a class viewer analogous to the Visual Studio Object Viewer, for those not using Visual Studio. It is located in the Program Files\Microsoft.Net\SDK\V1.x\Bin directory and can be run from the command prompt. When the window appears, type the name of the class you want to view into the Searching For box (see Figure 1-12).

Figure 1-12. Using WinCV to view type definition of the Array class


WinCV provides a wealth of information about any type in the base class libraries. The four highlighted areas provide a sampling of what is available:

  1. System.Array is the class that is being explored.

  2. This class is located in the mscorlib.dll assembly. We have already mentioned that this assembly contains the .NET managed types.

  3. This list contains the class, object, and interfaces that the Array class inherits from.

  4. The definition of each method in the class is included. This definition, which includes accessibility, type, and parameters, is called the method's signature.

Framework Configuration Tool

This tool provides an easy way to manage and configure assemblies as well as set security policies for accessing code. This tool is packaged as a Microsoft Management Console (MMC) snap-in. To access it, select Administrative Tools from the Control Panel; then select the Microsoft .NET Framework Configuration tool. This tool is designed for administrators who need to do the following:

  • Manage assemblies. Assemblies can be added to the GAC or deleted.

  • Configure assemblies. When an assembly is updated, the publisher of the assembly is responsible for updating the binding policy of the assembly. This policy tells the CLR which version of an assembly to load when an application references an assembly. For example, if assembly version 1.1 replaces 1.0, the policy redirects version 1.0 to 1.1 so that it is loaded. This redirection information is contained in a configuration file.

  • View .NET Framework security and modify an assembly's security. .NET security allows an assembly to be assigned certain permissions or rights. In addition, an assembly can require that other assemblies accessing it have certain permissions.

  • Manage how individual applications interact with an assembly or set of assemblies. You can view a list of all assemblies an application uses and set the version that your application uses.

To illustrate a practical use of the configuration tool, let's look at how it can be used to address one of the most common problems that plagues the software development process: the need to drop back to a previous working version when a current application breaks. This can be a difficult task when server DLLs or assemblies are involved. .NET offers a rather clever solution to this problem: Each time an application runs, it logs the set of assemblies that are used by the program. If they are unchanged from the previous run, the CLR ignores them; if there are changes, however, a snapshot of the new set of assemblies is stored.

When an application fails, one option for the programmer is to revert to a previous version that ran successfully. The configuration tool can be used to redirect the application to an earlier assembly. However, there may be multiple assemblies involved. This is where the configuration tool comes in handy. It allows you to view previous assembly configurations and select the assemblies en masse to be used with the application.

To view and select previous configurations, select Applications ?Fix an Application from the Configuration tool menu. Figure 1-13 combines the two dialog boxes that subsequently appear. The main window lists applications that have run and been recorded. The smaller window (a portion of a larger dialog) is displayed when you click on an application. This window lists the most recent (up to five) configurations associated with the application. You simply select the assembly configuration that you want the application to use.

Figure 1-13. Using application configuration tool to select assembly version


This configuration tool is clearly targeted for administrators. Individual developers should rely on a subset of this tool that is packaged as three wizards: Adjust .NET Security, Trust An Assembly, and Fix An Application. Access these by selecting Framework Wizards from Administrative Tools.

    Previous Section  < Day Day Up >  Next Section