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
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
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…
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
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