SEMINOR ON DOTNET

Document Sample
SEMINOR ON  DOTNET Powered By Docstoc
					What is .NET?
     you’ve probably heard some of the buzz surrounding the
Microsoft   .net   framework(.net).with          that     buzz    have     come
announcements from a wide variety of language vendors indicating
support for the new initiative. The question arises:
     Why is Microsoft interested in having so many languages target
the new Environment?
     The answer lies in recognizing that most businesses do not have
the luxury of rewriting their large code base every time they want to
extend the use of their existing applications.
     Microsoft® .NET is a set of Microsoft software technologies for
connecting your world of information, people, systems, and devices. It
enables an unprecedented level of software              integration      through
the use of XML Web services: small, discrete, building-block
applications that connect to each other—as well as to other, larger
applications—via the Internet. .NET connected software delivers what
developers need to create XML Web services and stitch them together.
The benefit to individuals is seamless, compelling experiences with
information sharing.

Understanding .NET:
     Microsoft .NET expands opportunities to act on data and
communicate anywhere, anytime, on any device. .NET connected
software uses a distributed computing model and builds on open
standards like XML to connect PCs and other smart devices.
Understand the basics.
    What are XML Web Services?
   What .NET Means for Business


                       dotNet & CLR Frame Work                                1
Product Information:
     .NET    connected      software   from    Microsoft     includes   a
comprehensive family of     products—clients    that       power   smart
devices, services, servers, and tools—designed to support XML and
incorporate Internet industry standards. More....
   Microsoft Servers and .NET
   Microsoft Visual Studio® .NET
   .NET Framework

Using .NET:
     At its core, Microsoft .NET is about making technology work for
people, instead of forcing individuals to adapt to the limitations of
their computers. More ...
   What .NET Means for Business
   XML Web Services Case Studies

Developing with .NET:
     Microsoft Visual Studio .NET and Microsoft .NET Framework not
only change the way applications can be developed but also make it
possible to create new kinds of applications. More ...
   .NET and Security

XML Web Services Basics:
Summary: An overview of the value of XML Web services for
developers, with introductions to SOAP, WSDL, and UDDI. (6 printed
pages)




                     dotNet & CLR Frame Work                            2
Contents:
   What Is an XML Web Service?
   SOAP
   WSDL
   UDDI
What Is an XML Web Service?
     XML Web services are the fundamental building blocks in the
move to Distributed computing on the Internet. Open standards and
the focus on communication and collaboration among people and
applications have created an environment where XML Web services
are becoming the platform for application integration. Applications
are constructed using multiple XML Web services from various
sources that work together regardless of where they reside or how
they were implemented.
     There are probably as many definitions of XML Web Service as
there are companies building them, but almost all definitions have
these things in common:
     XML Web Services expose useful functionality to Web users
through a standard Web protocol.In most cases, the protocol used is
soap.
     XML Web services provide a way to describe their interfaces in
enough detail to allow a user to build a client application to talk to
them. This description is usually provided in an XML document
called a Web Services Description Language (WSDL) document.




                    dotNet & CLR Frame Work                         3
     XML Web services are registered so that potential users can find
them easily. This is done with Universal Discovery Description and
Integration (UDDI).
     I'll cover all three of these technologies in this article but first I
want to explain why you should care about XML Web services. One of
the primary advantages of the XML Web services architecture is that
it allows programs written in different languages on different
platforms to communicate with each other in a standards-based way.
Those of you who have been around the industry a while are now
saying, "Wait a minute! Didn't I hear those same promises from
CORBA and before that DCE? How is this any different?" The first
difference is that SOAP is      significantly less complex than earlier
approaches, so the barrier to entry for a standards-compliant SOAP
implementation is significantly lower. Paul Kulchenko maintains a
list of SOAP implementations at:
http://www.soapware.org/directory/4/implementations which at last
count contained 79 entries. You'll find SOAP implementations from
most of the big software companies, as you would expect, but you will
also find many implementations that are built and maintained by a
single developer. The other significant advantage that XML Web
services have over previous efforts is that they work with standard
Web protocols—XML, HTTP and TCP/IP. A significant number of
companies already have a Web infrastructure, and people with
knowledge and experience in maintaining         it, so again, the cost of
entry for XML Web services is significantly less than previous
technologies.


                      dotNet & CLR Frame Work                            4
     We've defined an XML Web service as a software service exposed
on the Web through SOAP, described with a WSDL file and registered
in UDDI. The next logical question is. "What can I do with XML Web
services?" The first XML Web services tended to be information
sources that you could easily incorporate into applications—stock
quotes, weather forecasts, sports scores etc. It's easy to imagine a
whole class of applications that could be built to analyze and
aggregate the information you care about and present it to you in a
variety of ways; for example, you might have a Microsoft® Excel
spreadsheet that summarizes your whole financial picture—stocks,
401K, bank accounts, loans, etc. If this information is available
through XML Web services, Excel can update it continuously. Some
of this information will be free and some might require a subscription
to the service. Most of this information is available now on the Web,
but XML Web services will make programmatic access to it easier and
more reliable.
     Exposing existing applications as XML Web services will allow
users to build new, more powerful applications that use XML Web
services as building blocks. For example, a user might develop a
purchasing application to automatically obtain price information from
a variety of vendors, allow the user to select a vendor, submit the
order and then track the shipment until it is received. The vendor
application, in addition to exposing its services on the Web, might in
turn use XML Web services to check the customer's credit, Charge
the customer's account and set up the shipment with a shipping
company.


                    dotNet & CLR Frame Work                         5
     In the future, some of the most interesting XML Web services
will support applications that use the Web to do things that can't be
done today. For example, one of the services that the Microsoft .NET
My Services project will support is a calendar service. If your dentist
and mechanic exposed their calendars through this XML Web service,
you could schedule appointments with them on line or they could
schedule appointments for cleaning and routine maintenance directly
in your calendar if you like. With a little imagination, you can
envision hundreds of applications that can be built once you have the
ability to program the Web.
     For more information on XML Web services and the applications
they will help you build, please see the MSDN Web services home
page.
SOAP
     Soap is the communications protocol for XML Web services.
When SOAP is described as a communications protocol, most people
think of DCOM or CORBA and start asking things like, "How does
SOAP do object activation?" or "What naming service does SOAP
use?" While a SOAP implementation will probably include these
things, the SOAP standard doesn't specify them. SOAP is a
specification that defines the XML format for messages—and that's
about it for the required parts of the spec. If you have a well-formed
XML fragment enclosed in a couple of SOAP elements, you have a
SOAP message. Simple isn't it?
     There are other parts of the SOAP specification that describe
how to represent program data as XML and how to use SOAP to do


                     dotNet & CLR Frame Work                         6
Remote Procedure Calls. These optional parts of the specification are
used to implement RPC-style applications where a SOAP message
containing a callable function, and the parameters to pass to the
function, is sent from the client, and the server returns a message
with the results of the executed function.
     Most     current     implementations         of   SOAP      support   RPC
applications because programmers who are used to doing COM or
CORBA applications understand the RPC style. SOAP also supports
document style applications where the SOAP message is just a
wrapper     around      an   XML     document.         Document-style      SOAP
applications are very flexible and many new XML Web services take
advantage of this flexibility to build services that would be difficult to
implement using RPC.
     The last optional part of the SOAP specification defines what an
HTTP message that contains a SOAP message looks like. This HTTP
binding is important because HTTP is supported by almost all current
OS's (and many not-so-current OS's). The HTTP binding is optional,
but almost all SOAP implementations support it because it's the only
standardized protocol for SOAP. For this reason, there's a common
misconception that SOAP requires HTTP. Some implementations
support MSMQ, MQ Series, SMTP, or TCP/IP transports, but almost
all current XML Web services use HTTP because it is ubiquitous.
Since HTTP is a core protocol of the Web, most organizations have a
network     infrastructure    that   supports      HTTP    and    people    who
understand how to manage it already. The security,monitoring, and
load-balancing infrastructure for HTTP are readily available today.


                        dotNet & CLR Frame Work                              7
     A major source of confusion when getting started with SOAP is
the difference between the SOAP specification and the many
implementations of the SOAP specification. Most people who use
SOAP don't write SOAP messages directly but use a SOAP toolkit to
create and parse the SOAP messages. These toolkits generally
translate function calls from some kind of language to a SOAP
message. For example, the Microsoft SOAP Toolkit 2.0 translates
COM function calls to SOAP and the Apache Toolkit translates JAVA
function calls to SOAP. The types of function calls and the datatypes
of the parameters supported vary with each SOAP implementation so
a function that works with one toolkit may not work with another.
This isn't a limitation of SOAP but rather of the particular
implementation you are using.
     By far the most compelling feature of SOAP is that it has been
implemented on many different hardware and software platforms.
This means that SOAP can be used to link disparate systems within
and without your organization. Many attempts have been made in the
past to come up with a common communications protocol that could
be used for systems integration, but none of them have had the
widespread adoption that SOAP has. Why is this? Because SOAP is
much smaller and simpler to implement than many of the previous
protocols. DCE and CORBA for example took years to implement, so
only a few implementations were ever released. SOAP, however, can
use existing XML Parsers and HTTP libraries to do most of the hard
work, so a SOAP implementation can be completed in a matter of




                    dotNet & CLR Frame Work                        8
months. This is why there are more than 70 SOAP implementations
available.
     SOAP obviously doesn't do everything that DCE or CORBA do,
but the lack of complexity in exchange for features is what makes
SOAP so readily available.
     The ubiquity of HTTP and the simplicity of SOAP make them an
ideal basis for implementing XML Web services that can be called
from almost any environment. For more information on SOAP, see the
MSDN SOAP home page.
What about Security?
     One of the first questions newcomers to SOAP ask is how does
SOAP deal with security.Early in its development, SOAP was seen as
an HTTP-based protocol so the assumption was made that HTTP
security would be adequate for SOAP. After all, there are thousands
of Web applications running today using HTTP security so surely this
is adequate for SOAP. For this reason, the current SOAP standard
assumes security is a transport issue and is silent on security issues.
     When SOAP expanded to become a more general-purpose
protocol running on top of a number of transports, security became a
bigger   issue.   For    example,    HTTP    provides   several   ways   to
authenticate which user is making a SOAP call, but how does that
identity get propagated when the message is routed from HTTP to an
SMTP transport? SOAP was designed as a building-block protocol, so
fortunately, there are already specifications in the works to build on
SOAP to provide additional security features for Web services. The
WS-Security specification defines a complete encryption system.


                        dotNet & CLR Frame Work                          9
WSDL:
     WSDL (often pronounced whiz-dull) stands for Web Services
Description Language. For our purposes, we can say that a WSDL file
is an XML document that describes a set of SOAP messages and how
the messages are exchanged. In other words, WSDL is to SOAP what
IDL is to CORBA or COM. Since WSDL is XML, it is readable and
editable but in most cases, it is generated and consumed by software.
     To see the value of WSDL, imagine you want to start calling a
SOAP method provided by one of your business partners. You could
ask him for some sample SOAP messages and write your application
to produce and consume messages that look like the samples, but
this can be error-prone. For example, you might see a customer ID of
2837 and assume it's an integer when in fact it's a string. WSDL
specifies what a request message must contain and what the
response message will look like in unambiguous notation.
     The notation that a WSDL file uses to describe message formats
is based on the XML Schema standard which means it is both
programming-language neutral and standards-based which makes it
suitable for describing XML Web services interfaces that are
accessible from a wide variety of platforms and programming
languages. In addition to describing message contents, WSDL defines
where the service is available and what communications protocol is
used to talk to the service. This means that the WSDL file defines
everything required to write a program to work with an XML Web
service. There are several tools available to read a WSDL file and
generate the code required to communicate with an XML Web service.


                    dotNet & CLR Frame Work                        10
     Some of the most capable of these tools are in Microsoft Visual
Studio® .NET. Many current SOAP toolkits include tools to generate
WSDL files from existing program      interfaces, but there are few
tools for writing WSDL directly, and tool support for WSDL isn't as
complete as it should be. It shouldn't be long before tools to author
WSDL files, and then generate proxies and stubs much like COM IDL
tools, will be part of most SOAP implementations. At that point,
WSDL will become the preferred way to author SOAP interfaces for
XML Web services.
     An excellent description of WSDL is available, and you can find
the WSDL specification at
     http://www.w3.org/TR/wsdl.
UDDI:
     Universal Discovery Description and Integration is the yellow
pages of Web services. As with traditional yellow pages, you can
search for a company that offers the services you need, read about
the service offered and contact someone for more information. You
can,of course, offer a Web service without registering it in UDDI, just
as you can open a business in your basement and rely on word-of-
mouth advertising but if you want to reach a significant market, you
need UDDI so your customers can find you.
     A UDDI directory entry is an XML file that describes a business
and the services it offers. There are three parts to an entry in the
UDDI directory. The "white pages" describe the company offering the
service: name, address, contacts, etc. The "yellow pages" include
industrial categories based on standard taxonomies such as the


                     dotNet & CLR Frame Work                         11
North American Industry Classification System and the Standard
Industrial Classification. The "green pages" describe the interface to
the service in enough detail for someone to write an application to
use the Web service. The way services are defined is through a UDDI
document called a Type Model or tModel. In many cases, the tModel
contains a WSDL file that describes a SOAP interface to an XML Web
service, but the tModel is flexible enough to describe almost any kind
of service.
     The UDDI directory also includes several ways to search for the
services you need to build your applications. For example, you can
search for providers of a service in a specified geographic location or
for business of a specified type. The UDDI directory will then supply
information, contacts, links, and technical data to allow you to
evaluate which services meet your requirements.
     UDDI allows you to find businesses you might want to obtain
Web services from. What if you already know whom you want to do
business with but you don't know what services are offered? The WS-
Inspection specification allows you to browse through a collection of
XML Web services offered on a specific server to find which ones
might meet your needs. More information about UDDI is available at
http://www.uddi.org/about.html.

What .NET Means for Business:
     By using the Internet to enable software applications to more
easily work together, Microsoft® .NET promises easier integration
within and between businesses, while creating opportunities to more
meaningfully connect with consumers. With .NET software and


                     dotNet & CLR Frame Work                         12
services, businesses can realize improvements in the time and cost
associated     with   developing   and   maintaining   their   business
applications, as well as benefitting from empowering employees with
the ability to act on vital information anywhere, from any smart
device.
   .NET will deliver best of breed integration for businesses.
   Exposing XML Web services increases potential reach and
     exposure, creating new business opportunities.
   .NET promises substantial savings in development costs, as well
     as creating new revenue streams, through the use of XML Web
     services. Web Sites and Web Services For businesses to truly
     harness the power of the Internet, Web sites must evolve. They
     must learn to interact with one another as well as with existing
     systems and applications. XML Web services represent the
     evolution of the Web site.

.NET and Security:
     Security and privacy are a central part of creating and delivering
compelling user experiences. Distributing computing power across
numerous systems—both inside and outside the walls of your home
or company—creates new types of challenges.
     The Microsoft® .NET platform is built from the ground up with
security in mind. Coupled with good operational practices by
individuals and administrators, it provides the basis for a computing
experience that puts users in control of their personal and business
information.



                      dotNet & CLR Frame Work                        13
     The .NET Framework, the programming engine at the heart of
the .NET platform, provides the means to secure both client and
server machines through its core security features. Developers can
focus on application logic because security is handled transparently
at the core level by the common language runtime. Yet developers can
use and extend the security model at any time.

.NET Framework:
1. Common Language Runtime Architecture:
     Microsoft .NET Framework provides a Common Language
Runtime (CLR) that manages the execution of source code after being
compiled into Microsoft intermediate language (MSIL), OptIL, or
native machine code. All code based on MSIL or OptIL executes as
managed code; that is code that runs under a "contract of
cooperation" with the .NET Framework.             The.NET Framework
provides services such as memory management, cross language
integration, exception handling, code access security, and automatic
lifetime control of objects.

     A key feature of CLR is its ability to provide software isolation of
programs running within a single address space.         It does this by
enforcing typesafe access to all areas of memory when running
typesafe managed code. Some compilers generate MSIL that is not
only typesafe but whose type safety can be proven by simply
examining the MSIL.       This process, verification, allows servers to
quickly examine user programs written in MSIL and only run those
that it can demonstrate will not make unsafe memory references.


                      dotNet & CLR Frame Work                          14
This independent verification is critical to truly scalable servers that
execute user-defined programs (scripts).

The CLR provides the following services:

      Code management

      Software memory isolation

      Verification of the type safety of MSIL

      Conversion of MSIL to native code

      Loading and execution of managed code (MSIL or native)

      Accessing metadata (enhanced type information)

      Managing memory for managed objects

      Insertion and execution of security checks

      Handling exceptions, including cross-language exceptions

      Interoperation between .NET Framework objects and COM
        objects

      Automation of object layout for late binding

      Supporting developer services (profiling, debugging, etc.)

     One of the most important functions of the CLR is on-the-fly
conversion of MSIL (or OptIL) to native code. Source code compilers
generate MSIL (or OptIL), and JIT compilers convert that MSIL to
native code for specific machine architectures. As long as a simple
set of rules is followed by the MSIL generator, the same MSIL code
will run on any architecture that supports the .NET Framework.


                     dotNet & CLR Frame Work                          15
Because the conversion from MSIL to native code occurs on the target
machine, the generated native code can take advantage of hardware-
specific optimizations. Other significant CLR functions include class
loading, verification, and support for security checks.

1.1 MSIL and OptIL:

     MSIL is a stack-based set of instructions designed to be easily
generated from source code by compilers and other tools.      Several
kinds of instructions are provided, including instructions for
arithmetic and logical operations, control flow, direct memory access,
exception handling, and method invocation.

     It can also be converted efficiently into native code. The design
of MSIL allows this process to produce optimized native code at
reasonable cost. The design of MSIL allows programs that are not
typesafe to be expressed, since this is essential for support of some
common programming languages. At the same time, by following a
simple set of rules, it is possible to generate MSIL programs that are
not only typesafe but can easily be proven to be so (see the
Verification section for more information about type safety and
verification).

     OptIL is a subset of MSIL that can be generated by optimizing
compiler front ends. OptIL contains embedded annotations, which are
MSIL instructions that supply control flow and register allocation
information. Since OptIL is a subset of MSIL, any component that can
execute or analyze MSIL can also analyze or execute OptIL (ignoring
the embedded annotations if necessary). The OptJIT compiler (to be


                     dotNet & CLR Frame Work                        16
shipped in a future release), however, uses the embedded information
to rapidly produce optimized native code. The correctness of this
native code depends on the annotations, so they are subject to
verification.   OptIL is useful in situations where limited time and
memory resources are available during the conversion to native code
(ie at JIT time), yet the native code produced must meet high
performance standards.

1.2 JIT Compilation:

     The CLR provides three JIT compilers for converting MSIL to
native code: EconoJIT, JIT, and OptJIT. Each JIT compiler has been
designed to meet specific goals with respect to performance and
resource usage. The performance characteristics are summarized in
Error! Reference source not found.Error! Reference source not
found.. Because of the low overhead of the EconoJIT compiler, as
well as the ease with which it can be ported to new architectures, the
.NET Framework does not include an interpreter for MSIL. (EconoJIT
is so named because it performs the same task as the full JIT
compiler, but using less computer resources.      As a trade-off, the
quality of the generated code is not so high).




                      dotNet & CLR Frame Work                       17
    JIT             Input             JIT Compiler Compilati        Quality
    Compil          Language          Overhead         on Speed     of
    er                                                              Output

    EconoJI         MSIL       (incl. Very Small       Very Fast    Low
    T               OptIL)

    JIT             MSIL       (incl. Medium       to Moderate      High
                    OptIL)            Large

    OptJIT          OptIL only        Small            Fast         High
    (not       in
    V1)

Figure 1: Performance Characteristics of .NET Framework JIT
Compilers

1.3 Class Loading:

       The CLR’s class loader loads the implementation of a class,
expressed in MSIL, OptIL or native code, into memory, checks that it
is consistent with assumption made about it by other previously
loaded classes, and prepares it for execution. To accomplish this
task, the class loader ensures that certain information is known,
including the amount and the shape of the space that instances of
the type require.          In addition, the class loader determines whether
references made by the loaded type are available at runtime and
whether references to the loaded type are consistent.

       The class loader checks for certain consistency requirements
that     are   vital   to     the   .NET   Framework     security   enforcement


                             dotNet & CLR Frame Work                          18
mechanism.      These    checks    constitute     a   minimal,   mandatory,
verification process that precedes the MSIL verification, which is more
rigorous (and optional). In addition, the class loader supports security
enforcement by providing some of the credentials required for
validating code identity. For more details, see the Technical Review of
the CLR Virtual Object System specification.

CLR allows only one class loader, its own. The .NET Framework does
not support user-written class loaders.

1.4 Verification:

     Typesafe programs reference only memory that has been
allocated for their use, and they access objects only through their
public interfaces. These two restrictions allow objects to safely share
a single address space, and they guarantee that security checks
provided by the objects’ interfaces are not circumvented. Code access
security, the CLR’s security mechanism, can effectively protect code
from unauthorized access only if there is a way to verify that the code
is typesafe.

     To meet this need, the CLR uses the information in type
signatures to help determine whether MSIL code is typesafe.              It
checks to see that metadata is well-formed, and it performs control
flow analyses to ensure that certain structural and behavioral
conditions are met. The runtime declares that a program is
successfully verified only if it is typesafe.

  Used in conjunction with the strong typing of metadata and MSIL,
such checking can ensure the type safety of programs written in


                        dotNet & CLR Frame Work                          19
MSIL. The .NET Framework requires code to be so checked before it
is run, unless a specific (administratively controlled) security check
determines that the code can be fully trusted.

1.5 Security Checks:

     The CLR is involved in many aspects of the .NET Framework’s
security mechanism. In addition to the verification process required
by code access security, the CLR provides support that enables both
declarative and imperative security checks to occur.

     Declarative security checks take place automatically whenever a
method is called. The permissions that are required in order to access
the method are stored in the component’s metadata.       At run time,
calls to methods that are marked as requiring specific permissions
are intercepted to determine whether callers have the required
permissions.   A stack walk is sometimes necessary to determine
whether each caller in the call chain also has the required
permissions.

     Imperative security checks occur when security functions, such
as checking a code access permission, or asserting the right to use a
specified permission, are invoked from within the code being
protected. The CLR supports this type of security check by providing
trusted methods that enable code identity to be determined and allow
permissions to be located and stored in the stack. In addition, the
CLR gives the security engine access to administrative information
about security requirements.




                     dotNet & CLR Frame Work                        20
1.6 Profiling and Debugging:

     The CLR provides the ability to both debug (observe and modify
the behavior) and profile (measure resource utilization) of running
programs.     It does this by providing three underlying services,
described in detail in the Debugging Specifications and the Profiling
Specification. Both profiling and debugging depend on information
produced by the source language compiler and updated by the JIT
compiler.

     The CLR provides an API for debugging that handles registration
for and notification of events in the running program. This allows a
debugger to control execution of a program, including setting and
handling breakpoints, intercepting exceptions, modifying control flow,
and examining or modifying program state (both code and data).

     The CLR also provides an API for use by tools that do program
profiling. The API supports profiling of managed native code (e.g. the
output of a JITter) both with and without inserting specific profiling
probes into the code.

1.7 Interoperation with Unmanaged Code:

     The CLR also provides for two-way transitions between managed
and unmanaged code.       This includes interoperation with existing
COM clients and services (known as “COM Interop”) as well as
previously compiled native DLLs (known as “platform invoke”). Where
necessary because of data format or other differences, the CLR
supplies    marshaling   procedures   that    copy   and/or   reformat
information across the boundary.


                    dotNet & CLR Frame Work                         21
2. Virtual Execution System:
     By providing services such as class loading, verification, JIT
compilation, and code management, the CLR creates an environment
for code execution called the Virtual Execution System. Figure 2
shows the major elements of the CLR highlighted in gray, and it
indicates with arrows the various paths that can be taken through
this execution environment. In most cases, source code is compiled
into MSIL, the MSIL is loaded, compiled to native code on-the-fly
using one of the JIT compilers, and executed. Note that for trusted
code, verification can be omitted.

     The CLR's metadata engine enables the source code compiler to
place metadata in the PE file along with the generated MSIL or OptIL.
(“PE” stands for Portable Executable, the format used for executable
(EXE) and dynamically linked library (DLL) files). During loading and
execution, this metadata provides information needed for registration,
debugging, memory management, and security. Also indicated in the
diagram is the fact that classes from the .NET Framework class
library can be loaded by the class loader along with MSIL, OptIL, or
native code.

     Another execution path that can be chosen involves pre-
compilation to native code using a backend compiler. This option
might be chosen if compiling code at run-time (that’s to say, JIT
compiling) is unacceptable due to performance requirements. As
indicated   in   the   diagram,   precompiled    native   code   bypasses
verification and JIT compilation. Because precompiled native code is


                       dotNet & CLR Frame Work                         22
not verified, it must be considered fully trusted code in order to
execute.




Figure     2:   Overview   of   the   Common   Language   Runtime
Architecture

                     dotNet & CLR Frame Work                    23
Conclusion:
     Microsoft has taken the chance of connecting your world of
information, people, systems, and devices. It is still in its infancy, and
will emerge to be a cyber super power dominating existing
frameworks and takes Microsoft towards the winning post providing
the user’s utmost flexibility and efficacy.


References:
     www.microsoft.com
     .Net Frame Work and SDK Architecture(Developer IQ)




                      dotNet & CLR Frame Work                           24

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:48
posted:3/4/2011
language:English
pages:24
Description: SEMINOR TOPIC ON DOTNET(.NET)