.NET Framework version 4.0 ppt pdf assignment

.NET Framework version 4.0 ppt pdf assignment

click here to download for offline use 

click here to view the file 

C# and .NET Framework

Net Framework 4.0

.NET Framework version 4.0

Description

The Microsoft .NET Framework version 4.0 redistributable package (released 2010-04-12) installs the .NET Framework runtime and associated files that are required to run and develop applications to target the .NET Framework 4.

The Microsoft .NET Framework 4 provides the following new features and improvements:

• The .NET Framework 4 works side by side with the Framework version 3.5 SP1. Applications that are based on earlier versions of the Framework will continue to run on that version. Just a subset of functionality is shared by all versions of the Framework.

• Innovations in the Visual Basic and C# languages, for example statement lambdas, implicit line continuations, dynamic dispatch, and named/optional parameters.

• The ADO.NET Entity Framework, which simplifies how developers program against relational databases by raising the level of abstraction, has many new features. These includes persistence ignorance and POCO support, lazy loading, test-driven development support, functions in model, and new LINQ operators.

• Enhancements to ASP.NET:

• New JavaScript UI Templates and databinding capabilities for AJAX.
• New ASP.NET chart control.

• Improvements in WPF:

• Added support in Windows Presentation Foundation (WPF) for Windows 7 multi-touch, ribbon controls, and taskbar extensibility features.
• Added support in WPF for Surface 2.0 SDK.New line-of-business controls including charting control, smart edit, data grid, and others that improve the experience for developers who build data centric applications.
• Improvements in performance and scalability.
• Visual improvements in text clarity, layout pixel snapping, localization, and interoperability.

• Improvements to Windows Workflow (WF) that let developers to better host and interact with workflows. These include an improved activity programming model, an improved designer experience, a new flowchart modeling style, an expanded activity palette, workflow-rules integration, and new message correlation features. The .NET Framework also offers significant performance gains for WF-based workflows.

• Improvements to Windows Communication Foundation (WCF) such as support for WCF Workflow Services enabling workflow programs with messaging activities, correlation support, durable two-way communication and rich hosting capabilities. Additionally, .NET Framework 4 provides new WCF features such as service discovery, router service, simplified configuration and a number of improvements to queuing, REST support, diagnostics, and performance.

• Innovative new parallel programming features such as parallel loop support, Task Parallel Library (TPL), Parallel LINQ (PLINQ), and coordination data structures which let developers harness the power of multi-core processors.

What's New in the .NET Framework 4

This topic contains information about key features and improvements in the .NET Framework version 4. This topic does not provide comprehensive information about all new features and is subject to change.

The .NET Framework 4 introduces an improved security model. For more information, see Security Changes in the .NET Framework 4. For lists of new namespaces, new types, and new members added to existing types, see New Types and Members in the .NET Framework 4. Other new features and improvements in the .NET Framework 4 are described in the following sections:

• Application Compatibility and Deployment

• Core New Features and Improvements

• Managed Extensibility Framework

• Parallel Computing

• Networking

• Web

• Client

• Data

• Windows Communication Foundation

• Windows Workflow Foundation

The following optional updates to .NET Framework 4 are also available:

• Visual Studio 2010 Service Pack 1 (SP1), which includes an update to the .NET Framework 4.

• Update 4.0.3 for Microsoft .NET Framework 4 and earlier updates, which include several enhancements for the .NET Framework.

The changes in .NET 4.0 are largely reactive, in that they address existing problems rather than implementing new features. Over the years, the CAS model, as implemented in the pre-4.0 version of the .NET Framework, has revealed some problems which are not so trivial to solve. In particular:

All the work that must be done to setup a successful CAS Policy, that is, all the work needed to define the right PermissionSet and Code Groups for each specific machine. This discouraged a lot of administrators from implementing the technology on their systems.

·         When a specific application needs to be moved onto a different system, the different security policy applied to this new system could cause malfunctions in the application itself. For example, if an executable file was able to run properly on the developer’s machine, sometimes, when it needed to be moved on to a production server or a remote share, the same executable could suddenly stop working.

·         When developing code, it was not so easy to set up the CAS features for the assembly. This was because administrators needed to set up very different CAS policies on their machines, and the developer had to keep in mind all the possible locations their assemblies might be run, as well as what the possibly PermissionSets were. Developers had no way of knowing the administrators decisions in advance.

·         CAS policies were very useful when administrators needed to control what software could and could not do, but CAS policies had no effect at all on unmanaged code.

So, the Microsoft .NET Security Team decided to rebuild Code Access Security from the ground up. The main differences can be boiled down to:

1. All of the CAS policy system has been completely removed. Decisions about what permissions can be granted to an assembly are now taken by the host in which the assembly runs. This eliminates all problems related to CAS Policies setup.

2. The enforcement mechanism, that is, the mechanism used by the run-time to force an assembly to execute only code that has permission to execute, has been replaced by the Security Transparent model. This simplifies a lot of the work needed to set the access conditions for the resources that the assembly has to use.

The Security Transparent model was introduced in the .NET Framework 2.0 but, until the 4.0 version, it could only be used at the assembly level, and it was mainly used to prevent security transparent code from elevating privileges. In fact, Security transparent code could not even use the Assert method. In pre-4.0 versions of the .NET Framework, transparency could not be used for enforcement, as enforcement was handled by the CAS Policy system; this behavior is now called Level1 Security Transparency. With .NET Framework 4.0, these limitations have been removed and the Security Transparent model became the standard way to protect resources. The new model has been called Level2 Security Transparency, and now we’ll take a look at how it works.

The Level2 Security Transparent Model

Level2 security transparent model divides all code in three categories:  SecurityCritical code, SecurityTransparent code and SecuritySafeCritical code. Let’s see in detail what they can and cannot do:

• SecurityCritical:

SecurityCritical code is full trusted. Such code can be called by other SecurityCritical code or by SecuritySafeCritical code, but cannot be called by SecurityTransparent code.

• SecurityTransparent:

SecurityTransparent code has limited privileges on the system resources, and has no access to SecurityCritical code. Moreover, it cannot call native code nor elevate permissions.

• SecuritySafeCritical:

SecuritySafeCritical code provides a sort of bridge between SecurityTransparent code and SecurityCritical code. In fact, SecurityTransparent code can call SecuritySafeCritical code, which in turn can call SecurityCritical code. SecuritySafeCritical code is considered fully trusted, and has the same permission of the SecurityCritical code.

Note that due to the fact that SecurityTransparent code cannot call SecurityCritical code, Level2 Security Transparence became an enforcement mechanism.

Let’s start with some examples to demonstrate the model. Say we start writing a simple console application that helps us to explore the security settings of an assembly which we write. To do this, we use the following new properties of .NET Framework 4.0:

• Assembly.SecurityRuleSet:

This states which security rule is used on our assembly: Level1 Security Transparence or Level2 Security Transparence.

• Assembly.IsFullTrusted:

If true, the assembly is executing as a fully trusted assembly, and all of its methods are SecurityCritical. If false, the assembly is partially trusted, and all its methods are SecurityTransparent.

• Type.IsSecurityCritical:

If true, the object is running as SecurityCritical code.

• Type.IsSecuritySafeCritical:

If true, the object is running as SecuritySafeCritical code.

• Type.IsSecurityTransparent:

If true, the object is running as SecurityTransparent code.