8 Chapter 1 • Introducing the Microsoft .NET Platform
in use, these objects will always have a reference count greater than zero, so unless
they are implicitly deconstructed, their memory may never be recovered.
For a C or C++ programmer—accustomed to ensuring that objects are
properly destroyed, essentially managing memory on their own—this sounds per-
fectly normal, and a good reason for not trusting anyone else to take care of
managing resources. However, in the .NET environment, Microsoft is striving to
make developing software easier. Later in this chapter, we cover a how .NET
garbage collection works, and the improvements that have been made over strict
reference counting or manual memory management approaches.
Versioning Support
Anyone who doesn’t understand the phrase “DLL Hell” hasn’t been developing
(or at least supporting) software for Windows very long. For the uninitiated,
you’ll find yourself in DLL Hell someday when a customer installs a software
package that uses one of the same DLLs as your application. However, your appli-
cation used version 1.0 of this DLL, and the new software replaces it with version
1.1.We developers all always make sure everything is 100% backwards-compat-
ible, right? The new DLL makes your application exhibit some strange problem
or perhaps just stop working altogether.After a lot of investigation, you figure out
what the offending DLL is and have the customer replace the new one with the
version that works with your software. Now their new software doesn’t work…
welcome to DLL Hell. Many developers resort to simply installing every DLL
their application requires in the application directory so that it will be found first
when the application loads the libraries.This defeats the purpose of shared
libraries, but it is one way around the problem.
COM was going to change this; one of its primary tenants was that you never
changed a methods interface you simply add new methods. Unfortunately, software
developers are frequently perfectionists, and leaving a “broken” function alone just
chafes some people. Problem is, changing a components interface once it’s in use
can have adverse affects on the client software that expected the old behavior.
Because COM objects are loaded using information in the Registry, simply placing
the DLL or control in the application directory doesn’t work for this problem.
The .NET architecture now separates application components so that an
application always loads the components with which it was built and tested. If the
application runs after installation, the application should always run.This is done
with assemblies, which are .NET-packaged components.Although current DLLs
and COM objects do contain version information, the OS does not use this
information for any real purpose.Assemblies contain version information that the
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 8
Introducing the Microsoft .NET Platform • Chapter 1 9
.NET Common Language Runtime uses to ensure that an application will load
the components it was built with.We cover more of the specifics of how assem-
blies and versioning works later in the chapter.
Support for Open Standards
In today’s world, not every device you may want to work with is going to be
running a Microsoft OS or using an Intel CPU. Realizing this, the architects of
.NET are relying on XML and its most visible descendant, SOAP, an emerging
standard for sending messages across the Internet that activates programs or appli-
cations regardless of their underlying infrastructure. SOAP will provide the means
for disparate systems to exchange information easily, but even more, SOAP allows
you to invoke methods on remote systems and return the results. Because SOAP
is a simple text-based protocol similar to HTTP, it can easily pass through fire-
walls, unlike DCOM or CORBA objects.
Other standards employed by the .NET platform include Universal
Description, Discovery, and Integration (UDDI), a directory of companies and
their XML interfaces and the Web Services Description Language (WSDL),
which describes what a piece of application code can do. By basing much of
.NET on open standards and by submitting the proposed draft standards for C#
and the .NET Common Language Infrastructure to ECMA, an international
standards organization, Microsoft hopes to see its version of the future of software
adopted beyond its own domain.
Easy Deployment
Today, developing installations for Windows-based applications can be incredibly
difficult, to the point that most companies use third party tools for developing
their installation programs, and even then it’s not pleasant.There are usually a
large number of files to be installed in several directories, various Registry set-
tings, installation of required COM components, and shortcuts that need to be
created, and so on. Completely uninstalling an application is nearly impossible,
most leave bits and pieces of themselves around even if they provide an uninstall
feature.With the release of Windows 2000, Microsoft introduced a new installa-
tion engine that helps with some of these issues, but it is still possible that the
author of a Microsoft Installer Package may fail to do everything correctly. Even
with those third party tools specifically designed to make developing installation
programs easier, it is still frequently a monumental task to correctly install a
retrievial application.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 9
10 Chapter 1 • Introducing the Microsoft .NET Platform
The .NET design team must have felt the same way about this problem,
because .NET plans to do away with these issues for good. .NET components
are not referenced in the Registry, thanks to the use of metadata and reflection,
components are self describing. In fact, installing many .NET applications will
require no more than copying their files to a directory, and uninstalling an appli-
cation will be as easy as deleting those files.
Distributed Architecture
Today’s distributed applications are much different than those we will see in the
future. Microsoft certainly believes this; they say they are betting the company on
the concept of distributed Web services.
www.syngress.com
Using the Visual Studio.NET Setup Tools
Realizing that deploying applications and authoring installation pack-
ages is frequently a monumental task, the Visual Studio.NET team inte-
grated a number of setup tools into the Visual Studio.NET environment.
After you have completed your Visual Studio.NET project develop-
ment, start a new project from the File menu. Choose Setup and
Deployment Projects from the selection list. You’ll see a number of
setup project options listed:
■
Cab Project
■
Deploy Wizard
■
Merge Module Project
■
Setup Project
■
Setup Wizard
■
Web Setup Project
Using the wizards, you can select the Visual Studio project you want
to use and have a setup or deployment project created automatically. If
the defaults are not sufficient for your needs, you can use the new setup
project as a basis for creating your custom setup or deployment.
Developing & Deploying…
167_C#_01.qxd 12/3/01 5:42 PM Page 10
Introducing the Microsoft .NET Platform • Chapter 1 11
For example, today when a user is interacting with a portal site, it appears to
them that they are working with one remote server. Most of us know that is nor-
mally not the case, at least for a site of any significant size.There are various
servers and applications behind the scenes are accessing information on several
remote sites, combining it with information from their user database and merging
it all into an integrated product that is delivered to the user via their browser.
As useful as these types of applications are, they are all very complex to
develop and maintain. Each provider of information has developed different
interfaces to access data and processes on their servers.This redundant develop-
ment is grossly inefficient and for the most part fairly boring, so there has been a
great deal of activity around three standards to streamline the process: XML,
SOAP, and UDDI.As we discussed earlier, these are used in .NET and also in
competing, less well known initiatives from IBM and Sun.
Interoperability with Unmanaged Code
As you can probably guess, unmanaged code is code that isn’t managed by the
.NET Common Language Runtime. However, this code is still run by the CLR,
it just doesn’t get the advantages that it offers, such as the Common Type System
and Automatic Memory Management.You will probably end up using unman-
aged code in a couple of different situations:
■
Calling DLL functions There is a lot of functionality locked inside
DLLs today. Not every company is going to rush to deliver a .NET
component version of their products, so if you need to interface with
them, you’ll be calling unmanaged code.
■
Using COM components This is likely to be for pretty much the
same reasons you might be required to call DLL functions.
■
Calling .NET services from COM components Although this
sounds a little odd, it is possible.A COM client can be made to call a
.NET component as though it was a COM server.
Here’s a little more information on the COM interoperability issue. Microsoft
didn’t want to force companies to abandon their existing COM components;
especially because many of Microsoft’s own products are COM-based today.
COM components interoperate with the .NET runtime through an
interop layer
that handles all the work required when translating messages that pass back and
forth between the managed runtime and the COM components operating as
unmanaged code.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 11
12 Chapter 1 • Introducing the Microsoft .NET Platform
On the other side of the coin, companies with a vested interest in COM
technology might want to use a few bits and pieces from the .NET platform,
sticking a toe in before taking the plunge. COM clients can easily interface with
.NET components through the COM interop layer.
Security
Distributed component-based applications require security, and thus far Microsoft
hasn’t had a lot of positive feedback about its products’ security features.
Fortunately, the .NET designers decided to take a new approach, different than
traditional OS security, which provides isolation and access control based on user
accounts, and also unlike the model used by Java, where code that is not trusted is
run in a “sandbox,” with no access to critical resources.The .NET Framework
provides a fine-grained control of application security.
Security for .NET applications starts as soon as a class is loaded by the CLR.
Before the class loader instantiates a class, security information—such as accessi-
bility rules and self-consistency requirements—are checked. Calls to class methods
are checked for type safety. If you’ve ever heard of a security vulnerability caused
by a “buffer overrun,” you can understand why this is important.With verified
code, a method that is declared as taking a 4-byte integer parameter will reject an
attempt to call it with an 8-byte integer parameter.Verification also prevents
applications from executing code at a random location in memory, a common
tactic in buffer overflow exploits.
Additionally, as code requests access to certain resources, the class credentials are
verified. .NET security crosses process boundaries and even machine boundaries to
prevent access to sensitive data or resources in a distributed application environ-
ment.The following are some of the basic elements of the .NET security system:
■
Evidence-based security is a new concept introduced by the
.NET Framework. An assembly contains several important pieces of
information that can be used to decide what level of access to grant the
component. Some of the information used includes what site the com-
ponent was downloaded from, what zone that site was in, (Internet,
intranet, local machine, and so on) and the strong name of the assembly.
The strong name refers to an encrypted identifier that uniquely defines
the assembly and ensures that it has not been tampered with.
■
The .NET Common Language Runtime further provides secu-
rity using a Policy-Driven Trust Model Using Code Evidence.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 12
Introducing the Microsoft .NET Platform • Chapter 1 13
It sounds worse than it really is. Essentially this is a system of security
policies that can be set by an administrator to allow certain levels of
access based on the component’s assembly information.The policies are
set at three levels: the enterprise, the individual machine, and the user.
■
Calling .NET Framework methods from the Base Class Library
get the benefits of built in security. That is, the developer doesn’t
have to make explicit security calls to access system resources. However,
if your components expose interfaces to protected resources, you will be
expected to take the appropriate security measures.
■
Role-based security plays a part in the .NET security scheme.
Many applications need to restrict access to certain functions or
resources based on the user, and .NET introduces the concepts of identi-
ties and principals to incorporate these functions.
■
Authentication and authorization functions are accessed
through a single API. It can easily be extended to incorporate appli-
cation-specific logic as required.Authentication methods include basic
operating system user identification, basic HTTP,ASP.NET forms,
Digest and Kerberos, as well as the new .NET service, Microsoft .NET
Passport.
■
Isolated storage is a special area on disk assigned to a specific
assembly by the security system. No access to other files or data is
allowed, and each assembly using isolated storage is separated from each
other. Isolated storage can be used for a saving a components state, or
saving settings, and can be used by components that do not have access
to read and write files on the system.
■
A robust set of cryptographic functions that support encryp-
tion, digital signatures, hashing, and random-number generation
are included in the .NET Framework. These are implemented
using well-known algorithms, such as RSA, DSA, Rijndael/AES,Triple
DES, DES, and RC2, as well as the MD5, SHA1, SHA-256, SHA-384,
and SHA-512 hash algorithms.Additionally, the XML Digital Signature
specification, under development by the Internet Engineering Task Force
(IETF) and the World Wide Web Consortium (W3C), is also available.
The .NET Framework uses these cryptographic functions to support
various internal services.The cryptographic objects are also available in
the Base Class Library for developers who require this functionality.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 13
14 Chapter 1 • Introducing the Microsoft .NET Platform
Performance and Scalability
Let’s face it—there is no magic bullet that will allow a poorly designed applica-
tion to scale well.What the .NET Framework is giving you are tools to make it
easier to design better performing software. One big gain for Web development
will come from ASP.NET’s improved support for keeping code, data, and presen-
tation separate. .NET offers features for transaction handling and component
pooling, but makes them easier to use than they were in previous incarnations, so
more development will be likely to take advantage of them.The .NET Base Class
Library has an enormous set of functionality, which means that you will have to
write less basic code and spend more time refining the features and performance
of your applications.
New versions of Microsoft software christened with the .NET emblem offer
improved performance over earlier versions. SQL Server.NET offers quite an
enhancement over earlier versions of the database engine, and other server prod-
ucts offer enhanced scalability as well.When you redesign an application around
the .NET Framework, take advantage of the latest advances all around and see
what the results are.
Components of the .NET Architecture
As we mentioned earlier, there is a lot to the .NET Framework. In this section,
we identify the individual components and describe their features and how they
fit into the overall picture.
.NET Runtime
The heart of the .NET Framework is the CLR. Similar in concept to the Java
Virtual Machine, it is a runtime environment that executes MSIL code. Unlike
the Java environment, which is the concept of one language for all purposes, the
.NET platform supports multiple programming languages through the use of the
Common Language Specification, which defines the output required of com-
pilers that want to target the CLR.
Managed/Unmanaged Code
Because all code targeted at the .NET platform runs with the CLR environment,
it is referred to as managed code.This simply means that the execution of the
code and its behavior is managed by the CLR.The metadata available with man-
aged code contains the information required to allow the CLR to manage its safe
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 14
Introducing the Microsoft .NET Platform • Chapter 1 15
execution. By safe execution we mean memory and security management, type
safety, and interlanguage interoperability. Unmanaged code can write to areas of
memory it does not own, execute instructions at arbitrary locations in memory,
and exhibit any number of other bad behaviors that cannot be managed or pre-
vented by the CLR. Most of the applications running on Windows today are
unmanaged.
Intermediate Language
The .NET intermediate language, MSIL, is defined in the Common Language
Specification. It is an amalgam of a low-level language similar in many ways to a
machine language and a higher object language.You can write applications directly
in MSIL, much as you can write directly in assembly language.Thankfully, this is
not necessary for most purposes.
Common Type System
.NET applications, regardless of their source languages all share a common type
system.What this means is that you no longer have to worry when doing devel-
opment in multiple languages about how a data type declared in one language
needs to be declared in another. Any .NET type has the same attributes regardless
of the language it is used in. Furthermore, all .NET data types are objects,
derived from System.Object.
Because all data types derive from a common base class, they all share some
basic functionality, for example the ability to be converted to a string, serialized,
or stored in a collection.
.NET Base Class Library (BCL)
If I could have bought a library that offered everything the .NET Base Class
Library offers when I started programming, a year’s salary would have seemed
reasonable—there really is that much to it.Almost everything in the .NET envi-
ronment is contained within the BCL. Let’s look at a “Hello World” example:
using System;
class Hello
{
public static void Main()
{
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 15
16 Chapter 1 • Introducing the Microsoft .NET Platform
Console.WriteLine("Hello World");
}
}
The only function contained in this simple program is a call to the WriteLine
method of the Console class.What is really unique about the .NET environment
is that .NET languages don’t have to implement even the most basic functions;
they are available in the BCL. Because all .NET languages share the same
common set of libraries, the code being executed by your C# program is the
same code being executed by a program written in another language.This means
that all languages that target the .NET environment essentially share the same
capabilities, except they have different syntax.
Some people will wonder why we even have different languages if they all
have the same capabilities.A few reasons immediately spring to mind:
■
Programmers don’t like change.
■
Programmers usually have a favorite language.
■
Programmers don’t like change…
Imagine if Microsoft had come out with all the good things in .NET, but said
that in order to use it, we all had to learn a new language. Lots of people might
have never even given it an honest look unless forced by their employers. Making
it available for all languages makes it seem less like the chore of learning a new
language and more like the excitement of receiving a new library with tens of
thousands of functions that will make your life as a developer easier.
Assemblies
Assemblies are the means of packaging and deploying applications and compo-
nents in .NET. Just like a compiled application or component today, assemblies
can be made up of either single or multiple files.An assembly contains metadata
information (covered in the next section), which is used by the CLR for every-
thing from type checking and security to actually invoking the components
methods.All of this means that you don’t need to register .NET components,
unlike COM objects.
Metadata
Metadata is the feature that lets the CLR know the details about a particular
component.The metadata for an object is persisted at compile time and then
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 16
Introducing the Microsoft .NET Platform • Chapter 1 17
queried at runtime so that the CLR knows how to instantiate objects, call their
methods, and access their properties.Through a process called reflection, an appli-
cation can interrogate this metadata and learn what an object exposes.This is
similar to the way IDispatch and type libraries work in COM.
Unlike COM, where the information about a component can be found in
type libraries and the Registry, where it is only associated with the actual compo-
nent, .NET metadata is stored within the component itself in a binary format
packaged inside the assembly.The metadata contains a declaration for every type
and a declaration, including names and types, for all of its members (methods,
fields, properties, and events). For every method implemented by the component,
the metadata contains information that the loader uses to locate the method
body. It is also possible (but not required) for the creator of a class type to asso-
ciate help text and comments with a method or parameter in the metadata, sim-
ilar to the way that information can be associated with a component using
information within the IDL in the COM world.
Besides the low-level information described in this section, a component also
includes information regarding its version and any culture information specific to
the component.The culture information can be queried at runtime and used in
developing localized applications. Look at the System.Reflection.AssemblyName class
as a place to get started, and check out the CultureInfo class to see how extensive
the culture support of .NET components can be.You can also use reflection to
determine a components version, which might be useful if your application is
dynamically loading components and needs to make adjustments for different
versions.
Assemblies and Modules
.NET applications are deployed as assemblies, which can be a single executable or
a collection of components.When you create a .NET application, you are actu-
ally creating an assembly, which contains a manifest that describes the assembly.
This manifest data contains the assembly name, its versioning information, any
assemblies referenced by this assembly and their versions, a listing of types in the
assembly, security permissions, its product information (company, trademark, and
so on), and any custom attribute.
An assembly that is shared between multiple applications also has a shared
name (also known as a strong name).This is a key pair containing a globally unique
name (think GUID from COM) as well as an encrypted digital signature to pre-
vent tampering.This information is optional and may not be in a component’s
manifest if it was not intended as a shared component.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 17
18 Chapter 1 • Introducing the Microsoft .NET Platform
Creating .NET modules that do not contain assembly manifest data is also
possible.These modules can then be added to an assembly, by including it in the
Visual Studio project.An example of why you might want to do this would be if
you had a component that was logically divided into several subcomponents that
would be best distributed and versioned as a single unit.
Assembly Cache
The assembly cache is a directory normally found in the \WinNT\Assembly direc-
tory.When an assembly is installed on the machine, it can be merged into the
assembly cache, depending upon the installation author or the source of the
assembly.The assembly cache has two separate caches: a global assembly cache and
a transient assembly cache.When assemblies are downloaded to the local machine
using Internet Explorer, the assembly is automatically installed in the transient
assembly cache. Keeping these assemblies separated prevents a downloaded com-
ponent from impacting the operation of an installed application.
Now for what may be a great feature that you won’t think of until your pro-
ject is finished.The assembly cache will hold multiple versions of an assembly,
and if your installation programs are written correctly, they cannot overwrite a
www.syngress.com
Finally, a Complete Debugging Solution
Some old-school programmers eschew today’s fancy Integrated
Development Environments (IDEs) as a mere toy for the weak. (Giving
away my age, it’s mostly us crusty old Unix programmers) However, the
debugging capabilities offered by the new Visual Studio.NET IDE may
finally change their minds. The new IDE provides end-to-end debugging
of applications across languages, projects, processes, and stored proce-
dures. This is a monumental achievement on the part of the Visual
Studio development team.
Using the integrated debugger, developers can step between HTML,
script, and code written in any of the .NET supported languages com-
plete with integrated call stacks offering a total solution for end-to-end
development.
Debugging…
167_C#_01.qxd 12/3/01 5:42 PM Page 18
Introducing the Microsoft .NET Platform • Chapter 1 19
previous version of an assembly that may be needed by another application.You
read that right, the .NET Framework is making a solid effort to banish DLL Hell.
Just to clarify what this means, the assembly cache can contain multiple ver-
sions of a component, as an example, we’ll say we’ve installed versions 1.0 and 1.1
of MyComponent.dll on a system. If an application was built and tested using
Version 1.0 of MyComponent.dll, the CLR will see this when it reads the appli-
cation’s metadata and will load Version 1.0 of MyComponent.dll, even though a
later version of the assembly exists in the cache.The application will continue to
function normally because the code that it is executing is the same code that it
was built and tested with.Thanks to this feature, you also don’t have to maintain
compatibility with earlier versions of your components.This feature alone is
enough to make the .NET architecture great.
Reflection
Reflection is the means by which .NET applications can access an assembly’s meta-
data information and discover its methods and data types at runtime.You can also
dynamically invoke methods and use type information through late binding
through the Reflection API.
The System.Type class is the core of the reflection system. System.Type is an
abstract class that is used to represent a Common Type System type. It includes
methods that allow you to determine the type’s name, what module it is con-
tained in, and its namespace, as well as if it is a value or reference type.
For example, using the System.Reflection.Assembly class you can retrieve all of
the types in an assembly, and all of the modules contained in the assembly.To
invoke a method of a class loaded at runtime, you would use a combination of
the Activator class to create an instance of the type you had obtained through the
Assembly class.Then you can use the type’s GetMethod method to create a
MethodInfo object by specifying the method name that you wish to invoke.At
this point, you can use the MethodInfo object’s Invoke method, passing it the
instance of the type you created with the Activator class.
It sounds a lot like some of the nasty bits of COM programming, but the
Reflection API genuinely makes it a lot easier.
Just In Time Compilation
The .NET CLR utilizes Just In Time (JIT) compilation technology to convert
the IL code back to a platform/device–specific code. In .NET, you currently have
three types of JIT compilers:
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 19
20 Chapter 1 • Introducing the Microsoft .NET Platform
■
Pre-JIT This JIT compiles an assembly’s entire code into native code at
one stretch.You would normally use this at installation time.
■
Econo-JIT You would use this JIT on devices with limited resources. It
compiles the IL code bit-by-bit, freeing resources used by the cached
native code when required.
■
Normal JIT The default JIT compiles code only as it is called and
places the resulting native code in the cache.
In essence, the purpose of a JIT compiler is to bring higher performance to
interpreted code by placing the compiled native code in a cache, so that when
the next call is made to the same method/procedure, the cached code is exe-
cuted, resulting in an increase in application speed.
Garbage Collection
Memory management is one of those housekeeping duties that takes a lot of pro-
gramming time away from developing new code while you track down memory
leaks.A day spent hunting for an elusive memory problem usually isn’t a produc-
tive day.
.NET hopes to do away with all of that within the managed environment
with the garbage collection system. Garbage collection runs when your applica-
tion is apparently out of free memory, or when it is implicitly called but its exact
time of execution cannot be determined. Let’s examine how the system works.
When your application requests more memory, and the memory allocator
reports that there is no more memory on the managed heap, garbage collection is
called.The garbage collector starts by assuming everything in memory is trash
that can be freed. It then walks though your application’s memory, building a
graph of all memory that is currently referenced by the application. Once it has a
complete graph, it compacts the heap by moving all the memory that is gen-
uinely in use together at the start of the free memory heap.After this is complete,
it moves the pointer that the memory allocator uses to determine where to start
allocating memory from the top of this new heap. It also updates all of your
application’s references to point to their new locations in memory.This approach
is commonly called a mark and sweep implementation.
The exception to this is with individual objects over 20,000 bytes.Very large
objects are allocated from a different heap, and when this heap is garbage col-
lected, they are not moved, because moving memory in this size chunks would
have an adverse effect on application performance.
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 20
Introducing the Microsoft .NET Platform • Chapter 1 21
As you can see, garbage collection involves a lot of work, and it does take
some time.A number of performance optimizations involved in the .NET
garbage collection mechanism make it much more than the simple description
given here.
Normally you will just let the CLR take care of running garbage collection
when it is required. However, at times you may want to force the garbage col-
lector to run, perhaps before starting an operation that is going to require a large
amount of memory.To do this, just call GC.Collect().And if you want to report
on your memory use at various points during your application’s execution to
help you determine when might be a good time to force collection, you can use
GC.GetTotalMemory(bool forceFullCollection).
As you can probably guess, the parameter forceFullCollection determines if
garbage collection is run before returning the amount of memory in use.
NOTE
For those of you who may want to know more about how the .NET
garbage collector actually works its magic, Jeffery Richter wrote two arti-
cles for MSDN magazine in the November and December 2000 issues
that describe the system architecture in some depth. You can find them
online at msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp and
msdn.microsoft.com/msdnmag/issues/1200/GCI2/GCI2.asp.
Exploring the Code Cycle
Let’s take a look at what’s really going on with a .NET application from code to
execution.We’ve already covered that the compiler is going to transform your
source code into IL, but what else is happening from code to running applica-
tion? Here’s an example:
1. You write your “Hello World” application in Visual Studio .NET using
the C# Console Application project.
2. The compiler outputs the MSIL code and a manifest into an exe file
that has a standard Win32 executable header.
Let’s stop here and take a look at the output using ildasm.exe, a MSIL disas-
sembly tool provided with the .NET SDK. Here is the Hello.exe manifest:
www.syngress.com
167_C#_01.qxd 12/3/01 5:42 PM Page 21
Không có nhận xét nào:
Đăng nhận xét