Additional Key Design Goals - Page 6
April 13, 2001
Simpler, Safer Deployment
It's hard for an experienced Windows component developer to see
how anything can work without registration, GUIDs, and the like,
but the CLR does. Applications produced in the .NET framework can
be designed to install with a simple XCOPY. That's right –
just copy the files onto the disk and run the application. We
haven't seen this since the days of DOS (and some of us really
miss it). This can work because compilers in the .NET framework
embed identifiers (in the form of metadata, discussed below) into
compiled modules, and the CLR manages those identifiers
automatically. The identifiers provide all the information needed
to load and run modules, and to locate related modules.
As a great by-product, the CLR can manage multiple versions of
the same component (even a shared component), and have them run
side-by-side. The identifiers tell the CLR which version is
needed for a particular compiled module because such information
is captured at compile time. The runtime policy can be set in a
module to use the exact version of a component that was available
at compile time, to use the latest compatible version, or to
specify an exact version. The bottom line is that .NET is
intended to eradicate "DLL Hell" once and for all.
This has implications that might not be apparent at first; for
example, if a program needs to run directly from a CD (without
first running an installation program). This was not feasible in
Visual Basic after version 3, but the capability will reappear
with Visual Basic.NET.
Another significant deployment benefit in .NET is that
applications only need to install their own core logic. An
application produced in .NET will not need to install a runtime,
for example, or modules for ADO or XML. Such base functionality
will be part of the .NET Framework, which will be installed
separately and only once for each system. Those four-diskette
installs for a VB "Hello, world" program will be a thing of the
past!
Making all of this work automatically requires a sophisticated
security infrastructure. The .NET Framework captures the origin
of a piece of code, and the publisher of a module can be
identified with a public encryption key. This allows a system to
be set up so that it doesn't run untrusted software, which
provides mechanisms to block viruses like the infamous ILOVEYOU.
A method of a component, no matter how deep it is in the object
model, can demand proof of authorization to run all the way back
along the call chain that got to it.
Scalability
Since most of the system-level execution functions are
concentrated in the CLR, they can be optimized and architected to
allow a wide range of scalability for applications produced in
the .NET Framework. As with most of the other advantages of the
CLR, this one comes to all applications with little or no effort.
Memory and process management is one area where scalability can
be built in. The memory management in the CLR is self-configuring
and tunes itself automatically. Garbage Collection (reclaiming
memory that is no longer being actively used) is highly
optimized, and the CLR supports many of the component management
capabilities of MTS/COM+ (such as object pooling). The result is
that components can run faster, and thus support more users.
This has some interesting side effects. For example, the
performance and scalability differences among languages become
smaller. All languages compile to a standard byte code (IL –
the Microsoft Intermediate Language), and there is discussion
below on how the CLR executes IL. With all languages compiling
down to similar byte code, it becomes unnecessary in most cases
to look to other languages when performance is an issue. The
difference in performance among .NET languages is minor –
Visual Basic, for example, gives about the same performance as
any of the other .NET languages.
There are early-stage plans for the CLR to be available on a wide
range of devices. Eventually the vision is for .NET to be running
at all levels, from smart palm-tops all the way up to web farms.
That means the same development tools should work across the
entire range – news that will be appreciated by those who
have tried to use Windows CE development kits. Of course, this is
an ambitious plan and may be subject to changes and retractions.
Key Design Goals - Page 5
Introducing .NET
Metadata - Page 7
|
