SPEC-India

 Interoperability support (Interop)

 Migrating to .NET from existing languages and platforms has been made much easier. Especially if that environment is COM or Java. COM, Interop is built into the framework, and C# will be very familiar for those developing in Java currently. In fact, Microsoft has a migration utility to automatically migrate existing Java source code into C#.

 Common language runtime (CLR)

 This is the engine that is shared among all languages supported in .NET, including C#, VB.NET, Managed C++, J#, and others to come.
 With the help of the CLR, the developer can write base classes in VB.NET, child classes in C#, and aggregate this tree from Managed C++ (this is just one example). You choose the language during implementation.

 Base class library (BCL)

 What makes Java so appealing besides the managed environment and cross-platform support is its class library. The .NET framework takes the class library concept a step further by supporting it across any language and extensible for future platform variances. Now BCL-supported features such as remoting, string manipulation, exception handling, and collection management construct is the same from any language conforming to the CLI.

 Common type system (CTS)

 This addresses the supported data types within the framework and how they are represented in metadata format. Each supported .NET language need only support a subset of the total data type set. Typically, it will be those types used most frequently (e.g., integer, short, long, string, char, boolean, object, interface, struct, etc.)

 Simplified deployment

 Say goodbye to DLL hell and the nightmare of Windows registration. Applications can now be deployed by a simple XCOPY of the assemblies, ASP.net files, and configuration files.

 Full Web service and SOAP support

 Complexities are optionally hidden for building Web service providers and consumers in .NET. Details of the syntax and protocol surrounding XML Web services can be fully customized if needed, however. It is truly the best of both worlds.

 XML at the core

 Serialization, streaming, parsing, transforming, and schema support are only some of the “baked-in” XML features of the .NET runtime.

 Object-oriented ASP.NET

 Use script for your clients, not your server-based code! Leverage your existing OO framework from ASP.NET and enjoy improved Web application performance due to compiled server code.

A principal goal of the Microsoft .NET Framework is to make computing more secure—especially with respect to the use of mobile code and distributed systems. Most modern operating systems (including Microsoft Windows) support user-based security, allowing you to control the actions and resources to which a user has access. However, in the highly connected world resulting from the proliferation of computer networks—in particular the Internet—it’s insufficient to base security solely on the identity of a system’s user. In the interest of security, code should not automatically receive the same level of trust that you assign to the person running the code.

The .NET Framework incorporates the following two complementary security models that address many of the issues associated with user and code security:

1. Code access security (CAS)
2. Role-based security (RBS)

CAS and RBS do not replace or duplicate the security facilities provided by the underlying operating system. They are platform-independent mechanisms that provide additional security capabilities to augment and enhance the overall security of your managed solutions.

CAS uses information about the source and origin of an assembly (evidence) gathered at run time to determine which actions and resources that code from the assembly can access (permissions). The .NET Framework security policy—a hierarchical set of configurable rules—defines the mapping between evidence and permissions. The .NET Framework class library uses permission demands to protect its most important functionality from unauthorized access. A demand forces the common language runtime to ensure that code calling a protected method has a specific permission. CAS ensures that the runtime capabilities of code depend on the level of trust you place in the creator and source of the code, not the level of trust you place in the user running the code.

String objects in .NET are immutable, meaning that once created they can’t be changed. For example, if you build a String by concatenating a number of characters or smaller strings, the common language runtime (CLR) will create a completely new String object whenever you add a new element to the end of the existing string. This can result in significant overhead if your application performs frequent string manipulation.

The StringBuilder class offers a solution by providing a character buffer and allowing you to manipulate its contents without the runtime creating a new object as a result of every change. You can create a new StringBuilder object that’s empty or initialized with the content of an existing String object. You can manipulate the content of the StringBuilder object using overloaded methods that allow you to insert and append string representations of different data types. At any time, you can obtain a String representation of the current content of the StringBuilder by calling StringBuilder.ToString.

Two important properties of the StringBuilder control its behavior as you append new data: Capacity and Length. Capacity represents the size of the StringBuilder buffer, whereas Length represents the length of the buffer’s current content. If you append new data that results in the number of characters in the StringBuilder (Length) exceeding the capacity of the StringBuilder (Capacity), the StringBuilder must allocate a new buffer to hold the data. Used carelessly, this buffer reallocation can negate much of the benefit of using the StringBuilder. If you know the length of data you need to work with, or know an upper limit, you can avoid unnecessary buffer reallocation by specifying the capacity at creation time or setting the Capacity property manually. When setting the Capacity and Length properties, be aware of the following behavior:

1. If you set Capacity to a value less than the value of Length, the Capacity property throws the exception System.ArgumentOutOfRangeException.
2. If you set Length to a value less than the length of the current content, the content is truncated.
3. If you set Length to a value greater than the length of the current content, the buffer is padded with spaces to the specified length. Setting Length to a value greater than Capacity automatically adjusts the Capacity to the same value as the new Length.

 ADO.NET brings with it a number of benefits, which fall into the following categories:

Interoperability

The ability to communicate across heterogeneous environments. 

ADO.NET addresses the common data-exchange limitation by using XML as its payload data format. Since XML is text-based and simple to parse, it’s a good choice for a common, platform-independent, and transportable data format. Furthermore, because XML is nothing more than structured text, employing XML as the data format on top of the HTTP network protocol minimizes firewall-related problems. With ADO and its XML format, the clients do not have to know COM to de-serialize the packaged data. All they need is an XML parser, which is readily available in many flavors on many different platforms. The data producers and consumers need only adhere to the XML schema to exchange data among themselves

 Scalability

The ability to serve a growing number of clients without degrading system performance. 

ADO.NET has enhanced its predecessor(ADO) by growing out of the client/server model and into the distributed components model. By using disconnected datasets as the paradigm for data exchange, ADO.NET is much more scalable than its predecessors.

Productivity

The ability to quickly develop robust data access applications using ADO.NET’s rich and extensible component object model. 

ADO.NET improves developers’ productivity through its rich and extensible framework classes. Because ADO.NET framework classes are managed code, developers can inherit and extend these classes to their custom needs. If you prefer not to do this low-level legwork, you can use the Visual Studio. NET data-design environment to generate these classes for you.

Performance

An improvement over previous ADO versions due to the disconnected data model. 

Because ADO.NET is mainly about disconnected datasets, the system benefits from improved performance and scalability. The database server is no longer a bottleneck when the number of connection requests goes up. Data Providers in ADO.NET also enable implicit connection pooling, which reduces the time required to open a connection.

Metadata is machine-readable information about a resource, or “data about data.” Such information might include details on content, format, size, or other characteristics of a data source. In .NET, metadata includes type definitions, version information, external assembly references, and other standardized information.

In order for two systems, components, or objects to interoperate with one another, at least one must know something about the other. In COM, this “something” is an interface specification, which is implemented by a component provider and used by its consumers. The interface specification contains method prototypes with full signatures, including the type definitions for all parameters and return types.

Only C/C++ developers were able to readily modify or use Interface Definition Language (IDL) type definitions—not so for VB or other developers, and more importantly, not for tools or middleware. So Microsoft invented something other than IDL that everyone could use, called a type library. In COM, type libraries allow a development environment or tool to read, reverse engineer, and create wrapper classes that are most appropriate and convenient for the target developer. Type libraries also allow runtime engines, such as the VB, COM, MTS, or COM+ runtime, to inspect types at runtime and provide the necessary plumbing or intermediary support for applications to use them.

Type libraries are extremely rich in COM, but many developers criticize them for their lack of standardization. The .NET team invented a new mechanism for capturing type information. Instead of using the term “type library,” we call such type information metadata in .NET.

Before you start putting everything in cache, you need to consider the following benefits and risks.

 The benefits include

1. A reduced number of round trips to the data source, such as the database server, keeping the server resources more available for other operations.
2. An increase in the number of users supported, due to a faster response time to each user’s request.

 The risks include

1. Easily filling a computer’s memory, which is relatively small, if you put a large amount of data in cache. As the memory gets full, the performance starts to decline, eventually leading to an unacceptable response time from the server.
2. Problems in a server farm environment, when we cache information in the server’s memory, where various Web pages for the same user session may be served by different Web servers.
3. No guarantee of faster performance. It all depends on how effectively you manage objects in memory.

 In general, caching is useful when you have a large amount of relatively static information. A prime candidate for caching is product catalog information. There is little value in using SQL to search the database to retrieve the same list of products for each user who visits your Web site. It is a waste of database and network resources (assuming that the database is installed on a separate server than the Web site). You can easily store information like this in data cache. However, before you go wild and put your entire product catalog in one large XML DOM object (or DataSet object), consider this fact: Even though it is easier to get access to an object stored in memory, it is not necessarily faster to search that object.

 A prime example of this fact is the DataSet object. The ADO.NET enthusiasts love to glorify this object by focusing on its ability to provide in-memory cache of the database. They often neglect to tell their listeners about the slow performance of its search mechanism.

Implementing interoperability between application platforms involves the exchange of data. When implementing a .NET and J2EE interoperability project, you mainly confront the following three data exchange challenges.

1.  Primitive data type mappings
2.  Non-existent data types
3.  Complex data types

 All these challenges involve type compatibility and have the potential to hinder or prevent data transfer.

The details of these challenges are

1. Primitive data type mappings — You may know that the type “String” exists in both the CLR and in Java. However, this does not mean that java.lang.String in Java maps exactly to System.String in .NET. If your sample exposes java.lang.String, how do you go about mapping this to its equivalent in the CLR?
2.  Non-existent data types — How do you map data types on one platform that don’t exist in the other? For example, System.Collections.Specialized.HybridDictionary is a documented data type in the CLR, but nothing in Java resembles it in the slightest. Java contains similar examples that are not in .NET, such as Java.util.Vector.
3.  Complex data types — Your application may expose complex data types, made up of numerous or even nested primitive data types. Here you need to expose the complex data type so that the other platform can use it.

.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. 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; if any assembly is not granted the permission 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 whether 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; hence occasionally code that is ’safe’ does not pass. 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.

.NET Framework uses appdomains as a mechanism for isolating code running in a process. Appdomains can be created and code loaded into or unloaded from them independent of other appdomains. This helps increase the fault tolerance of the application, as faults or crashes in one appdomain do not affect rest of the application. Appdomains can also be configured independently with different security privileges. This can help increase the security of the application by isolating potentially unsafe code. The developer, however, has to split the application into subdomains; it is not done by the CLR.

1. Disable Session State
Disable Session State if you’re not going to use it. By default it’s on. You can actually turn this off for specific pages, instead of for every page:
<%@ Page language=”c#” Codebehind=”WebForm1.aspx.cs”
AutoEventWireup=”false” Inherits=”WebApplication1.WebForm1″
EnableSessionState=”false” %>

You can also disable it across the application in the web.config by setting the <sessionState> mode value to Off.

2. Output Buffering
Take advantage of this great feature. Basically batch all of your work on the server, and then run a Response.Flush method to output the data. This avoids chatty back and forth with the server.
<%response.buffer=true%>
Then use:
<%response.flush=true%>

3. Avoid Server-Side Validation
Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth.

4. Repeater Control Good, DataList, DataGrid, and DataView controls Bad
Asp.net is a great platform, unfortunately a lot of the controls that were developed are heavy in html, and create not the greatest scaleable html from a performance standpoint.

5. Use HTTPServerUtility.Transfer instead of Response.Redirect
Redirect’s are also very chatty. They should only be used when you are transferring people to another physical web server. For any transfers within your server, use .transfer! You will save a lot of needless HTTP requests.

6. Always check Page.IsValid when using Validator Controls
So you’ve dropped on some validator controls, and you think your good to go because ASP.net does everything for you! Right? Wrong! All that happens if bad data is received is the IsValid flag is set to false. So make sure you check Page.IsValid before processing your forms!

7. Deploy with Release Build
Make sure you use Release Build mode and not Debug Build when you deploy your site to production.

8. Turn off Tracing
It will add a lot of overhead to your application that is not needed in a production environment.
<configuration>
 <system.web>
 <trace enabled=”false” pageOutput=”false” />
 <trace enabled=”false” requestLimit=”10″ pageOutput=”false” traceMode=”SortByTime” localOnly=”true”/>
 <compilation debug=”false” />
 </system.web>
 </configuration>

9. Avoid Exceptions
Avoid throwing exceptions, and handling useless exceptions. Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications. Write your code so they don’t happen! Don’t code by exception!

10. Caching is Possibly the number one tip!
Use Quick Page Caching and the ASP.net Cache API!

Microsoft developed the .Net Compact Framework with one intention in mind : To Build application for Mobile Devices and Pocket PC. .NET Compact Framework is a subset of the full .NET Framework, the included controls have a subset of their desktop cousins’ functionality. Due to size and performance considerations, some control properties, methods and events have been omitted from .NET Compact Framework controls. With a little coding, you can implement these omitted features yourself as needed. This is because the .NET Compact Framework allows you to create your own controls by inheritance from the base control class. From this foundation, you can add your own properties, methods and events to create just the control you need.