CLR manages a common data type system, a
common metadata structure for describing
components, and a common security mechanism,
and also manages memory, object invocation, and so
forth. The Services Framework is a rich set of
libraries and tools developers can use to create
applications that work within a managed execution
context. The Applications Framework includes tools
for developers to create traditional Windows Forms
applications and ASP.NET.
The Common Language Runtime (CLR) is the
heart of .NET, the foundation on which all
the dreams of the programmable Web are resting for
Microsoft. It is arguably the most important move
forward for Microsoft-based development and
constitutes the single greatest paradigm shift yet
introduced for the PC. In this section CLR is
introduced with discussion on how different or
similar to the ASP/COM environment. Code that
runs within the CLR are known as "managed code."
since there is no IL compiler for Visual Basic 6.0
and Visual C++ 6.0.
The CLR offers a number of major benefits.
First, the CLR defines a common set of data types
across all CLR programming languages, allowing
for multi-language integration. This feature makes it
possible to create classes in Visual Basic .NET that
derive from classes created in C# and vice versa
(Tabor, 2003), (Kennedy, 2002). The CLR enables a
development environment with many desirable
features.
These include cross-language integration, a
strongly typed shared type system, self-describing
components, simplified deployment and versioning,
and integrated security services. Since the CLR is
used to load code, create objects, and make method
calls, it can perform security checks and enforce
policy as managed code is loaded and executed.
Code access security allows the developer to specify
the rights or permissions that a piece of code needs
in order to execute. For example, permission may be
needed to read a file or access environment settings.
This information is stored at the assembly level,
along with information about the identity of the
code, (Kennedy, 2002), (Sullivsan, 2003). The CLR
provides code-access security, which is, in essence,
mini-checkpoints your code must pass through based
on the actions it is trying to perform.
This security measure ensures that unauthorized
users cannot access resources on a machine and that
code cannot perform unauthorized actions. If the
programmers code accesses information or perform
actions on the machine it is running on (access files
on the hard drive or access the network), it must ask
the CLR if it has permission to do that. The CLR at
runtime determines the source of the code and where
it was obtained from, as well as other information
stored in the code's assembly, and grants or denies
permission to the code to perform the given task.
In addition to code access security, the runtime
supports role-based security. This builds on the same
permissions model as code access security, except
permissions are now based on user identity rather
than code identity. Roles represent categories of
users and can be defined at development time and
assigned at deployment time. Policies are defined for
each role. At runtime the identity of the user on
whose behalf the code is running is determined. The
runtime checks what roles are associated with the
user, and then grants permissions based on those
roles.
The CLR encourages moving away from scripted
languages compiled at run time to the concept of
Managed code. Managed code means a clearly
defined level of cooperation between an executing
component and the CLR itself. Responsibility for
many tasks, like creating objects and making method
calls, is delegated to the CLR, which
provides additional services to the executing
component.
Source code is compiled into Microsoft
Intermediate Language (MSIL) that is
then consumed by the CLR. In addition to MSIL,
.NET compilers also produce metadata. This is
information the CLR uses to carry out a variety of
actions such as locate and Load class types in a file,
Lay out object instances in memory, and resolve
method invocations and field references (Tabor,
2003), (Kennedy, 2002), (Sullivsan, 2003).
The CLR defines a common metadata so that
components can be self-describing; other words, no
separate type-library file or header file is necessary
because the class definition, version, and so forth
reside within the component or executable file. This
metadata is generated from the component's actual
source code, so it is never out of sync with the actual
executable file.
The metadata that the .Net Framework compliers
produce includes class definitions and configuration
information. It allows an application to totally
describe itself.
In other words, an assembly can be one physical
DLL file with one or more classes and resources, or
an assembly can have multiple DLL files, each with
one or more classes and resources. From the user-
programmer’s perspective, all the classes appear to
be packaged into the same component.
There are a number of advantages to
this approach, including how you can formulate a
security policy around assemblies, control
versioning in your components (that is, which
version of the dependent component should be used
if multiple versions are present on the system), and
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
252