ASP

ASP.
NET
From Wikipedia, the free encyclopedia
Jump to: navigation, search
ASP.NET logo
ASP.NET is a set of web application development technologies marketed by Microsoft.
Programmers can use it to build dynamic web sites, web applications and XML web
services. It is part of Microsoft's .NET platform and is the successor to Microsoft's Active
Server Pages (ASP) technology.
ASP.NET is built on the Common Language Runtime, meaning programmers can write
ASP.NET code using any Microsoft .NET language.
Contents
[hide]
• 1 ASPX file format

• 2 Other files
• 3 Performance
• 4 ASP.NET compared to ASP classic
• 5 Criticisms of ASP.NET
• 6 Development tools
• 7 History
• 8 ASP.NET team members
• 9 See also
• 10 Resources about ASP.NET
• 11 Other implementations
• 12 External links
o 12.1 Microsoft
ASPX file format
ASPX is a text file format used to create Webform pages; in programming jargon, the
ASPX file typically contains static HTML or XHTML markup, as well as markup defining
Web Controls and Web User Controls where the developer places all the required static
and dynamic content for the web page. Additionally, dynamic code which runs on the
server can be placed in a page within a block <% -- dynamic code -- %> which is similar to
other web development technologies such as PHP, JSP, and ASP, but this practice is
generally discouraged except for Databinding.
The recommended method for dealing with dynamic program code is to use the code-
behind model, which places this code in a separate file or in a specially designated script
tag. Code-behind files are typically named something to the effect of MyPage.aspx.cs or
MyPage.aspx.vb based on the ASPX file name (this practice is automatic in Microsoft
Visual Studio and other IDEs). When using this style of programming, the developer
writes code to respond to different events, like the page being loaded, or a control being
clicked, rather than a procedural walk through the document.
Other files
Other file extensions associated with different versions of ASP.NET include:
• asax - Global.asax, used for application-level logic and event handling[1]

• ascx - Web UserControls: custom controls to be placed onto web pages.
• ashx - custom HTTP handlers
• asmx - web service pages.
• axd - when enabled in web.config requesting trace.axd outputs application-level tracing.
• browser - browser capabilities files stored in XML format; introduced in version 3.0. ASP.NET 2
includes many of these by default, to support common web browsers. These specify which browsers
have which capabilities, so that ASP.NET 2 can automatically customize and optimize its output
accordingly. Special .browser files are available for free download to handle, for instance, the W3C
Validator, so that it properly shows standards-compliant pages as being standards-compliant. Replaces
the harder-to-use BrowserCaps section that was in machine.config and could be overridden in
web.config in ASP.NET 1.x.
• config - web.config is the only file in a specific Web application to use this extension by default
(machine.config similarly affects the entire Web server and all applications on it), however ASP.NET
provides facilities to create and consume other config files. These are stored in XML format, so as to
allow configuration changes to be made with simplicity.
• cs/vb - In ASP.NET 2 any cs/vb files placed inside the App_Code folder are dynamically compiled and
available to the whole application.
• master - Master Pages; introduced in version 2.0
• sitemap - sitemap configuration files
• skin - theme skin files
Performance
ASP.NET aims for performance benefits over other script-based technologies ( including
ASP Classic ) by compiling the server-side code to one or a few DLL files on the web
server. This happens transparently in the background the first time a page is requested
(i.e., the developer need not perform a separate compilation step for pages). This
provides the ease of development offered by scripting languages with the performance
benefits of a compiled binary.
The ASPX and other resource files are placed in a virtual host on an Internet Information
Services (or other compatible ASP.NET servers; see Other Implementations, below). The
first time a client requests a page, the .NET framework parses and compiles the file(s)
into a .NET assembly and sends the response; subsequent requests are served from the
dll files.
Developers can also choose to pre-compile their code before deployment, eliminating the
need for just-in-time compilation in a production environment.
ASP.NET compared to ASP classic

ASP.NET attempts to simplify developers' transition from Windows application
development to web development by offering the ability to build pages composed of
controls similar to a Windows user interface. A web control, such as a button or label,
functions in very much the same way as its Windows counterpart: code can assign it
properties and respond to its events. Controls know how to render themselves: whereas
Windows controls draw themselves to the screen, web controls produce segments of
HTML and JavaScript which form part of the resulting page sent to the end-user's
browser.
ASP.NET encourages the programmer to develop applications using an event-driven GUI
paradigm (event-driven GUI model), rather than in conventional web-scripting
environments like ASP and PHP. The framework attempts to combine existing
technologies such as JavaScript with internal components like "ViewState" to bring
persistent (inter-request) state to the inherently stateless web environment.
Other differences compared to ASP classic are:
• Compiled code means applications run faster with more design-time errors trapped at the development
stage.
• Significantly improved run-time error handling, making use of exception handling using try-catch
blocks.
• Similar metaphors to Windows applications such as controls and events, which make development of
rich user interfaces, previously only found on the desktop, possible.
• An extensive set of controls and class libraries allows the rapid building of applications, plus user-
defined controls allow commonly used templates, such as menus. Layout of these controls on a page is
easier because most of it can be done visually in most editors.
• ASP.NET leverages the multi-language capabilities of the .NET CLR, allowing web pages to be coded
in VB.NET, C#, J#, etc.
• Ability to cache the whole page or just parts of it to improve performance.
• Ability to use the code-behind development model to separate business logic from presentation.
• If an ASP.NET application leaks memory, the ASP.NET runtime unloads the AppDomain hosting the
erring application and reloads the application in a new AppDomain.
• Session state in ASP.NET can be saved in a SQL Server database or in a separate process running on the
same machine as the web server or on a different machine. That way session values are not lost when the
web server is reset or the ASP.NET worker process is recycled.
• Previous versions of ASP.NET (1.0 and 1.1) were criticized for their lack of standards compliance. The
generated HTML and JavaScript sent to the client browser would not always validate against
W3C/ECMA standards. In addition, the framework's browser detection feature sometimes incorrectly
identified web browsers other than Microsoft's own Internet Explorer as "downlevel" and returned
HTML/JavaScript to these clients that was crippled or broken. However, in version 2.0, all controls
generate valid HTML 4.0, XHTML 1.0 (the default) or XHTML 1.1 output, depending on the site
configuration. Detection of standards-compliant web browsers is more robust and support for Cascading
Style Sheets is more extensive.
Criticisms of ASP.NET
Active Server Pages Classic (ASP) and ASP.NET can be run side-by-side in the same web
application. This approach allows developers to migrate applications slowly instead of all
at once. On IIS 6.0 and lower, pages written using different versions of the ASP
framework can't share Session State without the use of third-party libraries. This
criticism does not apply to ASP.NET and ASP applications running side by side on IIS 7.
With IIS 7, modules may be run in an integrated pipeline that allows modules written in
any language to be executed for any request.[2]
In some circumstances, unhandled exceptions can force the ASP.NET worker processes to
shut down. In this instance a fresh worker process is loaded, the application is restarted
and application and session state can be lost depending on the configuration. Also, if the
application relies on session state to store authentication information and the application
is configured to use in-process sessions, the user may be logged out. ASP.NET 2.0
produces markup that passes W3C validation, but it is debatable as to whether this
increases accessibility; one of the benefits of a semantic XHTML page + CSS
representation. Several controls, such as the Login controls and the Wizard control, use
HTML tables for layout by default. (Microsoft has now gone some way to solve this
problem by releasing the ASP.NET 2.0 CSS Control Adapters, a free add-on that produces
compliant accessible XHTML+CSS markup.) However, some controls still rely on
JavaScript. The CSS Control Adapters do help override output, even if it is to improve
HTML, not CSS.
Development tools
Several available software packages exist for developing ASP.NET applications:
• Microsoft Expression Web Designer (available now), part of the forthcoming Microsoft Expression
Studio application suite.
• Visual Studio .NET or Visual Studio 2005 or Visual Web Developer 2005 Express Edition (for ASP.NET
2.0)
• ASP.NET Web Matrix (ASP.NET 1.x only, was free, now no longer supported: replaced by the free
Visual Web Developer 2005 Express Edition)
• Macromedia Dreamweaver MX, Macromedia Dreamweaver MX 2004, or Macromedia Dreamweaver 8
(doesn't support ASP.NET 2.0 features, and produces very inefficient code for ASP.NET 1.x: also, code
generation and ASP.NET features support through version 8.0.1 was little if any changed from version
MX: version 8.0.2 does add changes to improve security against SQL injection attacks)
• Macromedia HomeSite 5.5 (For ASP Tags)
• Microsoft SharePoint Designer 12
• Delphi 2006
• MonoDevelop (Free/Open Source)
• SharpDevelop (Free/Open Source)
History
Date Version Remarks New features
• Object oriented web application development supporting

Inheritance, Polymorphism and other standard OOP
features
o Developers are no longer forced to use
First version
Server.CreateObject(...), so early-binding and
January 16, released together type safety are possible.
1.0
2002 with Visual Studio
.NET • Based on Windows programming; the developer can
make use of dll class libraries and other features of the
web server to build more robust applications that do
more than simply rendering html ( i.e. exception handling
)
released together with
Windows Server 2003 • Mobile controls
April 24,
1.1 released together
2003
with Visual Studio • Automatic input validation
.NET 2003
• New data controls (GridView, FormView, DetailsView)
• New technique for declarative data access
(SqlDataSource, ObjectDataSource, XmlDataSource
controls)
codename Whidbey • Navigation controls
released together • Master pages
with Visual Studio • Login controls
November 2005 and Visual • Themes
2.0
7, 2005 Web Developer • Skins
Express • Web parts
and SQL Server • Personalization services
2005 • Full pre-compilation
• New localization technique
• Support for 64-bit processors
Provider class model

•
On January 23, 2007, Microsoft released version 1.0 of ASP.NET AJAX, an extension for
ASP.NET.
ASP.NET team members

Various ASP.NET team members maintain blogs. Here are some of them:
• Scott Guthrie, General Manager - http://weblogs.asp.net/scottgu

• Nikhil Kothari, Architect - http://www.nikhilk.net
• Brian Goldfarb, Product Manager - http://blogs.msdn.com/bgold
• Shanku Niyogi, Product Unit Manager - http://www.shankun.com
• Bertrand Le Roy, Developer - http://weblogs.asp.net/bleroy
• Harish Ranganathan, Developer Evangelist - http://geekswithblogs.net/ranganh
See also
• Active Server Pages (ASP) – ASP.NET's predecessor
• ASP master pages
• Yellow Screen of Death – ASP.NET's Exception page
• Java Server Faces (JSF) – web application technology with a similar component based approach for the
Java plattform
• ASP.NET AJAX – Extension for AJAX enabled ASP.NET pages
Resources about ASP.NET

• Pro ASP.NET 2.0 in C# 2005, Matthew MacDonald, Apress, November 27, 2005. ISBN 1-59059-496-7
• ASP.NET 2.0 Unleashed, Stephen Walther, Sams Publishing, June 6, 2006. ISBN 0-672-32823-2
• Essential ASP.NET With Examples in C#, Fritz Onion, Addison-Wesley Professional, February 11, 2003.
ISBN 0-201-76040-1
• Programming ASP.NET, Jessy Liberty & Dan Hurwitz, O'Reilly, October, 2005. ISBN 0-596-00916-X
• ASP.NET 2.0 Website Programming, Marco Bellinaso, Wrox, May, 2006. ISBN 0-7645-8464-2
Other implementations
• Mono - An open source .NET Framework implementation that runs on many platforms
• UltiDev Cassini Web Server - A free web server that can be redistributed with ASP.NET 1.1 and 2.0
applications
.NET Framework

This article or section does not adequately cite its references or sources.
Please help improve this article by adding citations to reliable sources. (help, get involved!)
Any material not supported by sources may be challenged and removed at any time. This article has been tagged since January 2007.
.NET Framework
Developer: Microsoft
Latest release: Version 3.0 / November 6, 2006
OS: Windows XP SP2 and above
Use: System platform
License: Proprietary software
Website: www.microsoft.com/net/
The Microsoft .NET Framework is a software component that can be added to the
Microsoft Windows operating system. It provides a large body of pre-coded solutions to
common program requirements, and manages the execution of programs written
specifically for the framework. The .NET Framework is a key Microsoft offering, and is
intended to be used by most new applications created for the Windows platform.
The pre-coded solutions form the framework's class library cover a large range of
programming needs in areas including: user interface, data access, database
connectivity, cryptography, web application development, numeric algorithms, and
network communications. The functions of the class library are used by programmers
who combine them with their own code to produce applications.
Programs written for the .NET Framework execute in a software environment that
manages the program's runtime requirements. This runtime environment, which is also a
part of the .NET Framework, is known as the Common Language Runtime (CLR). The CLR
provides the appearance of an application virtual machine, so that programmers need
not consider the capabilities of the specific CPU that will execute the program. The CLR
also provides other important services such as security mechanisms, memory
management, and exception handling. The class library and the CLR together compose
the .NET Framework. The framework is intended to make it easier to develop computer
applications and to reduce the vulnerability of applications and computers to security
threats.
First released in 2002, it is included with Windows Server 2003 and Windows Vista, and
can be installed on most older versions of Windows.
Contents
[hide]
• 1 Significance
• 2 Rationale
• 3 Design goals and principal features
• 4 .NET Framework architecture
o 4.1 Common Language Infrastructure (CLI)
o 4.2 Assemblies
o 4.3 Metadata
o 4.4 Base Class Library (BCL)
• 5 Security
• 6 Standardization and licensing
• 7 Versions
o 7.1 .NET Framework 1.0
 7.2.1 Changes since 1.0
 7.3.1 Changes since 1.1
• 8 .NET vs. Java and Java EE
• 9 Criticism
• 10 Alternative implementations
• 11 See also
o 11.1 Components and Libraries
• 12 References
o 13.1 Microsoft
o 13.2 Other
Significance
For software developers, the .NET Framework is a significant change. It brings into the
operating system features and responsibilities that previously had been provided
individually by programming languages and tools from various sources. The
incorporation of the features into the operating system is meant to provide a number of
advantages, including:
• Assuring the availability of framework features to all programs written in any of the .NET languages.
• Providing to programmers a common means of accessing framework features, regardless of

programming language.
• Guarantees of a common behavior within the framework, regardless of programming language.
• Allowing the operating system to provide some guarantees of program behavior that it otherwise could
not offer.
• Reducing the complexity and limitations of program-to-program communication, even when those
programs are written in different .NET languages.
Rationale
Microsoft believes that the creation of the .NET Framework reflects what has been
learned over the years about the typical challenges that programmers face and useful
approaches to those challenges.
Individual programming languages and tools led the way in proving the viability of
features such as strong data typing, garbage-collected memory management, exception-
based error handling, virtual machine architectures, and comprehensive class libraries.
Visual Basic, Powerbuilder, the C++ Standard Template Library (STL), and other
languages each implemented at least some of these features, but the Java language and
its frameworks J2SE and J2EE became the most notable competitive threat to
Microsoft[citation needed]. After failed attempts (due to copyright issues[1][2]) to include a
modified form of Java with Windows, Microsoft set out to create its own products that
incorporated the best features of Java and other languages. The effort resulted in the
Microsoft .NET Framework and its accompanying programming languages and tools.
Design goals and principal features

The .NET Framework was designed with several intentions:
• Interoperability - Because interaction between new and older applications is commonly required, the
.NET Framework provides means to access functionality that is implemented in programs that execute
outside the .NET environment. Access to COM components is provided in the EnterpriseServices
namespace of the framework, and access to other functionality is provided using the P/Invoke feature.
• Common Runtime Engine - Programming languages on the .NET Framework compile into an
intermediate language known as the Common Intermediate Language, or CIL; Microsoft's
implementation of CIL is known as Microsoft Intermediate Language, or MSIL. In Microsoft's
implementation, this intermediate language is not interpreted, but rather compiled in a manner known as
just-in-time compilation (JIT) into native code. The combination of these concepts is called the Common
Language Infrastructure (CLI), a specification; Microsoft's implementation of the CLI is known as the
Common Language Runtime (CLR).
• Language Independence - The .NET Framework introduces a Common Type System, or CTS. The
CTS specification defines all possible datatypes and programming constructs supported by the CLR and
how they may or may not interact with each other. Because of this feature, the .NET Framework
supports development in multiple programming languages. This is discussed in more detail in the .NET
languages section below.
• Base Class Library - The Base Class Library (BCL), sometimes referred to as the Framework Class
Library (FCL), is a library of types available to all languages using the .NET Framework. The BCL
provides classes which encapsulate a number of common functions, including file reading and writing,
graphic rendering, database interaction and XML document manipulation.
• Simplified Deployment - Installation of computer software must be carefully managed to ensure that it
does not interfere with previously installed software, and that it conforms to increasingly stringent
security requirements. The .NET framework includes design features and tools that help address these
requirements.
• Security - .NET allows for code to be run with different trust levels without the use of a separate
sandbox.
The design of the .NET Framework is such that it supports platform independence. That
is, a program written to use the framework should run without change on any type of
computer for which the framework is implemented. At present, Microsoft has
implemented the full framework only on the Windows operating system. Microsoft and
others have implemented portions of the framework on non-Windows systems, but to
date those implementations are neither complete nor widely used.
.NET Framework architecture
Visual overview of the Common Language Infrastructure (CLI)
Common Language Infrastructure (CLI)
Main article: Common Language Infrastructure

The most important component of the .NET Framework lies in the Common Language
Infrastructure, or CLI. The purpose of the CLI is to provide a language-agnostic
platform for application development and execution, including, but not limited to,
components for exception handling, garbage collection, security, and interoperability.
Microsoft's implementation of the CLI is called the Common Language Runtime, or CLR.
The CLR is composed of five primary parts:
• Common Type System (CTS)

• Common Language Specification (CLS)
• Common Intermediate Language (CIL)
• Just-in-Time Compiler (JIT)

• Virtual Execution System (VES)
Assemblies
Main article: .NET assembly

The intermediate MSIL code is housed in .NET assemblies, which for the Windows
implementation means a Portable Executable (PE) file (EXE or DLL). Assemblies are the
.NET unit of deployment, versioning and security. The assembly consists of one or more
files, but one of these must contain the manifest, which has the metadata for the
assembly. The complete name of an assembly contains its simple text name, version
number, culture and public key token; it must contain the name, but the others are
optional. The public key token is generated when the assembly is created, and is a value
that uniquely represents the name and contents of all the assembly files, and a private
key known only to the creator of the assembly. Two assemblies with the same public key
token are guaranteed to be identical. If an assembly is tampered with (for example, by
hackers), the public key can be used to detect the tampering.
Metadata
Main article: .NET metadata

All CIL is self-describing through .NET metadata. The CLR checks on metadata to ensure
that the correct method is called. Metadata is usually generated by language compilers
but developers can create their own metadata through custom attributes.
Base Class Library (BCL)
Main article: Base Class Library

The Base Class Library (BCL), sometimes incorrectly referred to as the Framework Class
Library (FCL) (which is a superset including the Microsoft.* namespaces), is a library of
classes available to all languages using the .NET Framework. The BCL provides classes
which encapsulate a number of common functions such as file reading and writing,
graphic rendering, database interaction, XML document manipulation, and so forth. The
BCL is much larger than other libraries, but has much more functionality in one package.
Security
.NET has its own security mechanism, with two general features: Code Access Security
(CAS), and validation and verification. Code Access Security is based on evidence that is
associated with a specific assembly. Typically the evidence is the source of the assembly
(whether it is installed on the local machine, or has been downloaded from the intranet
or Internet). Code Access Security uses evidence to determine the permissions granted
to the code. Other code can demand that calling code is granted a specified permission.
The demand causes the CLR to perform a call stack walk: every assembly of each
method in the call stack is checked for the required permission and if any assembly is
not granted the permission then a security exception is thrown.
When an assembly is loaded the CLR performs various tests. Two such tests are
validation and verification. During validation the CLR checks that the assembly contains
valid metadata and CIL, and it checks that the internal tables are correct. Verification is
not so exact. The verification mechanism checks to see if the code does anything that is
'unsafe'. The algorithm used is quite conservative and hence sometimes code that is
'safe' is not verified. Unsafe code will only be executed if the assembly has the 'skip
verification' permission, which generally means code that is installed on the local
machine.
Standardization and licensing

In August 2000, Microsoft, Hewlett-Packard, and Intel worked to standardise CLI and the
C# programming language. By December 2001, both were ratified ECMA standards
(ECMA 335 and ECMA 334). ISO followed in April 2003 (ISO/IEC 23271 and ISO/IEC
23270).
While Microsoft and their partners hold patents for CLI and C#, ECMA and ISO requires
that all patents essential to implementation be made available under "reasonable and
non-discriminatory (RAND) terms." In addition to meeting these terms, the companies
have agreed to make the patents available royalty-free.
However, this does not apply for the part of the .NET Framework which is not covered by
the ECMA/ISO standard, which includes Windows Forms, ADO.NET, and ASP.NET. Patents
that Microsoft holds in these areas may deter non-Microsoft implementations of the full
framework.
Versions
Microsoft started development on the .NET Framework in the late 90s originally under
the name of Next Generation Windows Services (NGWS). By late 2000 the first beta
versions of .NET 1.0 were being released.
Version Name Version Number Release Date
1.0 Beta 1 1.0.????.0 2000-11
1.0 Beta 2 1.0.2914.0 2001-06-20
1.0 RTM 1.0.3705.0 2002-01-05
1.0 SP1 1.0.3705.209 2002-03-19
1.0 SP2 1.0.3705.288 2002-08-07
1.0 SP3 1.0.3705.6018 2004-08-31
1.1 RTM 1.1.4322.573 2003-04-01
1.1 SP1 1.1.4322.2032 2004-08-30
1.1 SP1 (Windows Server 2003 Version) 1.1.4322.2300 2005-03-30

2.0 RTM 2.0.50727.42 2005-11-07
3.0 RTM 3.0.4506.30 2006-11-06
.NET Framework 1.0
This is the first release of the .NET Framework that was released on February 13, 2002. It
is available on its own as a redistributable package or in a software development kit. It is
also part of the first release of Microsoft Visual Studio .NET (also known as Visual Studio
.NET 2002).
.NET Framework 1.1
This is the first major .NET Framework upgrade. It is available on its own as a
redistributable package or in a software development kit. It is also part of the second
release of Microsoft Visual Studio .NET (released as Visual Studio .NET 2003). This is the
first version of the .NET Framework to be included as part of the Windows operating
system - it is part of Windows Server 2003. Windows Server 2003 originally shipped with
the 1.1 RTM version.
[edit] Changes since 1.0
• Built-in support for mobile ASP.NET controls. Previously available as an add-on for .NET Framework,
now part of the framework.
• Security changes - enable Windows Forms assemblies to execute in a semi-trusted manner from the
Internet, and enable Code Access Security in ASP.NET applications.
• Built-in support for ODBC and Oracle databases. Previously available as an add-on for .NET
Framework 1.0, now part of the framework.
• .NET Compact Framework - a version of the .NET Framework for small devices.
• Internet Protocol version 6 (IPv6) support.
• Numerous API changes.
.NET Framework 2.0
Released with Visual Studio .NET 2005, Microsoft SQL Server 2005 and BizTalk 2006.
• The 2.0 Redistributable Package can be downloaded for free from Microsoft.
• The 2.0 Software Development Kit (SDK) can be downloaded for free from Microsoft.
• It is included as part of Visual Studio 2005 and Microsoft SQL Server 2005.
• Version 2.0 is the last version with support for Windows 2000
.NET Framework 2.0 shipped with Windows Server 2003 R2 (not installed by default).
[edit] Changes since 1.1

• Numerous API changes.
• A new hosting API for native applications wishing to host an instance of the .NET runtime. The new API
gives a fine grain control on the behavior of the runtime with regards to multithreading, memory
allocation, assembly loading and more (detailed reference). It was initially developed to efficiently host
the runtime in Microsoft SQL Server, which implements its own scheduler and memory manager.
• Full 64-bit support for both the x64 and the IA64 hardware platforms.
• Language support for Generics built directly into the .NET CLR.
• Many additional and improved ASP.NET web controls.
• New data controls with declarative data binding.
• New personalization features for ASP.NET, such as support for themes, skins and webparts.
• .NET Micro Framework - a version of the .NET Framework related to the Smart Personal Objects
Technology initiative more....
.NET Framework 3.0
Architecture of the .NET Framework 3.0

.NET Framework 3.0, formerly called WinFX,[3] includes a new set of managed code
APIs that are an integral part of Windows Vista and Windows Server "Longhorn" operating
systems. It is also available for Windows XP SP2 and Windows Server 2003 as a
download. There are no major architectural changes included with this release; .NET
Framework 3.0 includes version 2.0 of the Common Language Runtime. The .NET 3.0
installer available from Microsoft checks to see if .NET 2.0 is already installed. If not, it
installs it and then installs .NET 3.0 components. Otherwise it just installs .NET 3.0
components. This means that if you do not have .NET 2.0 installed, you do not need to
install it; you can install .NET 3.0 straight away. .NET 1.1 and its service-pack, however,
must be installed separately, preferably before installing .NET 3.0.[4]
.NET Framework 3.0 consists of four major new components:
• Windows Presentation Foundation (WPF), formerly code-named Avalon; a new user interface
subsystem and API based on XML and vector graphics, which uses 3D computer graphics hardware and
Direct3D technologies. See WPF SDK for developer articles and documentation on WPF.
• Windows Communication Foundation (WCF), formerly code-named Indigo; a service-oriented
messaging system which allows programs to interoperate locally or remotely similar to web services.
• Windows Workflow Foundation (WF) allows for building of task automation and integrated
transactions using workflows.
• Windows CardSpace (WCS), formerly code-named InfoCard; a software component which securely
stores a person's digital identities and provides a unified interface for choosing the identity for a
particular transaction, such as logging in to a website.
.NET Framework 3.5
This article or section contains information about scheduled or expected future software.
The content may change dramatically as the software release approaches and more information becomes available.
In an interview with Channel 9, Jason Zander, general manager of the .NET Framework
team at Microsoft, discussed the version of the framework that will follow version 3.0.[5]
Tentatively titled "version 3.5", this version will include a new compiler that will support
new features such as Language Integrated Query (LINQ), as well as new language
features in C# and VB.NET. This version of the framework is slated to be included with
the version of Visual Studio following the 2005 release (Codenamed Orcas).
.NET vs. Java and Java EE

See also: Comparison of C# and Java
The CLI and C# have many similarities to Sun's JVM and Java. They are strong
competitors. Both are based on a virtual machine model that hides the details of the
computer hardware on which their programs run. Both use their own intermediate byte-
code, Microsoft calling theirs Common Intermediate Language (CIL; formerly MSIL) and
Sun Java bytecode. On .NET, the byte-code is always JIT-compiled: with Java, the byte-
code can be either interpreted or JIT-compiled. Both provide extensive class libraries that
address many common programming requirements, and both address many security
issues that are present in other approaches. The namespaces provided in the .NET
Framework closely resemble the platform packages in Java EE API Specification both in
style and invocation.
.NET in its complete form (Microsoft's implementation) is currently only fully available on
Windows platforms, whereas Java is fully available on many platforms. .NET was built
from the ground-up to support multiple programming languages while targeting Microsoft
Windows, while the Java platform was initially built to support only the Java language on
many operating system platforms under the slogan, "Write once, run anywhere."
Microsoft's reference implementation of .NET is closed source, whereas Sun's reference
implementation of Java is becoming open source (including the class library, the
compiler, the virtual machine, and the various tools associated with the Java Platform).
However, the third-party Mono project is developing an open source implementation of
subsets of the .NET Framework, including the Common Language Runtime, for the Linux,
Solaris, Mac OS, and Windows platforms. The current version supports version 1.1 of
.NET,[6] and the project is planning full support for 2.0. Meanwhile, the Java Virtual
Machine environment is host to many alternative languages not supported by Sun.
Criticism
Some concerns and criticisms relating to the .NET Framework include:
• With the introduction of the .NET framework, the old Visual Basic language was replaced by the Visual
Basic .NET language, which caused controversy among transitioning developers.
• Several backward and forward incompatibilities exist between .NET 1.0, .NET 1.1, and .NET. These are
well-documented however, and mostly include security fixes,[7] changes in the underlying
implementation (such as the GetHashCode() implementation),[8] as well as marking many methods as
Obsolete.[9] Additionally, the framework allows running different versions side-by-side, to alleviate
problems of version incompatibility.[10]
• Applications running in a managed environment such as the Microsoft framework's CLR or Java's JVM
tend to require more system resources than functionally similar applications that access machine
resources more directly. However, some applications have been shown to perform better in .NET than in
their native version. This could be due to the use of relatively well-performing functions in the .NET
framework, JITting of managed code, or other aspects of the CLR.[11][12]
• Although it is more a business decision than a real criticism on the framework, some people have
expressed concern that the framework is too much tied to the Microsoft Windows operating system.[13]
However, the existence of alternative implementations for other platforms (though not yet complete)
begin to alleviate this criticism.
• There is also concern in the development community about the fact that a .NET assembly, as produced
by the .NET programming environments, can be reverse-engineered to reveal some of the programming
techniques and algorithms used by an application. While this kind of reverse-engineering is possible
with all programs, those that compile to byte-code, as .NET and Java do, are somewhat more vulnerable.
Reverse engineering can lead to the loss of trade secrets and the bypassing of license control
mechanisms. Some developers are using obfuscation and other techniques in an attempt to protect their
intellectual property and license revenues. Indeed Microsoft includes a tool called the "dotfuscator
community edition" - a product of PreEmptive Solutions, in the full version of Visual Studio 2005.
• Microsoft has applied for patents on some parts of the Framеwork.[14] An agreement was made however
between Microsoft and Novell whereby Microsoft agreed to not sue Novell or its customers for patent
infringement, allowing the implementation of these parts in the open-source Mono implementation of
.NET.[15][16] According to a statement on the blog of Mono project leader Miguel de Icaza,[17] this
agreement extends to Mono but only for Novell developers and users. It was criticized by the Open
source community because it violates the principles of giving equal rights to all users of a particular
program (see Patent Agreement with Microsoft). In February 2007, the Free Software Foundation
announced that it is reviewing Novell's right to sell GNU software, which makes up much of a Linux
operating system, because of this agreement.[18].However Eben Moglen later said that he was quoted out
of context,[19] and referring to possible changes that could made to the GPL version 3, that would block
similar deals in the future.
Alternative implementations
The Microsoft .NET Framework is the predominant implementation of .NET technologies.
Other implementations for parts of the framework exist. Since the runtime engine is
described by a ECMA/ISO specification, other implementations of it are unencumbered by
copyright issues. It is more difficult to develop alternatives to the base class library
(BCL), which is not described by an open standard, and may be subject to copyright
restrictions. Additionally, parts of the BCL have Windows-specific functionality and
behavior, so implementation on non-Windows platforms can be problematic.
Some alternative implementations of parts of the framework are listed here.
• Microsoft's Shared Source Common Language Infrastructure is a shared source implementation of the
CLR component of the .NET Framework. It runs on Microsoft Windows XP, FreeBSD, and Mac OS X
10.2.
• Portable.NET (part of DotGNU) provides an implementation of the Common Language Infrastructure
(CLI), portions of the .NET Base Class Library (BCL), and a C# compiler. It supports a variety of CPUs
and operating systems.
• Mono is an implementation of the CLI and portions of the .NET Base Class Library (BCL), and provides
additional functionality. It is dual-licensed under free software and proprietary software licenses. Mono
is being developed by Novell, Inc. It includes support for ASP.NET, ADO.NET, and evolving support for
Windows Forms libraries. It also includes a C# compiler, and a VB.NET compiler is in pre-beta form.
See also
Microsoft Portal
• Common Language Infrastructure

• Microsoft .NET Languages
• Mono (software)
Components and Libraries
• Base Class Library

• ADO.NET
• ASP.NET
• Windows Presentation Foundation
• Windows Communication Foundation
• Windows Workflow Foundation
• Windows CardSpace
• Microsoft Enterprise Library - A collection of supplemental libraries for .NET.
References
1. ^ Microsoft's Customer Fact Sheet on Removal of Java from Windows [1]
2. ^ Sun's Fact Sheet on Sun Microsystems v. Microsoft Private Antitrust Suit [2]
3. ^ WinFX name change announcement
4. ^ .NET Framework 3.0 Versioning and Deployment Q&A. Retrieved on 2007 March 21.
5. ^ Jason Zander on the WinFX to .NET FX 3.0 rename
6. ^ FAQ: General. Mono (2006-12-20). Retrieved on 2007 January 21.
7. ^ Backwards Breaking Changes from version 1.1 to 2.0
8. ^ http://jaysonknight.com/blog/archive/2006/02/26/7344.aspx
9. ^ Compatibility Considerations and Version Changes
10. ^ Side-by-Side Execution of the .NET Framework
11. ^ The PHP Language Compiler for the .NET Framework
12. ^ IronPython: A fast Python implementation for .NET and Mono
13. ^ see for example Bjarne Stroustrup's homepage
14. ^ .Net patent could stifle standards effort
15. ^ Microsoft and Novell Announce Broad Collaboration on Windows and Linux Interoperability and
Support>
16. ^ Mono FAQ: Licensing (Patents)
17. ^ Statement on the blog of Mono project leader Miguel de Icaza regarding patent protection for Mono
(2006-11-04). Retrieved on 2006 November 6.
18. ^ Novell could be banned from selling Linux: group
19. ^ The Free Software Foundation vs. Novell?
External links
Microsoft
• .NET Framework Developer Center. Microsoft Developer Network. Retrieved on 2006 November 21.
• Windows Vista. Microsoft Developer Network. Retrieved on 2006 November 21.
• GotDotNet. Microsoft Developer Network. Retrieved on 2006 November 21. - This web site is being
phased out and will be gone by July 2007.
• BCL Team Blog
Other
• Is .NET Taking Over? - Detailed discussion of .NET & Java

• The Code Project - Visual Studio and .NET Articles
• DotNetKicks.com A community driven source of .NET news and links
• toxicmind.de German coders of free software based on .NET Framework
.NET Framework (Microsoft)

v•d•e
[hide]
Common Type System


The Common Type System (CTS) is used by every language built on the .NET
Framework. A fundamental part of the .NET Framework is Common Language Runtime
(CLR), the CTS specifies no particular syntax or keywords, but instead defines a common
set of types that can be used with many different language syntaxes. Each language is
free to define any syntax it wishes, but if that language is built on the CLR, it will use at
least some of the types defined by the CTS. While the creator of a CLR-based language is
free to implement only a subset of the types defined by the CTS. Visual Basic.NET, C#,
and pretty much every other language used with the .NET Framework rely heavily on the
CTS.
Contents
[hide]
• 1 Overview
• 2 Why the need for a CLR and CTS?
• 3 The functions of Common Type System
• 4 Type categories
• 5 Boxing and Unboxing
• 6 See also
Overview
The CTS provides every language running on the .NET platform with a base set of data
types. While the CTS is responsible for defining the types that can be used across the
.NET languages, most languages choose to implement aliases to those types. For
example, a four-byte integer value is represented by the CTS type System.Int32. C#
defines an alias for this called type called int.
Everything in the CTS is an object. Not only is everything an object but even more
importantly, all objects implicitly derive from a single base class defined as a part of the
CTS. This base class is called System.Object. The designers of CTS were faced with the
task of creating a type system in which every thing is an object, but the type system
works in an efficient manner, when applicable.
Why the need for a CLR and CTS?

Each programming language tends to bring its own datatypes with it. For example, VB
represents strings using the BSTR struct, C++ uses arrays of char/wchar_t or the
std::string class, and Microsoft Foundation Classes uses the CString class. The int
datatype in 32-bit versions of Visual C++ is a 32-bit value where the Visual Basic integer
datatype, prior to VB.NET, is a 16-bit value.
One of the goals of the .NET platform is to make it easier for the developer to write
applications. COM developers are exposed to a headache as they need to be concerned
about GUIDs, HRESULTs, early versus Late binding, managing reference counts, the type
of threading model your component will run in, and proxy and stub layers etc.
Fortunately, some of the programming environment and frameworks such as Visual Basic
and Active Template Library come to the rescue, reducing much of this complexity. Visual
Basic, for example, automatically generates the appropriate GUIDs and manages
reference counts for Component Object Model objects used within the application. Still,
many developers will argue that Visual Basic's implementation of COM leaves a lot to be
desired. The solution has been presented in the form of creating such a system which is
common to all the languages related to this platform and so the common type system
was created.
The functions of Common Type System

• Establishes a framework that helps enable cross-language integration, type safety, and high performance
code execution.
• Provides an object-oriented model that supports the complete implementation of many programming
languages.
• Defines rules that languages must follow, which helps ensure that objects written in different languages
can interact with each other.
Type categories
The common type system supports two general categories of types:
Value types
Value types directly contain their data, and instances of value types are either allocated on the stack or
allocated inline in a structure. Value types can be built-in (implemented by the runtime), user-defined, or
enumerations.
Reference types
Reference types store a reference to the value's memory address, and are allocated on the heap.
Reference types can be self-describing types, pointer types, or interface types. The type of a reference
type can be determined from values of self-describing types. Self-describing types are further split into
arrays and class types. The class types are user-defined classes, boxed value types, and delegates.
The following example shows the difference between reference types and value types:
Imports System
Class Class1
Public Value As Integer = 0
End Class 'Class1
Class Test
Shared Sub Main()
Dim val1 As Integer = 0
Dim val2 As Integer = val1
val2 = 123
Dim ref1 As New Class1()
Dim ref2 As Class1 = ref1
ref2.Value = 123
Console.WriteLine("Values: {0}, {1}", val1, val2)
Console.WriteLine("Refs: {0}, {1}", ref1.Value, ref2.Value)
End Sub 'Main
End Class 'Test
The output of the above example
Values: 0, 123
Refs: 123, 123
Boxing and Unboxing

Boxing
convert ValueTypes to Reference Types also known as boxing. Lets see a small example
below. You see in the example I wrote "implicit boxing" which means you don't need to
tell the compiler that you are boxing Int32 to object because it takes care of this itself
although you can always make explicit boxing as seen below right after implicit boxing.
Int32 x = 10;
object o = x ; // Implicit boxing
Console.WriteLine("The Object o = {0}",o); // prints out 10
//-----------------------------------------------------------
Int32 x = 10;
object o = (object) x; // Explicit Boxing
Console.WriteLine("The object o = {0}",o); // prints out 10
Unboxing
Lets now see UnBoxing an object type back to value type. Here is a simple code that
unbox an object back to Int32 variable. First we need to box it so that we can unbox.
Int32 x = 5;
object o = x; // Implicit Boxing
x = o; // Implicit UnBoxing
See also
• .NET Framework
• Blittable Types
External links
• Microsoft developer's guide describing the CTS
• built-in types in the .NET Framework
Common Intermediate Language


Common Intermediate Language (CIL) (formerly called Microsoft Intermediate
Language or MSIL) is the lowest-level human-readable programming language in the
Common Language Infrastructure and in the .NET Framework. Languages which target
the .NET Framework compile to CIL, which is assembled into bytecode. CIL resembles an
object-oriented assembly language, and is entirely stack-based. It is executed by a
virtual machine. The primary .NET languages are C#, Visual Basic .NET, C++/CLI, and J#.
CIL was originally known as Microsoft Intermediate Language (MSIL) during the beta
releases of the .NET languages. Due to standardization of C# and the Common Language
Infrastructure, the bytecode is now officially known as CIL. Because of this legacy, CIL is
still frequently referred to as MSIL, especially by long-standing users of the .NET
languages.
Contents
[hide]
• 1 General information
• 2 Just-In-Time (JIT) Compilation
• 3 NGEN (Native Image Generator) Compilation
• 4 Metadata
• 5 Executing CIL
• 6 See also
General information
During compilation of .NET programming languages, the source code is translated into
CIL code rather than platform or processor-specific object code. CIL is a CPU- and
platform-independent instruction set that can be executed in any environment
supporting the .NET framework. CIL code is verified for safety during runtime, providing
better security and reliability than natively compiled binaries.
Just-In-Time (JIT) Compilation

Just-in-time compilation involves the byte-code being turned into code immediately
executable by the CPU. The conversion is performed gradually during the program's
execution. JIT compilation provides environment-specific optimization, runtime type
safety, and assembly verification. To accomplish this, the JIT compiler examines the
assembly metadata for any illegal accesses and handles violations appropriately.
NGEN (Native Image Generator) Compilation

NGEN produces a native binary image for the current environment. The byte-code is
either skipped entirely or converted into native CPU instructions completely before
runtime. This eliminates the JIT overhead at the expense of portability; whenever an
NGEN-generated image is run in an incompatible environment, .NET framework
automatically reverts to using JIT.
Once NGEN is run against an assembly, the resulting native image is placed into the
Global Assembly Cache for use by all other .NET assemblies. It is advised that NGEN is
run during applications' deployment.
Metadata
Metadata is information about the compiled classes. It serves the same purpose as a
type library in COM. Metadata enables applications to support and discover the
interfaces, classes, types, methods, and fields in the assembly. The process of reading
metadata is called reflection.
Executing CIL
• Source code is converted to Common Intermediate Language and an assembly is created.
• Upon execution of a .NET assembly, its CIL is passed through the Common Language Runtime's JIT
compiler to generate native code. (NGEN compilation eliminates this step at run time.)
• The native code is executed by the computer's processor.
Just-in-time compilation

For other uses, see Just In Time.
In computing, just-in-time compilation (JIT), also known as dynamic translation, is a
technique for improving the runtime performance of a computer program. It converts, at
runtime, code from one format into another, for example bytecode into native machine
code. The performance improvement originates from caching the results of translating
blocks of code, and not simply evaluating each line or operand separately (see
Interpreted language), or compiling the code at development time. JIT builds upon two
earlier ideas in run-time environments: bytecode compilation and dynamic compilation.
Contents
[hide]
• 1 Overview
• 2 History
• 3 See also
• 4 Notes
• 5 References
Overview
In a bytecode-compiled system, source code is translated to an intermediate
representation known as bytecode. Bytecode is not the machine code for any particular
computer, and may be portable among computer architectures. The bytecode is then
interpreted, or run on a virtual machine.
A dynamic compilation environment is one in which the compiler can be used during
execution. For instance, most Common Lisp systems have a compile function which can
compile new functions created during the run. While advantageous in interactive
debugging, dynamic compilation is less useful in a hands-off deployed system.
In a JIT environment, bytecode compilation is the first step, reducing source code to a
portable and optimizable intermediate representation. The bytecode is deployed onto the
target system. When code is executed, the runtime environment's compiler translates it
into native machine code. This can be done per-file, per-function or even on any arbitrary
code fragment; code can be compiled when it is about to be executed (hence the name
"just-in-time").
The goal is to combine many of the advantages of native and bytecode compilation:
Much of the "heavy lifting" of parsing the original source code and performing basic
optimization is handled at compile time, prior to deployment: compilation from bytecode
to machine code is much faster than from source. The deployed bytecode is portable,
unlike machine code for any given architecture. Compilers from bytecode to machine
code are easier to write, because the portable bytecode compiler has already done much
of the work.
This also generally offers far better performance than interpreters as the compiled code
is stored in memory cache at runtime, such that subsequent recompilation or
reinterpretation of compiled code can be skipped, while also giving flexibility to
automatically recompile and optimise code that is found at runtime to be frequently
executed.
However, JIT may have a drawback by causing a slight delay in initial execution of an
application, due to the time taken to compile the bytecode. Sometimes this delay is
called "startup time delay". In general, the more optimization JIT performs, the better
code it will generate. However, the longer delay users will experience. Therefore a well
written JIT has to make the trade-offs between the compilation time and the quality of
the code it hopes to generate.
Other advantages of a JIT runtime include:
1. The compilation can be optimized to the targeted CPU and the operating system model where the
application runs. For example JIT can choose SSE2 CPU instructions when it detects that the CPU
supports them.
2. The system is able to collect statistics about how the program is actually running in the environment it is
in, and it can rearrange and recompile for optimum performance. This data is normally difficult or even
impossible to obtain for conventional compilers.
JIT compilation is considered advantageous in many scenarios because of its portability,

flexibility and performance. The only major drawback is the startup time delay. Various
technologies exist for reducing this delay. "Native Image Generator" (Ngen.exe) by
Microsoft is one of the examples. Ngen pre-compiles (or pre-jits) bytecode in a Common
Intermediate Language image into machine native code. As a result, no runtime
compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs
Ngen.exe on all of the Microsoft library DLLs right after the installation. Pre-jitting
provides a way to improve the startup time. However, the quality of code it generates
might not be as good as the one that is jitted, for many reasons. For example, the pre-
jitter is only allowed to choose the common subset of the CPU instructions from the CPU
architectures it plans to support.
History
Dynamic translation was pioneered by the commercial Smalltalk implementation
currently known as VisualWorks, in the early 1980s; various Lisp implementations like
Emacs picked the technique up quickly.
Sun's Self language used these techniques extensively and was at one point the fastest
Smalltalk system in the world; achieving approximately half the speed of optimised C but
with a fully object-oriented language.
The HP project Dynamo was an experimental JIT compiler where the bytecode format and
the machine code format were of the same type; the system turned HPA-8000 machine
code into HPA-8000 machine code. Counterintuitively, this resulted in speed ups, in some
cases of 30% since doing this permitted optimisations at the machine code level. For
example inlining code for better cache usage and optimisations of calls to dynamic
libraries and many other run-time optimisations which conventional compilers are not
able to attempt.[1]
Self was abandoned by Sun, but the research went into the Java language, and currently
it is used by most implementations of the Java virtual machine, as HotSpot builds on, and
extensively uses, this research base.
See also
• Code generation (compiler)
• Binary translation
• HotSpot
• Common Language Runtime
• Crusoe, a microprocessor that essentially performs just-in-time compilation from x86 code to microcode
within the microprocessor
Notes
1. ^ Ars Techica on HP's Dynamo
References
• L. Peter Deutsch and Allan M. Schiffman, "Efficient Implementation of the Smalltalk-80 System", 11th
Annual Symposium on Principles of Programming Languages, Jan 1984, pp. 297-302
• Free Online Dictionary of Computing entry
External links
• GNU lightning — A library that generates assembly language code at run-time
Virtual Execution System


The Virtual Execution System(VES) provides an environment for executing managed
code. It provides direct support for a set of built-in data types, defines a hypothetical
machine with an associated machine model and state, a set of control flow constructs,
and an exception handling model.To a large extent, the purpose of the VES is to provide
the support required to execute the Common Intermediate Language instruction set.
.NET assembly

For the counterpart to assembly language in the Microsoft .NET framework, see Common Intermediate
Language.
In the Microsoft .NET framework an assembly is a partially compiled code library for use
in deployment, versioning and security. In the Microsoft Windows implementation of
.NET, an assembly is a PE (portable executable) file. There are two types, process
assemblies (EXE) and library assemblies (DLL). A process assembly represents a process
which will use classes defined in library assemblies. In version 1.1 of the CLR classes can
only be exported from library assemblies; in version 2.0 this restriction is relaxed. The
compiler will have a switch to determine if the assembly is a process or library and will
set a flag in the PE file. .NET does not use the extension to determine if the file is a
process or library. This means that a library may have either .dll or .exe as its extension.
The code in an assembly is compiled into MSIL, which is then compiled into machine
language at runtime by the CLR.
An assembly can consist of one or more files. Code files are called modules. An assembly
can contain more than one code module and since it is possible to use different
languages to create code modules this means that it is technically possible to use
several different languages to create an assembly. In practice this rarely happens,
principally because Visual Studio only allows developers to create assemblies that
consist of a single code module.
Contents
[hide]
• 1 Assembly names
• 2 Assemblies and .NET security
• 3 Private and shared assemblies
• 4 Satellite assemblies
• 5 Fusion
• 6 Referencing assemblies
• 7 Delaysigning of an assembly
• 8 Language of an assembly
• 9 See also
• 10 References
Assembly names
The name of an assembly consists of four parts:
1. The short name. On Windows this is the name of the PE file without the extension.
2. The culture. This is an RFC 1766 identifier of the locale for the assembly. In general, library and process
assemblies should be culture neutral; the culture should only be used for satellite assemblies.
3. The version. This is a dotted number made up for 4 values — major, minor, build and revision. The
version is only used if the assembly has a strong name (see below).
4. A public key token. This is a 64-bit hash of the public key which corresponds to the private key used to
sign[1] the assembly. A signed assembly is said to have a strong name.
The public key token is used to make the assembly name unique. Thus, two strong
named assemblies can have the same PE file name and yet .NET will recognize them as
different assemblies. The Windows file system (FAT32 and NTFS) only recognizes the PE
file name, so two assemblies with the same PE file name (but different culture, version or
public key token) cannot exist in the same Windows folder. To solve this issue .NET
introduces something called the GAC (Global Assembly Cache) which is treated as a
single folder by the .NET CLR, but is actually implemented using nested NTFS (or FAT32)
folders..
To prevent spoofing attacks, where a cracker would try to pass off an assembly
appearing as something else, the assembly is signed with a private key. The developer of
the intended assembly keeps the private key secret, so a cracker cannot have access to
it, and cannot guess the associated public key. Thus the cracker cannot make his
assembly impersonate something else. Signing the assembly involves taking a hash of
important parts of the assembly and then encrypting the hash with the private key. The
signed hash is stored in the assembly along with the public key. The public key will
decrypt the signed hash. When the CLR loads a strongly named assembly it will generate
a hash from the assembly and then compare this with the decrypted hash. If the
comparison succeeds then it means that the public key in the file (and hence the public
key token) is associated with the private key used to sign the assembly. This will mean
that the public key in the assembly is the public key of the assembly publisher and hence
a spoofing attack is thwarted.
Assemblies and .NET security

.NET Code Access Security is based on assemblies and evidence. Evidence can be
anything deduced from the assembly, but typically it is created from the source of the
assembly — whether the assembly was downloaded from the Internet, an intranet, or
installed on the local machine (if the assembly is downloaded from another machine it
will be stored in a sandboxed location within the GAC and hence is not treated as being
installed locally). Permissions are applied to entire assemblies, and an assembly can
specify the minimum permissions it requires through custom attributes (see .NET
metadata). When the assembly is loaded the CLR will use the evidence for the assembly
to create a permission set of one or more code access permissions. The CLR will then
check to make sure that this permission set contains the required permissions specified
by the assembly.
.NET code can perform a code access security demand. This means that the code will
perform some privileged action only if all of the assemblies of all of the methods in the
call stack have the specified permission. If one assembly does not have the permission a
security exception is thrown.
The .Net code can also perform Linked Demand for getting the permission from the call
stack. In this case the CLR will look for only one method in the call stack in the TOP
position has the specified permission. Here the stack walk through is bound to one
method in the call stack by which the CLR assumes that all the other methods in the
CALL STACK have the specified permission.
Private and shared assemblies

When a developer compiles code the compiler will put the name of every library
assembly it uses in the compiled assembly's .NET metadata. When the CLR executes the
code in the assembly it will use this metadata to locate the assembly using a technology
called Fusion. If the called assembly does not have a strong name, then Fusion will only
use the short name (the PE file name) to locate the library. In effect this means that the
assembly can only exist in the application folder, or in a subfolder, and hence it is called
a private assembly because it can only be used by a specific application. Versioning is
switched off for assemblies that do not have strong names, and so this means that it is
possible for a different version of an assembly to be loaded than the one that was used
to create the calling assembly.
The compiler will store the complete name (including version) of strongly named
assembly in the metadata of the calling assembly. When the called assembly is loaded,
Fusion will ensure that only an assembly with the exact name, including the version, is
loaded. Fusion is configurable, and so you can provide an application configuration file to
tell Fusion to use a specific version of a library when another version is requested.
Shared assemblies are stored in the GAC. This is a system-wide cache and all
applications on the machine can use any assembly in the cache. To the casual user it
appears that the GAC is a single folder, however, it is actually implemented using FAT32
or NTFS nested folders which means that there can be multiple versions (or cultures) of
the same.
Satellite assemblies
In general, assemblies should only contain culture-neutral resources. If you want to
localize your assembly (for example use different strings for different locales) you should
use satellite assemblies — special, resource-only assemblies. Satellites are not loaded by
Fusion and so they should not contain code. As the name suggests, a satellite is
associated with an assembly called the main assembly. That assembly (say, lib.dll) will
contain the neutral resources (which Microsoft says is International English, but implies
to be US English). Each satellite has the name of the associated library appended with
.resources (for example lib.resources.dll). The satellite is given a non-neutral culture
name, but since this is ignored by existing Windows file systems (FAT32 and NTFS) this
would mean that there could be several files with the same PE name in one folder. Since
this is not possible, satellites must be stored in subfolders under the application folder.
For example, a satellite with the UK English resources will have a .NET name of
"lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null", a PE file name of
lib.resources.dll, and will be stored in a subfolder called en-GB.
Satellites are loaded by a .NET class called System.Resources.ResourceManager. The
developer has to provide the name of the resource and information about the main
assembly (with the neutral resources). The ResourceManager class will read the locale of
the machine and use this information and the name of the main assembly to get the
name of the satellite and the name of the subfolder that contains it. ResourceManager
can then load the satellite and obtain the localized resource.
Fusion
Filesystems in common use by Windows (FAT32, NTFS, CDFS, etc.) are restrictive because
the names of files do not include information like versioning or localization. This means
that two different versions of a file cannot exist in the same folder unless their names
have versioning information. Fusion is the Windows loader technology that allows
versioning and culture information to be used in the name of a .NET assembly that is
stored on these filesystems. Despite being the exclusive system for loading a managed
assembly into a process, Fusion is also currently used to load Win32 assemblies
independent of managed assembly loading.
Fusion uses a specific search order when it looks for an assembly.
1. If the assembly is strongly named it will first look in the GAC.

2. Fusion will then look for redirection information in the application's configuration file. If the library is
strongly named then this can specify that another version should be loaded, or it can specify an absolute
address of a folder on the local hard disk, or the URL of a file on a web server. If the library is not
strongly named, then the configuration file can specify a subfolder beneath the application folder to be
used in the search path.
3. Fusion will then look for the assembly in the application folder with either the extension .exe or .dll.
4. Fusion will look for a subfolder with the same name as the short name (PE file name) of the assembly
and then looks for the assembly in that folder with either the extension .exe or .dll.
If Fusion cannot find the assembly, the assembly image is bad, or if the reference to the
assembly doesn't match the version of the assembly found, it will throw an exception. In
addition, information about the name of the assembly, and the paths that it checked, will
be stored. This information may be viewed by using the Fusion log viewer (fuslogvw), or
if a custom location is configured, directly from the HTML log files generated.
Referencing assemblies
One can reference an executable code library by using the /reference flag of the C#
compiler. Satellites are loaded by a .NET class called
System.Resources.ResourceManager. The developer has to provide the name of the
resource and information about the main assembly (with the neutral resources). The
ResourceManager class will read the locale of the machine and use this information and
the name of the main assembly to get the name of the satellite and the name of the
subfolder that contains it. ResourceManager can then load the satellite and obtain the
localized resource.
Delaysigning of an assembly
The shared assemblies need to give a strong name for uniquely identifying the assembly
which might be shared among the applications. The strong naming consists of the public
key token, culture, version and PE file name. If an assembly is likely to be used for the
development purpose which is a shared assembly, the strong naming procedure contains
only public key generation. The private key is not generated at that time. It is generated
only when the assembly is deployed.
Language of an assembly
The assembly is built up with the MSIL code. MSIL code is nothing but assembly language
coding. The framework internally converts the high level language code into assembly
code. If we have a program that prints "Hello world", the equivalent MSIL code is:
.method private hidebysig static void Main(string[] args) cil managed {
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 11 (0xb)
.maxstack 1
IL_0000: ldstr "Hello World"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret } // end of method Class1::Main
So the assembly code loads the String first into stack. Then it calls the Writeline function
and stores the address where the control should return after the function is over.
Base Class Library


The Base Class Library (BCL) is a library of types and functionalities available to all
languages using the .NET Framework. In order to make the programmer's job easier,
.NET includes the BCL in order to encapsulate a large number of common functions, such
as file reading and writing, graphic rendering, database interaction, and XML document
manipulation. It is much larger in scope than standard libraries for most other languages,
including C++, and would be comparable in scope to the standard libraries of Java. The
BCL is sometimes incorrectly referred to as the Framework Class Library (FCL), which is a
superset including the Microsoft.* namespaces.
The BCL is updated with each version of the .NET Framework.
Contents
[hide]
• 1 Namespaces
• 2 See also
o 2.1 Other Capabilities of the .NET Framework
• 3 References
Namespaces
Some of these namespaces may or may not be officially considered part of the BCL by
Microsoft, but all are included as part of the standard libraries that are provided with the
.NET Framework.
System
This namespace includes the core needs for programming. It includes base types like String, DateTime,
Boolean, and so forth, support for environments such as the console, math functions, and base classes
for attributes, exceptions, and arrays.
System.CodeDom
This library provides the ability to create code and run it, at runtime.
System.Collections
Defines many common containers or collections used in programming, such as lists, queues, stacks,
hashtables, and dictionaries. It includes support for generics.
System.ComponentModel
Provides the ability to implement the run-time and design-time behavior of components and controls. It
contains the infrastructure "for implementing attributes and type converters, binding to data sources, and
licensing components."[1]
System.Configuration
Provides the infrastructure for handling configuration data.
System.Data
This namespace represents the ADO.NET architecture, which is set of computer software components
that can be used by programmers to access data and data services.
System.Deployment
Allows you to customize the way your application upgrades when using ClickOnce.
System.Diagnostics
Gives you the ability to diagnose your application. It includes event logging, performance counters,
tracing, and interaction with system processes.
System.DirectoryServices
Provides easy access to Active Directory from managed code.
System.Drawing
Provides access to GDI+ graphics functionality, including support for 2D and vector graphics, imaging,
printing, and text services.
System.EnterpriseServices
"Provides .NET objects with access to COM+ services making the .NET Framework objects more
practical for enterprise applications."[2]
System.Globalization
Provides help for writing internationalized applications. "Culture-related information, including the
language, the country/region, the calendars in use, [and] the format patterns for dates, currency, and
numbers" can be defined.[3]
System.IO
Allows you to read from and write to different streams, such as files or other data streams. Also provides
a connection to the file system.
System.Management
Allows you to query for information, "such as how much free space is left on the disk, what is the
current CPU utilization, which database a certain application is connected to, and much more."[4]
System.Media
Provides you the ability to play system sounds and .wav files.
System.Messaging
Allows "you to connect to, monitor, and administer message queues on the network and send, receive, or
peek messages."[5] .NET Remoting is another name for some of the functionality provided. This
namespace is being superseded by Windows Communication Foundation.
System.Net
Provides an interface "for many of the protocols used on networks today,"[6] such as HTTP, FTP, and
SMTP. Secure communication is supported by protocols such as SSL.
System.Reflection
Provides an object view of types, methods, and fields. You have "the ability to dynamically create and
invoke types."[7]
System.Resources
Allows you to manage many different resources in the application in order to internationalize an
application for different cultures and languages.
System.Runtime
Allows you to manage the runtime behavior of an application or the CLR. Some of the included abilities
are interoping with COM or other native code, writing distributed applications, and serializing objects
into binary or SOAP.
System.Security
"Provides the underlying structure of the common language runtime security system."[8] This namespace
allows you to build security into your application based on policy and permissions. It provides services
such as cryptography.
System.ServiceProcess
Allows you to create applications that run as a service within Windows.
System.Text
Supports various encodings, regular expressions, and a more efficient mechanism for manipulating
strings (StringBuilder).
System.Threading
Helps facilitate multithreaded programming. It allows the synchronizing of "thread activities and access
to data" and provides "a pool of system-supplied threads."[9]
System.Timers
"Allows you to raise an event on a specified interval."[10]
System.Transactions
Provides support for local or distributed transactions.
System.Web
Provides various web related functionality. It enables browser-server communication and the creating
XML Web Services. Most or all of these libraries are referred to as the ASP.NET architecture.
System.Windows.Forms
This namespace contains the Windows Forms architecture which provides access to the older Windows
API for writing graphical applications for Windows from within managed code. This system is being
superseded by the Windows Presentation Foundation.
System.Xml
"Provides standards-based support for processing XML,"[11] including reading, writing, schemas,
serialization, searching, and transforming.
Code Access Security


Code Access Security (CAS), in the Microsoft .NET framework, is Microsoft's solution to
prevent untrusted code from performing privileged actions. When the CLR loads an
assembly it will obtain evidence for the assembly and use this to identify the code group
that the assembly belongs to. A code group contains a permission set (one or more
permissions). Code that performs a privileged action will perform a code access demand
which will cause the CLR to walk up the call stack and examine the permission set
granted to the assembly of each method in the call stack. If one of these assemblies is
not granted the demanded permission then a security exception is thrown and execution
stops.
The code groups and permission sets are determined by the administrator of the
machine who defines the security policy.
Contents
[hide]
• 1 Evidence
• 2 Policy
• 3 Code Group
• 4 Demands
• 5 See also
• 6 References
Evidence
Evidence can be any information associated with an assembly. The default evidences
that are used by .NET code access security are:
• URL - the complete URL where the library was downloaded from.
• Site - just the hostname of the URL.
• Zone - the defined security zones (defined by Internet Explorer).
• Hash - a hash of the assembly.
• Strong Name - isher - X.509 certificate uniquely identifying a publisher
A developer can use custom evidence (so-called assembly evidence) but this requires
writing a security assembly and in version 1.1 of .NET this facility does not work.
Evidence based on a hash of the assembly is easily obtained in code. For example in C#,
evidence may be obtained by the following code clause:
this.GetType().Assembly.Evidence
Policy
A policy is a set of expressions that uses evidence to determine a code group
membership. A code group gives a permission set for the assemblies within that group.
There are four policies in .NET:
• Enterprise - policy for a family of machines that are part of an Active Directory installation.
• Machine - policy for the current machine.
• User - policy for the logged on user.
• AppDomain - policy for the executing application domain.
The first three policies are stored in XML files and are administered through the .NET
Configuration Tool 1.1 (mscorcfg.msc). The final policy is administered through code for
the current application domain.
Code access security will present an assembly's evidence to each policy and will then
take the intersection (that is the permissions common to all the generated permission
set) as the permissions granted to the assembly.
By default, the Enterprise, User policies and AppDomain policies give full trust (that is
they allow all assemblies to have all permissions) and the Machine policy is more
restrictive. Since the intersection is taken this means that the final permission set is
determined by the Machine policy.
Code Group
Code groups associate a piece of evidence with a named permission set. The
administrator uses the .NET Configuration Tool to specify a particular type of evidence
(for example, Site) and a particular value for that evidence (for example,
www.mysite.com) and then identifies the permission set that the code group will be
granted.
Demands
Code that performs some privileged action will make a demand for one or more
permissions. The demand makes the CLR walk the call stack and for each method the
CLR will ensure that the demanded permissions are in the method's assembly's granted
permissions. If the permission is not granted then a security exception is thrown. This
prevents downloaded code from performing privileged actions. For example, if an
assembly is downloaded from an untrusted site the assembly will not have any file IO
permissions and so if this assembly attempts to access a file code access security will
throw an exception preventing the call.
External links
Wikibooks has more on the topic of

ASP.NET
• ASP.NET at the Open Directory Project (suggest site)

• ASP.NET website, tutorials and code examples
Microsoft
• Microsoft's ASP.NET 2.0 website

• ASP.NET on MSDN
• CSS friendly ASP.NET 2.0 control adapters
• Visual Web Developer Express Edition 2005
• Visual Web Developer Express Edition 2005 SP1 Download
• Microsoft Expression Web Designer (Standards-compliant css-based design)
• Webmatrix for ASP.NET
.NET Framework (Microsoft)

v•d•e
[hide]
Architecture: Common Language Infrastructure • .NET assembly • .NET metadata • Base
Class Library
Common Language Common Language Runtime • Common Type System • Common Intermediate
Infrastructure: Language • Virtual Execution System
Languages: C# • Visual Basic .NET • C++/CLI (Managed) • J# • JScript .NET • Windows
PowerShell • IronPython • F#
Windows Foundations: Presentation • Communication • Workflow • CardSpace
Related: Windows Forms • ASP.NET • ADO.NET • .NET Remoting • XAML
Other Implementations: .NET Compact Framework • .NET Micro Framework • Shared Source CLI •
Portable.NET • Mono
Comparison: C# vs. Java • C# vs. VB.NET
Retrieved from "http://en.wikipedia.org/wiki/ASP.NET"
Categories: .NET framework | .NET programming languages | Template engines | World Wide Web | Web
application frameworks | Microsoft APIs

ASP

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ASP

Загружено:

Авторское право:

Доступные форматы

ASP.

Jump to: navigation, search

• 1 ASPX file format

ASPX file format

Other file extensions associated with different versions of ASP.NET include:

• asax - Global.asax, used for application-level logic and event handling[1]

ASP.NET compared to ASP classic

Date Version Remarks New features

• Object oriented web application development supporting

Provider class model

ASP.NET team members

• Scott Guthrie, General Manager - http://weblogs.asp.net/scottgu

Resources about ASP.NET

Jump to: navigation, search

Latest release: Version 3.0 / November 6, 2006

OS: Windows XP SP2 and above

Use: System platform

License: Proprietary software

• Providing to programmers a common means of accessing framework features, regardless of

Design goals and principal features

.NET Framework architecture

Visual overview of the Common Language Infrastructure (CLI)

Common Language Infrastructure (CLI)

Main article: Common Language Infrastructure

• Common Type System (CTS)

• Just-in-Time Compiler (JIT)

Main article: .NET assembly

Main article: .NET metadata

Base Class Library (BCL)

Main article: Base Class Library

Standardization and licensing

Version Name Version Number Release Date

1.0 Beta 1 1.0.????.0 2000-11

1.0 Beta 2 1.0.2914.0 2001-06-20

1.0 RTM 1.0.3705.0 2002-01-05

1.0 SP1 1.0.3705.209 2002-03-19

1.0 SP2 1.0.3705.288 2002-08-07

1.0 SP3 1.0.3705.6018 2004-08-31

1.1 RTM 1.1.4322.573 2003-04-01

1.1 SP1 1.1.4322.2032 2004-08-30

1.1 SP1 (Windows Server 2003 Version) 1.1.4322.2300 2005-03-30

3.0 RTM 3.0.4506.30 2006-11-06

.NET Framework 1.0

.NET Framework 1.1

[edit] Changes since 1.0

.NET Framework 2.0

[edit] Changes since 1.1

.NET Framework 3.0

Architecture of the .NET Framework 3.0

.NET Framework 3.5

.NET vs. Java and Java EE

• Common Language Infrastructure

Components and Libraries

• Base Class Library

• Is .NET Taking Over? - Detailed discussion of .NET & Java

.NET Framework (Microsoft)

Common Type System

Jump to: navigation, search

Why the need for a CLR and CTS?

The functions of Common Type System

Boxing and Unboxing

Common Intermediate Language

Jump to: navigation, search