Friday, March 4, 2011

dot net basics material

http://www.informit.com/library/content.aspx?b=Net_2003_21days&seqNum=9

Day 1. Introduction to the Microsoft .NET Framework
This week you learn about the tools that Visual Studio .NET offers. You'll get a good understanding of what types of applications you can create using Visual Studio .NET. But before we get to that point, you must have a solid understanding of what the .NET Framework is and what it can do for you. Understanding the internals of the .NET Framework helps you better understand what's happening when Visual Studio .NET is helping you create applications. By the end of the day, you'll have better insight into the technologies that make up the .NET Framework, how the .NET Framework fits into Microsoft's vision of the future of computing, and how things are much different from the past.

What Is .NET?
When .NET was announced in late 1999, Microsoft positioned the technology as a platform for building and consuming Extensible Markup Language (XML) Web services. XML Web services allow any type of application, be it a Windows- or browser-based application running on any type of computer system, to consume data from any type of server over the Internet. The reason this idea is so great is the way in which the XML messages are transferred: over established standard protocols that exist today. Using protocols such as SOAP, HTTP, and SMTP, XML Web services make it possible to expose data over the wire with little or no modifications to your existing code.
Figure 1.1 presents a high-level overview of the .NET Framework and how XML Web services are positioned.

Figure 1.1 Stateless XML Web services model.
Since the initial announcement of the .NET Framework, it's taken on many new and different meanings to different people. To a developer, .NET means a great environment for creating robust distributed applications. To an IT manager, .NET means simpler deployment of applications to end users, tighter security, and simpler management. To a CTO or CIO, .NET means happier developers using state-of-the-art development technologies and a smaller bottom line. To understand why all these statements are true, you need to get a grip on what the .NET Framework consists of, and how it's truly a revolutionary step forward for application architecture, development, and deployment.
Windows of the Past
In the past, millions of applications were developed for Windows-based systems using a variety of development tools and languages. Visual Basic, C++, Delphi, Java, and Access provided a great toolset that enabled you to write applications for Windows. The problem that crept up again and again was how these applications communicated with each other and how they could communicate with data beyond the departmental server. Because each language has its own runtime environment, they all run essentially inside their own box, using their own way to communicate with core system services. There was no way to get outside the box. When a new feature to a language had to be added, it would be bolted somewhere on to the runtime environment through a new set of API calls. If you wanted to access the new features, each language had its own way of doing so. And, as was the case with Visual Basic, many features were simply not available because the runtime environment of Visual Basic couldn't support them. This problem seemed to have been solved with the Windows Distributed Internet Applications (DNA) architecture, which was based on Component Object Model (COM) components moving data between different types of distributed applications.
Windows DNA and COM
Writing distributed Internet applications became easier as the model of COM services that Windows servers could provide became more stable and widespread. You could write an Active Server Pages (ASP) application and access methods, properties, and events through the object model of components running inside of COM+ services on remote machines. Figure 1.2 shows the flow of a DNA/COM application.

Figure 1.2 DNA and COM in action.
Windows DNA became more accepted because of the ease with which a Visual Basic 6 developer could write components that could be accessed from any other type of application, as long as he had access to the Windows 2000 server that the COM+ services were running on. This is where the problems begin.
If you provide data to outside vendors in an application, you must write the user interface and code to allow them access to what they need. There's no simple way to expose methods, or allow other applications to call methods, on your servers. You have to open up security and give them the keys to the farm, which isn't what IT managers are likely to do. If you want to maintain multiple versions of a component, you are in a very bad way with COM. Because COM makes heavy use of the Registry and doesn't allow for a simple versioning policy, you're essentially maintaining the same component forever. You're constantly adding new features to it, but leaving the old stuff in. This is one of the big rules of COM: Thou shall not change any interfaces to your components. Doing so makes for a huge headache in deployment. If you change an in or out parameter on a method, you've broken the functionality of the component. That means all the components must be recompiled to restore the correct interfaces that the caller expects. After a component is deployed, how do you easily scale it across machines while maintaining any state data that the code expects? This isn't a trivial problem, and companies have spent millions of dollars writing state machines to handle the scalability problems that come with COM.
All these issues are solved with the .NET Framework. The services provided by the .NET Framework enable us to expose methods over HTTP and SOAP through XML Web services. The Windows Registry is not used in .NET, which eliminates the DLLHell of the past and gives us a strong versioning policy. There are many ways to maintain state data, so we can scale applications across processors and across servers with no worry about crashing the applications running on those servers. This all starts with the common language runtime and the base class libraries.
On Day 13, "XML Web Services in .NET," you learn more about the different protocols and messaging standards that make up anXML Web service.
The Common Language Runtime
At the heart of the .NET Framework is the common language runtime. The common language runtime is responsible for providing the execution environment that code written in a .NET language runs under. The common language runtime can be compared to the Visual Basic 6 runtime, except that the common language runtime is designed to handle all .NET languages, not just one, as the Visual Basic 6 runtime did for Visual Basic 6. The following list describes some of the benefits the common language runtime gives you:
• Automatic memory management
• Cross-language debugging
• Cross-language exception handling
• Full support for component versioning
• Access to legacy COM components
• XCOPY deployment
• Robust security model
You might expect all those features, but this has never been possible using Microsoft development tools. Figure 1.3 shows where the common language runtime fits into the .NET Framework.

Figure 1.3 The common language runtime and the .NET Framework.
Code written using a .NET language is known as managed code. Code that uses anything but the common language runtime is known as unmanaged code. The common language runtime provides a managed execution environment for .NET code, whereas the individual runtimes of non-.NET languages provide an unmanaged execution environment.
Inside the Common Language Runtime
The commonlanguage runtime enables code running in its execution environment to have features such as security, versioning, memory management, and exception handling because of the way .NET code actually executes. When you compiled Visual Basic 6 forms applications, you had the ability to compile down to native node or p-code. Figure 1.4 should refresh your memory of what the Visual Basic 6 options dialog looked like.

Figure 1.4 Visual Basic 6 compiler options dialog.
When you compile your applications in .NET, you aren't creating anything in native code. When you compile in .NET, you're converting your code—no matter what .NET language you're using—into an assembly made up of an intermediate language called Microsoft Intermediate Language (MSIL or just IL, for short). The IL contains all the information about your application, including methods, properties, events, types, exceptions, security objects, and so on, and it also includes metadata about what types in your code can or cannot be exposed to other applications. This was called a type library in Visual Basic 6 or an IDL (interface definition language) file in C++. In .NET, it's simply the metadata that the IL contains about your assembly.
The file format for the IL is known as PE (portable executable) format, which is a standard format for processor-specific execution.
When a user or another component executes your code, a process occurs called just-in-time (JIT) compilation, and it's at this point that the IL is converted into the specific machine language of the processor it's executing on. This makes it very easy to port a .NET application to any type of operating system on any type of processor because the IL is simply waiting to be consumed by a JIT compiler.
The first time an assembly is called in .NET, the JIT process occurs. Subsequent calls don't re-JIT the IL; the previously JITted IL remains in cache and is used over and over again. On Day 5, "Writing ASP.NET Applications," you learn more about the JITting process and how it can affect your ASP.NET applications. On Day 19, "Understanding Microsoft Application Center Test," when you learn about Application Center Test, you also see how the warm-up time of the JIT process can affect application performance.
Understanding the process of compilation in .NET is very important because it makes clear how features such as cross-language debugging and exception handling are possible. You're not actually compiling to any machine-specific code—you're simply compiling down to an intermediate language that's the same for all .NET languages. The IL produced by J# .NET and C# looks just like the IL created by the Visual Basic .NET compiler. These instructions are the same, only how you type them in Visual Studio .NET is different, and the power of the common language runtime is apparent.
When the IL code is JITted into machine-specific language, it does so on an as-needed basis. If your assembly is 10MB and the user is only using a fraction of that 10MB, only the required IL and its dependencies are compiled to machine language. This makes for a very efficient execution process. But during this execution, how does the common language runtime make sure that the IL is correct? Because the compiler for each language creates its own IL, there must be a process that makes sure what's compiling won't corrupt the system. The process that validates the IL is known as verification. Figure 1.5 demonstrates the process the IL goes through before the code actually executes.

Figure 1.5 The JIT process and verification.
When code is JIT compiled, the common language runtime checks to make sure that the IL is correct. The rules that the common language runtime uses for verification are set forth in the Common Language Specification (CLS) and the Common Type System (CTS).
Understanding the Common Language Specification
The CLS describes the concrete guidelines that make a .NET language compliant with the common language runtime. That doesn't mean a .NET language can't have language-specific features, but it does indicate that to be considered a .NET language, the language must comply with the set of requirements set forth in the CLS. All features added to a .NET language and that aren't part of the CLS won't be exposed to other .NET languages at runtime.
If your code is fully CLS compliant, it's guaranteed to interoperate with all other components written in any .NET language. Certain languages, such as C#, attempt to accommodate developers moving from C and C++ with the similarity of their syntaxes. Because C# attracts such developers, it includes functionality familiar from their native languages, such as pointers and code access to unsafe memory blocks. This functionality is not CLS compliant and won't be accessible by other .NET languages, but it's allowed by the common language runtime and the language-specific compilers. To make sure that your code is CLScompliant, compilers such as C# include checks for non-CLS-compliant code through the use of attributes. If you apply theCLSCompliantAttribute attribute to a class or method in your code and the code isn't CLS compliant, an error occurs and the compile fails. The following code demonstrates how to apply the CLSCompliantAttribute attribute in your code:
using System;
[assembly: CLSCompliantAttribute(true)]
[CLSCompliantAttribute(true)]
public class Class1
{
public void x(UInt32 x){}
public static void Main( )
{
}
}
In this case, the code won't compile because unsigned integers aren't part of the CLS.
The second part of the verification process that the JIT compiler goes through to make sure that your code executes correctly is the verification of types. All types used in .NET must conform to the CTS.
Understanding the Common Type System
The CTS sets forth the guidelines for data type safety in .NET.
In the past, there were no rules for type safety across execution runtimes, hence the general protection fault (GPF) and blue screen of death errors that could occur when running applications. The culprit behind those meltdowns was the overlapping of memory by data types. This was a common occurrence in Windows 3.1, Windows 95, and Windows 98. When a Visual Basic developer deployed a new application, fingers had to be crossed to make sure that the data types and memory access between the newly installed DLLs and the existing ones on the system mingled happily. Most of the time they did, but when they didn't, errors occurred.
In .NET, the CTS defines types and how they can act within the bounds of the common language runtime. There are two type classifications in .NET: value types and reference types.
Value Types
Value types directly contain the data you assign them. They're built into the common language runtime and derive directly from the base System.Object type. Examples of value types are primitive types, structures, and enumerations. Primitive types can be further broken down into numbers, such as Boolean, byte, short, integer, long, single, double, decimal, date, and char.
Reference Types
Reference types don't directly contain any data; rather, they point to a memory location that contains the actual data. Reference types are built into the common language runtime and derive directly from the base System.Object type. Some examples of reference types are strings, classes, arrays, delegates, and modules (see Figure 1.6).

Figure 1.6 The common type system defined.
To make the difference between Value types and Reference types clearer, consider the following code. It accesses a primitive type (which is a value type) and a class (which is a reference type), and attempts to assign values to them.

using System;
namespace cSharp_ValueReference
{
class Class1
{
static public int x;
[STAThread]
static void Main(string[] args)
{
x=4;
int y;
y = x;
x=0;
// Since each Value type contains its own data,
// modifying the variable X after setting Y to the value
// of X does not affect either variable
Console.WriteLine(x);
Console.WriteLine(y);

// Create an instance of Class2
Class2 ref1 = new Class2();
// Set the refValue of this instance to 5
ref1.refValue=5;

// Create an object reference to the ref1 class
Class2 ref2 = ref1;
// Set the refValue of the object
ref2.refValue=10;

// Notice how the results are the same, even
// though you set re1.refValue to 5, the reference
// to this memory was overridden by the value of 10
Console.WriteLine(ref1.refValue);
Console.WriteLine(ref2.refValue);
Console.ReadLine();
}
}

class Class2
{
public int refValue;
}
}

Module Module1

Sub Main()

Dim X As Integer = 4
Dim Y As Integer
intY = X
intX = 0
Console.WriteLine(X)
Console.WriteLine(Y)

Dim ref1 As Class2 = New Class2()
ref1.refValue = 5

Dim ref2 As Class2 = ref1
ref2.refValue = 10

Console.WriteLine(ref1.refValue)
Console.WriteLine(ref2.refValue)
Console.ReadLine()
End Sub

End Module

Class Class2
Public refValue As Integer
End Class
In both examples, the values of the value type variables X and Y are 0 and 4, whereas the values of the reference types ref1 andref2 are both 10. Because the reference type points to the same memory allocation for the initial object ref1, the value for all variables set to an instance of that object is always the last value assigned. Figure 1.7 shows the console output of the code.

Figure 1.7 Value and reference type test output.
You don't normally get into much trouble when dealing with reference types and value types like the example describes. When you're creating instances of classes, always derive from a new instance of the object, not a previously set instance.
Now that you have an understanding of what the CTS is and how it works, you need to see how the types are removed from memory. Removing types that are no longer referenced in your applications is known as garbage collection.
Handling Memory and Garbage
The common language runtime handles all memory allocation and management that your application requires. This includes the initial allocation that occurs when you declare an object and store data in it, and the release of memory back to the operating system when the object is no longer in use. The automatic garbage collection of unused objects solves all the inherent problems of Win32-based applications when it comes to the mysterious resource losses that Windows would succumb to after running applications.
Memory management is improved with each new version of the Windows operating system, but the fault is not completely that of the operating system. If you're writing C++ applications, it's very easy to forget to destroy object handles and memory blocks after they've been used. When this happens, there's no way for Windows to recover that memory until the machine is rebooted. In Visual Basic 6, you had to set all your object instances toNothing to guarantee that memory would be freed after an object was used. The limitations for the runtime environments of all languages lead to the problems of resource loss in Windows. So, in the end, it isn't really the fault of Windows—it's the fault of the developers writing the code that runs in Windows.
The garbage collection mechanism used in .NET is very simple and can be summed up in the following steps:
1. The garbage collector (GC) allocates memory resources on the managed heap when a process starts and sets a pointer to that memory allocation.
2. Each object created for the allocated resource is given the next address space in the managed heap when it's created.
3. The GC continuously scans the managed heap for objects that are out of scope and no longer in use.
4. The GC reclaims stack heaps that it determines are out of scope and compacts the managed heap for the running process.
This four-step process occurs over and over during the execution lifetime of your application. Under the hood, the GC divides the managed heap running your processes into three generations. Each generation is examined separately by the GC based on when the objects on the heap were created and their dependency to each other. This mechanism improves the overall performance of garbage collection because constantly scanning the entire managed heap for unused resources would be processor-intensive and time-consuming. By splitting apart when and where objects are created, the process of garbage collection can effectively determine what objects are in use and what objects are out of scope.
Although the GC can handle the destruction of most objects on the managed heap, objects such as file handles, network handles, database connections, and window handles are unmanaged resources that are created on the managed heap. These resources can be given the correct memory allocation, and the GC knows when they are out of scope, but it doesn't know when to destroy those objects to reclaim the memory on the stack. To reclaim memory from unmanaged resources, you must explicitly destroy the objects by creating the necessary cleanup code to implement the IDisposable interface and override theDispose method of the object. This isn't always necessary, and should be used only if you know that a resource must be freed when your component is no longer being used.
If you're using an object and you know it's a CTS-compliant managed type, the automatic garbage collection handles reclaiming the resource. Haphazardly calling the Dispose method on objects consumes resources and forces garbage collection. When writing components that use unmanaged resources, you can close file handles and network handles in the Dispose method, and the normal process of garbage collection destroys the object and reclaims the memory allocation.
Because the common language runtime determines when garbage collection takes place, it's referred to as nondeterministic finalization. In other words, you have no idea when the finalize method, which marks an object for collection, will occur.
The reason that understanding the existence of Dispose method is important is because of an unlikely worst-case scenario in which object resources aren't freed and a component attempts to create them again. This situation could occur if the system running a component is depleting its resources and garbage collection isn't occurring on a regular basis. The following code demonstrates how to implement the Dispose method when creating a Windows User Control and implementing a database connection.

Imports System.Data.SqlClient

Public Class UserControl1
Inherits System.Windows.Forms.UserControl
Private cn As New SqlConnection()
Public Sub New()
MyBase.New()
cn.ConnectionString = "uid=sa;pwd=;database=pubs;server=."
cn.Open()
InitializeComponent()
End Sub

Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
cn.Close()
cn = Nothing
End If
End If
MyBase.Dispose(disposing)
End Sub

Private components As System.ComponentModel.IContainer

Private Sub InitializeComponent()
Me.Name = "UserControl1"
End Sub
End Class


using System;
using System.Collections;
using System.ComponentModel;
using System.Drawing;
using System.Data;
using System.Windows.Forms;
using System.Data.SqlClient;

namespace cSharpDispose
{
public class UserControl1 : System.Windows.Forms.UserControl
{
private System.ComponentModel.Container components = null;
private SqlConnection cn;
public UserControl1()
{
InitializeComponent();
cn.ConnectionString=
"database=pubs;server=localhost;uid=sa;pwd=";
cn.Open();
}
protected override void Dispose( bool disposing )
{
if( disposing )
{
if( components != null )
components.Dispose();
cn.Close();
cn=null;
}
base.Dispose( disposing );
}

private void InitializeComponent()
{
this.Name = "UserControl1";
this.Load += new
System.EventHandler(this.UserControl1_Load);
}
}
}
As you can see, implementing Dispose is a simple task. By default, any class that derives from System.ComponentModel.Componenthas a Dispose method that you can override. If you're writing a component that doesn't derive fromSystem.ComponentModel.Component, you can implement the IDisposable interface and create your own Dispose method.
The .NET Framework Class Library
The second most important piece of the .NET Framework is the .NET Framework class library (FCL). As you've seen, the common language runtime handles the dirty work of actually running the code you write. But to write the code, you need a foundation of available classes to access the resources of the operating system, database server, or file server. The FCL is made up of a hierarchy of namespaces that expose classes, structures, interfaces, enumerations, and delegates that give you access to these resources.
The namespaces are logically defined by functionality. For example, the System.Data namespace contains all the functionality available to accessing databases. This namespace is further broken down into System.Data.SqlClient, which exposes functionality specific to SQL Server, and System.Data.OleDb, which exposes specific functionality for accessing OLEDB data sources. The bounds of a namespace aren't necessarily defined by specific assemblies within the FCL; rather, they're focused on functionality and logical grouping. In total, there are more than 20,000 classes in the FCL, all logically grouped in a hierarchical manner. Figure 1.8 shows where the FCL fits into the .NET Framework and the logical grouping of namespaces.

Figure 1.8 The .NET Framework class library.
To use an FCL class in your application, you use the Imports statement in Visual Basic .NET or the using statement in C#. When you reference a namespace in Visual Basic .NET or C#, you also get the convenience of auto-complete and auto-list members when you access the objects' types using Visual Studio .NET. This makes it very easy to determine what types are available for each class in the namespace you're using. As you'll see over the next several weeks, it's very easy to start coding in Visual Studio .NET. The following code adds a reference to the data classes in both Visual Basic .NET and C#.

Imports System
Imports System.Data.SqlClient
Imports System.Data.OleDb


using System;
using System.Data.SqlClient;
using System.Data.OleDb;
On Day 10, "Accessing Data with ADO.NET," you learn more about the common FCL namespaces and assemblies, and how to write applications using them. For now, you can see that without the FCL, the common language runtime and Visual Studio .NET wouldn't be very easy tools to use. The key idea to grasp is that the FCL is 100% available to all .NET languages, so the FCLnamespace that implements file I/O capability in C# is the same FCL namespace that's used in Visual Basic .NET, J# .NET, and COBOL .NET.
What about C++?
With the introduction of Visual Studio .NET and great new languages like C# and Visual Basic .NET, Microsoft has also improved the C++ language. By providing Managed Extensions for C++, an application written in C++ can take advantage of the core features of .NET and the common language runtime. Garbage collection, cross-language debugging and code access security are all fundamental aspects of .NET, and are the foundation of the Visual Basic .NET and C# languages. Using Managed Extensions for C++, a traditional C++ developer can take advantage of the features of the .NET Framework directly from Visual Studio .NET, writing applications that contain both managed and unmanaged code. New project templates for C++ are built into VS.NET, and improved compiler options allow C++ applications written using VS.NET to live in the managed environment of the .NET Framework. All of the power and flexibility that has made C++ a great language is still there, the Managed Extensions take the language to the next level with the power and flexibility of the .NET Framework. Using Managed Extensions for C++ will allow you to create .NET classes that are callable from managed C++ or unmanaged C++ applications.
In this book, to reach the broadest audience possible, all of the code is written in either Visual Basic .NET or C#. If you are a C++ developer, and new to .NET, the syntax of C# will be familiar to you, and you will be able to write applications immediately using C#. Using Visual Studio .NET as your development tool will allow you to create applications faster and easier than ever, so you can look at this book as a reference on the tool, not the language. No matter what language you develop in, using VS.NET will allow you create better applications faster.
.NET Servers and the Future of .NET
The designers of the .NET Framework put much thought into how distributed computing should work. It seems that .NET is the next killer app, but to make the .NET Framework a widespread success, actual servers must be built using the .NET Framework. Currently, there are no true .NET servers. There are servers that take advantage of the common language runtime and its managed execution environment, but most servers from Microsoft today still run under COM and unmanaged code.
Commerce Server 2002 is positioned as a .NET server for e-commerce, and applications you design with it can be completely written using Visual Basic .NET or C#, but the underlying infrastructure of Commerce Server is still based on COM. Because rewriting server applications is a truly monumental task, the move to completely .NET servers could take several years. Along the way, there'll be servers such as Commerce Server 2002 that are half managed code and half unmanaged code. From a developer's viewpoint that's fine, because you don't want to write ASP and Visual Basic 6 code for server products while the rest of your distributed application development is in a .NET language.
Currently, Microsoft seems to be positioning server products as .NET Enterprise Servers if they can integrate XML Web services into their existing infrastructure. For example, SQL Server 2000 certainly isn't written in managed code, but there are add-ons to SQL Server 2000 that enable you to expose stored procedures as XML Web services. The SQL Server Notification Service is a .NET add-on that allows notification to .NET applications if certain events trigger in SQL. BizTalk server's purpose in life is the orchestration and automation of complex business processes, and it's positioned as a .NET server because of its capability to consume XML Web services. The following Microsoft server products are considered .NET Enterprise Servers because of their capability to at least interact with a distributed environment such as the Internet and have some relationship with the .NET Framework concepts:
• Internet Security and Acceleration Server
• Application Center 2000
• Commerce Server 2000 and Commerce Server 2002
• BizTalk Server 2000 and BizTalk Server 2002
• SQL Server 2000
• Exchange Server 2000
• Host Integration Server 2000
In my opinion, the fact that a .NET server is truly running under the common language runtime is not a deal breaker. For .NET to get to the next step, it must run on other operating systems, not just the Windows family of desktop and server operating systems. Currently, the Mono project is a grass-roots move to port the .NET Framework class library to the Linux operating system. That means the code you're writing now for Windows will also eventually run under Linux and, hopefully, Unix as well. You can learn more about the Mono project and where it currently is in the development process at http://www.go-mono.org. It would be a huge step forward if .NET were ported to the Macintosh operating system also. Although the Mac is still a small percentage of the overall market in desktop PCs, its incompatibility with Windows creates headaches for application developers. There needs to be consistency across platforms eventually.
Moving into the future with .NET, the sky seems to be the limit. This isn't necessarily because Microsoft is going to think of some great new thing to add to the .NET Framework, even though it most likely will, but it has to do with computing in general and the general infrastructure of our daily lives. As every household and business installs high-speed data access, and as computers become faster and cheaper, the applications you write will have a greater influence on how people look at what computer programs can do. You aren't bound to single servers anymore. Writing truly distributed and scalable applications is very easy because of the groundwork laid out by the .NET Framework. You can begin to look at the code you write not as blocks of modules running on a Windows 2000 Server, but as distributed objects that you can reuse in multiple applications across an enterprise simply by plugging them into an XML Web service. The future of .NET is the concept of a true distributed environment.
Summary
Today you learned about the core concepts of the .NET Framework and how it fits into the vision of .NET. The common language runtime, in conjunction with the .NET Framework class library, gives you the foundation in which to write distributed, scalable, and robust applications. Technologies such as the common type system, garbage collection, and the Common Language Specification make up the core infrastructure that help the common language runtime and the .NET Framework make your applications run better. Starting tomorrow, you'll learn the essentials of writing applications using the tools provided in Visual Studio .NET.

dot net link

http://dotnetguts.blogspot.com/search/label/C%23

real time dotnet guys website

all .net interview questions understandable to beginners in a very celar mannaer is given in the following link


http://dotnetguts.blogspot.com/search/label/C%231

.Net Frequently Asked Questions

The link below gives more information about .net Frequently asked questions..........

http://dng-dotnetframework.blogspot.com/

New Features in C# .NET 3.5

click on the following link for C#.net new features with sample coding in step by step approach........

http://crazorsharp.blogspot.com/2009/03/new-features-in-c-30-net-35-part-1.html

.NET NEW FEATURES 3.5 and 4.0 (VISUAL STUDIO 2010)

clear and neat description of new features in c#.net 2008 and 2010 is in the following link


http://msdn.microsoft.com/en-us/library/bb332048.aspx

What's New in the .NET Framework Version 3.5
Other Versions
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

This topic contains information about new and enhanced features in the .NET Framework version 3.5.

.NET Compact Framework
The .NET Compact Framework version 3.5 expands support for distributed mobile applications by including the Windows Communication Foundation (WCF) technology. It also adds new language features such as LINQ, new APIs based on community feedback, and improves debugging with updated diagnostic tools and features.

For details about these new features and enhancements, see What's New in the .NET Compact Framework Version 3.5.

ASP.NET
The .NET Framework 3.5 includes enhancements in targeted areas of ASP.NET and Visual Web Developer. The most significant advance is improved support for the development of AJAX-enabled Web sites. ASP.NET supports server-centric AJAX development with a set of new server controls and APIs. You can enable an existing ASP.NET 2.0 page for AJAX by adding a ScriptManager control and an UpdatePanel control so that the page can update without requiring a full page refresh.

ASP.NET also supports client-centric AJAX development with a new client library called the Microsoft AJAX Library. The Microsoft AJAX Library supports client-centric, object-oriented development, which is browser-independent. By using the library classes in your ECMAScript (JavaScript) you can enable rich UI behaviors without roundtrips to the server. You can mix the degree of server-centric and client-centric development to meet the needs of your application. Furthermore, Visual Web Developer includes improved IntelliSense support for JavaScript and support for the Microsoft AJAX Library.

ASP.NET and Visual Web Developer now support the creation of both ASMX and WCF-based Web services and the seamless use of either implementation from Web pages using Microsoft AJAX Library. Furthermore, server-side application services including forms authentication, roles management, and profiles are now exposed as Web services that can be consumed in WCF-compatible applications, including client script and Window Forms clients. ASP.NET enables all Web-based applications to share these common application services.

Other improvements in ASP.NET include a new data control, ListView, for displaying data; a new data source control, LinqDataSource, that exposes Language Integrated Query (LINQ) to Web developers through the ASP.NET data source control architectures; a new tool, ASP.NET Merge Tool (Aspnet_merge.exe), for merging precompiled assemblies; and tight integration with IIS 7.0. ListView is a highly customizable control (using templates and styles) that also supports edit, insert, and delete operations, as well as sorting and paging functionality. The paging functionality for ListView is provided by a new control called DataPager. You can use the merge tool to combine assemblies to support a range of deployment and release management scenarios. The integration of ASP.NET and IIS 7.0 includes the ability to use ASP.NET services, such as authentication and caching, for any content type. It also includes the ability to develop server pipeline modules in ASP.NET managed code and supports unified configuration of modules and handlers.

Other improvements in Visual Web Developer include multitargeting support, inclusion of Web Application Projects, a new Design view, new Cascading Style Sheets (CSS) design tools, and support for LINQ for SQL databases. Multitargeting enables you to use Visual Web Developer to target development of Web applications to specific versions of the .NET Framework, including versions 2.0, 3.0, and 3.5.

For more information, see What's New in ASP.NET and Visual Web Developer.

Add-Ins and Extensibility
The System.AddIn.dll assembly in the .NET Framework 3.5 provides powerful and flexible support to developers of extensible applications. It introduces a new architecture and model that helps developers with the initial work to add extensibility to an application and by ensuring that their extensions continue working as the host application changes. The model provides the following features:

Discovery

You can easily find and manage sets of add-ins in multiple locations on a computer with the AddInStore class. You can use this class to search for and obtain information about add-ins by their base types without having to load them.

Activation

After an application chooses an add-in, the AddInToken class makes it easy to activate. Simply choose the isolation and sandboxing level and the system takes care of the rest.

Isolation

There is built-in support for application domains and process isolation of add-ins. The isolation level for each add-in is in the control of the host. The system handles loading application domains and processes and shutting them down after their add-ins have stopped running.

Sandboxing

You can easily configure add-ins with either a default or customized trust level. Support includes Internet, Intranet, Full Trust, and “same-as-host” permission sets, as well as overloads that let the host specify a custom permission set.

UI Composition

The add-in model supports direct composition of Windows Presentation Foundation (WPF) controls that span application domain boundaries. You can easily allow add-ins to contribute directly to the UI of the host while still retaining the benefits of isolation, ability to unload, sandboxing, and versioning.

Versioning

The add-in architecture makes it possible for hosts to introduce new versions of their object model without breaking existing add-ins or impacting the developer experience for new ones.

For more information, see Add-ins and Extensibility.

Common Language Runtime
Collections

HashSet(Of T) provides high performance set operations to the .NET Framework. A set is a collection that contains no duplicate elements, and whose elements are in no particular order. For more information, see HashSet Collection Type.

Diagnostics

The EventSchemaTraceListener class provides tracing of end-to-end, schema-compliant events. You can use end-to-end tracing for a system that has heterogeneous components that cross thread, AppDomain, process, and computer boundaries. A standardized event schema (see Event Representation for Event Consumers) has been defined to enable tracing across these boundaries. This schema is shared by various tracing technologies, including Windows Vista diagnostics tools such as Event Viewer. The schema also enables the addition of custom, schema-compliant elements.

The EventSchemaTraceListener class is tuned for logging performance with implicit support for lock-free tracing.

I/O and Pipes

Pipes provide interprocess communication between any processes running on the same computer, or on any other Windows computer within a network. The .NET Framework provides access to two types of pipes: anonymous pipes and named pipes. For more information about pipes, see Pipes.

Garbage Collection

The GCSettings class has a new LatencyMode property that you can use to adjust the time that the garbage collector intrudes in your application. You set this property to one of the values of the new GCLatencyMode enumeration.

The GC class has a new Collect(Int32, GCCollectionMode) method overload that you can use to adjust the behavior for a forced garbage collection. For example, you can use this overload to specify that the garbage collector should determine whether the current time is optimal to reclaim objects. This overload takes a value from the new GCCollectionMode enumeration.

Reflection and Reflection Emit in Partial Trust

Assemblies that run with partial trust can now emit code and execute it. Emitted code that calls only public types and methods needs no permissions beyond the permissions demanded by the types and methods that are accessed. The new DynamicMethod(String, Type, Type()) constructor makes it easy to emit such code.

When emitted code needs to access private data, the new DynamicMethod(String, Type, Type(), Boolean) constructor allows restricted access. The host must grant ReflectionPermission with the new RestrictedMemberAccess flag to enable this feature, which gives emitted code the ability to access private data only for types and methods in assemblies with equal or lesser trust levels. See Walkthrough: Emitting Code in Partial Trust Scenarios.

For reflection, a host grant of RestrictedMemberAccess similarly allows restricted use of methods that access private properties, call private methods, and so on, but only for target assemblies with equal or lesser trust levels.

Threading

Better Reader/Writer Lock

The new ReaderWriterLockSlim class provides performance that is significantly better than ReaderWriterLock, and comparable with the lock statement (SyncLock in Visual Basic). Transitions between lock states have been simplified to make programming easier and to reduce the chances of deadlocks. The new class supports recursion to simplify migration from lock and from ReaderWriterLock.

ThreadPool Performance Enhancements

Throughput for the dispatch of work items and I/O tasks in the managed thread pool is significantly improved. Dispatch is now handled in managed code, without transitions to unmanaged code and with fewer locks. The use of ThreadPool is recommended over application-specific thread pool implementations.

Time Zone Improvements

Two new types, DateTimeOffset and TimeZoneInfo, improve support for time zones and make it easier to develop applications that work with dates and times in different time zones. For a discussion of which type to use in particular situations, see Choosing Between DateTime, DateTimeOffset, and TimeZoneInfo.

TimeZoneInfo

The new TimeZoneInfo class largely supplants the existing TimeZone class. You can use TimeZoneInfo to retrieve any time zone defined in the registry, rather than just the local time zone and Coordinated Universal Time (UTC). You can also use this class to define custom time zones, to serialize and deserialize custom time zone data, and to convert times between time zones. For more information about developing applications that use the TimeZoneInfo class, see Times and Time Zones.

DateTimeOffset

The new DateTimeOffset structure extends the DateTime structure to make working with times across time zones easier. The DateTimeOffset structure stores date and time information as a UTC date and time together with an offset value that indicates how much the time differs from UTC.

Cryptography
ClickOnce Manifests

There are new cryptography classes for verifying and obtaining information about manifest signatures for ClickOnce applications. The ManifestSignatureInformation class obtains information about a manifest signature when you use its VerifySignature method overloads. You can use the ManifestKinds enumeration to specify which manifests to verify. The result of the verification is one of the SignatureVerificationResult enumeration values. The ManifestSignatureInformationCollection provides a read-only collection of ManifestSignatureInformation objects of the verified signatures. In addition, the following classes provide specific signature information:

StrongNameSignatureInformation

Holds the strong name signature information for a manifest.

AuthenticodeSignatureInformation

Represents the Authenticode signature information for a manifest.

TimestampInformation

Contains information about the time stamp on an Authenticode signature.

TrustStatus

Provides a simple way to check whether an Authenticode signature is trusted.

Suite B Support

The .NET Framework 3.5 supports the Suite B set of cryptographic algorithms published by the National Security Agency (NSA). For the NSA documentation, see www.nsa.gov/ia/industry/crypto_suite_b.cfm.

The following algorithms are included:

Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits for encryption.

Secure Hash Algorithm (SHA-256 and SHA-384) for hashing.

Elliptic Curve Digital Signature Algorithm (ECDSA) using curves of 256-bit and 384-bit prime moduli for signing. This algorithm is provided by the ECDsaCng class. It allows you to sign with a private key and verify with a public key.

Elliptic Curve Diffie-Hellman (ECDH) using curves of 256 and 384-bit prime moduli for key exchange/secret agreement. This algorithm is provided by the ECDiffieHellmanCng class.

Managed code wrappers for the Federal Information Processing Standard (FIPS) certified implementations of the AES, SHA-256, and SHA-384 implementations are available in the new AesCryptoServiceProvider, SHA256CryptoServiceProvider, and SHA384CryptoServiceProvider classes.

The Cryptography Next Generation (CNG) classes provide a managed implementation of the native Crypto API (CAPI). Central to this group is the CngKey key container class, which abstracts the storage and use of CNG keys. This class allows you to store a key pair or a public key securely and refer to it using a simple string name. The ECDsaCng and ECDiffieHellmanCng classes use CngKey objects.

The CngKey class is used for a variety of additional operations, including opening, creating, deleting, and exporting keys. It also provides access to the underlying key handle to use when calling native APIs directly.

There are a variety of supporting CNG classes, such as CngProvider, which maintains a key storage provider, CngAlgorithm, which maintains a CNG algorithm, and CngProperty, which maintains commonly used key properties.

Networking
Peer-to-Peer Networking

Peer-to-peer networking is a serverless networking technology that allows several network devices to share resources and communicate directly with each other. The System.Net.PeerToPeer namespace provides a set of classes that support the Peer Name Resolution Protocol (PNRP) that allows the discovery of other peer nodes through PeerName objects registered within a peer-to-peer cloud. PNRP can resolve peer names to IPv6 or IPv4 IP addresses.

Collaboration Using Peer-to-Peer Networking

The System.Net.PeerToPeer.Collaboration namespace provides a set of classes that support collaboration using the Peer-to-Peer networking infrastructure. These classes simplify the process by which applications can:

Track peer presence without a server.

Send invitations to participants.

Discover peers on the same subnet or LAN.

Manage contacts.

Interact with peers.

Microsoft’s Peer-to-Peer collaboration infrastructure provides a peer-to-peer network-based framework for collaborative serverless activities. Use of this framework enables decentralized networking applications that use the collective power of computers over a subnet or the Internet. These types of applications can be used for activities such as collaborative planning, communication, content distribution, or even multiplayer game matchmaking.

Socket Performance Enhancements

The Socket class has been enhanced for use by applications that use asynchronous network I/O to achieve the highest performance. A series of new classes have been added as part of a set of enhancements to the Socket namespace. These classes provide an alternative asynchronous pattern that can be used by specialized high-performance socket applications. These enhancements were specifically designed for network server applications that require the high-performance.

Windows Communication Foundation
WCF and WF Integration—Workflow Services

The .NET Framework 3.5 unifies the Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) frameworks so that you can use WF as a way to author WCF services or expose your existing WF workflow as a service. This enables you to create services that can be persisted, can easily transfer data in and out of a workflow, and can enforce application-level protocols. For code samples, see Workflow Services Samples.

Durable Services

The .NET Framework 3.5 also introduces support for WCF services that use the WF persistence model to persist the state information of the service. These durable services persist their state information on the application layer, so that if a session is torn down and re-created later, the state information for that service can be reloaded from the persistence store.

WCF Web Programming Model

The WCF Web Programming Model enables developers to build Web-style services with WCF. The Web Programming Model includes rich URI processing capability, support for all HTTP verbs including GET, and a simple programming model for working with a wide variety of message formats (including XML, JSON, and opaque binary streams). For more information, see WCF Web Programming Model Overview.

WCF Syndication

WCF now includes a strongly typed object model for processing syndication feeds, including both the Atom 1.0 and RSS 2.0 formats. For more information, see WCF Syndication. For code samples, see Syndication Samples.

WCF and Partial Trust

In .NET Framework 3.5, applications running with reduced permissions can use a limited subset of WCF features. Server applications running with ASP.NET Medium Trust permissions can use the WCF Service Model to create basic HTTP services. Client applications running with Internet Zone permissions (such as XAML Browser Applications or unsigned applications deployed with ClickOnce) can use the WCF proxies to consume HTTP services. In addition, the WCF Web Programming Model features (including AJAX and Syndication) are available for use by partially trusted applications. For more information, see Partial Trust.

WCF and ASP.NET AJAX Integration

The integration of WCF with the Asynchronous JavaScript and XML (AJAX) capabilities in ASP.NET provides an end-to-end programming model for building Web applications that can use WCF services. In AJAX-style Web applications, the client (for example, the browser in a Web application) exchanges small amounts of data with the server by using asynchronous requests. Integration with AJAX features in ASP.NET provides an easy way to build WCF Web services that are accessible by using client JavaScript in the browser. For more information, see ASP.NET AJAX Integration and JSON Support. For code samples, see AJAX Samples.

Web Services Interoperability

In the .NET Framework 3.5, Microsoft maintains its commitment to interoperability and public standards and introduces support for the new secure, reliable, and transacted Web services standards:

Web Services Reliable Messaging v1.1

Web Services Reliable Messaging Policy Assertion v1.1

WS-SecureConversation v1.3

WS-Trust v1.3

WS-SecurityPolicy v1.2

Web Services Atomic Transaction (WS-AtomicTransaction) Version 1.1

Web Services Coordination (WS-Coordination) Version 1.1

Web Services Policy 1.5 - Framework

Web Services Policy 1.5 - Attachment

Implementation of these protocols is made available using the new standard bindings, ws2007HttpBinding and ws2007FederationHttpBinding, which are documented in the Web Services Protocols Interoperability Guide. For a code sample, see WS Binding Samples.

Windows Presentation Foundation
In the .NET Framework 3.5, Windows Presentation Foundation contains changes and improvements in numerous areas, including versioning, the application model, data binding, controls, documents, annotations, and 3-D UI elements.

For details about these new features and enhancements, see What's New in Windows Presentation Foundation Version 4.

Windows Workflow Foundation
WCF and WF Integration—Workflow Services

The .NET Framework 3.5 unifies the Windows Workflow Foundation (WF) and Windows Communication Foundation (WF) frameworks so that you can use WF as a way to author WCF services or expose your existing WF workflow as a service. This enables you to create services that can be persisted, can easily transfer data in and out of a workflow, and can enforce application-level protocols. For code samples, see Workflow Services Samples.

Rules

The WF rules engine now supports extension methods, operator overloading, and the use of the new operator in your rules. For more information, see Rule Changes in .NET Framework 3.5. For cde samples, see Rules and Conditions.

Windows Forms
ClickOnce Improvements

Several improvements have been made to ClickOnce. Improvements include deployment from multiple locations and third-party branding. For more information, see Deploying ClickOnce Applications For Testing and Production Servers without Resigning and Creating ClickOnce Applications for Others to Deploy.

The Mage.exe tool, which is sometimes used together with ClickOnce, has been updated for the .NET Framework 3.5. For more information, see Mage.exe (Manifest Generation and Editing Tool).

Authentication, Roles, and Settings Services

Client application services are new in the .NET Framework 3.5 and enable Windows-based applications (including Windows Forms and Windows Presentation Foundation applications) to easily access the ASP.NET login, roles, and profile services. These services enable you to authenticate users and retrieve user roles and application settings from a shared server.

You can enable client application services by specifying and configuring client service providers in your application configuration file or in the Visual Studio Project Designer. These providers plug into the Web extensibility model and enable you to access the Web services through existing .NET Framework login, roles, and settings APIs. Client application services also support occasional connectivity by storing and retrieving user information from a local data cache when the application is offline.

For more information, see Client Application Services.

Windows Vista Support

Existing Windows Forms applications work seamlessly on Windows Vista, and they are upgraded to have the same appearance as applications written specifically for Windows Vista whenever possible. Common file dialog boxes are automatically updated to the Windows Vista version. The .NET Framework 3.5 also supports the User Account Control (UAC) Shield icon. For more information, see FileDialog Class and Shield.

WPF support

You can use Windows Forms to host Windows Presentation Foundation (WPF) controls and content together with Windows Forms controls. You can also open WPF windows from a Windows Form. For more information about how to use Windows Forms and WPF together, see Migration and Interoperability.

LINQ
Language-Integrated Query (LINQ) is a new feature in Visual Studio 2008 and the .NET Framework 3.5. LINQ extends powerful query capabilities to the language syntax of C# and Visual Basic in the form of standard, easily-learned query patterns. This technology can be extended to support potentially any kind of data store. The .NET Framework 3.5 includes LINQ provider assemblies that enable the use of LINQ for querying .NET Framework collections, SQL Server databases, ADO.NET Datasets, and XML documents.

The components of LINQ that are part of the .NET Framework 3.5 are:

The System.Linq namespace, which contains the set of standard query operators and types and interfaces that are used in the infrastructure of a LINQ query. This namespace is in the System.Core.dll assembly.

The System.Data.Linq namespace, which contains classes that support interaction with relational databases in LINQ to SQL applications.

The System.Data.Linq.Mapping namespace, which contains classes that can be used to generate a LINQ to SQL object model that represents the structure and content of a relational database.

The System.Xml.Linq namespace, which contains the classes for LINQ to XML. LINQ to XML is an in-memory XML programming interface that enables you to modify XML documents efficiently and easily. Using LINQ to XML, you can load XML, serialize XML, create XML trees from scratch, manipulate in-memory XML trees, and validate by using XSD. You can also use a combination of these features to transform XML trees from one shape into another.

New types in the System.Web.UI.WebControls and System.Web.UI.Design.WebControls namespaces. These new types, such as LinqDataSource, support the use of LINQ in ASP.NET Web pages through a data source control.

The DataRowComparer, DataRowExtensions, and DataTableExtensions classes in the System.Data namespace support LINQ queries against ADO.NET DataSet objects.

In the class library, the LINQ extension methods that apply to a class are listed in the members page for the class, in the Contents pane, and in the Index pane.

Expression Trees
Expression trees are new in the .NET Framework 3.5, and provide a way to represent language-level code in the form of data. The System.Linq.Expressions namespace contains the types that are the building blocks of expression trees. These types can be used to represent different types of code expressions, for example a method call or an equality comparison.

Expression trees are used extensively in LINQ queries that target remote data sources such as a SQL database. These queries are represented as expression trees, and this representation enables query providers to examine them and translate them into a domain-specific query language.

The System.Linq.Expressions namespace is in the System.Core.dll assembly.

Programming Languages
Three Microsoft programming languages explicitly target the .NET Framework. For more information about new and enhanced features in these languages, see the following topics:

What's New in Visual C# 2010

What's New in Visual C++ 2008

What's New in the Visual Basic Language

See Also
Concepts

What's New in ASP.NET and Visual Web Developer
What's New in the .NET Compact Framework Version 3.5
What's New in Windows Presentation Foundation Version 4
What's New in Visual Studio 2010