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 codebehind 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 userdefined 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 Server.CreateObject(...), so early-binding and type safety are possible.

•

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 )

•

Mobile controls

•

Automatic input validation

First version January 16, 1.0 2002

April 24, 2003

1.1

released together with Visual Studio .NET

released together with Windows Server 2003 released together with Visual Studio .NET 2003

• •

November 2.0 7, 2005

codename Whidbey released together with Visual Studio 2005 and Visual Web Developer Express and SQL Server 2005

• • • • • • • • • •

New data controls (GridView, FormView, DetailsView) New technique for declarative data access (SqlDataSource, ObjectDataSource, XmlDataSource controls) Navigation controls Master pages Login controls Themes Skins Web parts Personalization services 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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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: Latest release:

Microsoft 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 o 7.2 .NET Framework 1.1  7.2.1 Changes since 1.0 o 7.3 .NET Framework 2.0  7.3.1 Changes since 1.1 o 7.4 .NET Framework 3.0 o 7.5 .NET Framework 3.5 8 .NET vs. Java and Java EE 9 Criticism 10 Alternative implementations 11 See also o 11.1 Components and Libraries 12 References 13 External links 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, exceptionbased 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 bytecode, 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 bytecode 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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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

•

7 External links

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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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

•

7 External links

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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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

•

6 External links

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 prejitter 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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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

•

11 External links

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

From Wikipedia, the free encyclopedia

Jump to: navigation, search 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

•

4 External links

• •

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 From Wikipedia, the free encyclopedia

Jump to: navigation, search 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