Software Technologies

Use the ServiceHost class to configure and expose a service for use by client applications when you are not using Internet Information Services (IIS) or Windows Activation Services (WAS) to expose a service. Both IIS and WAS interact with a ServiceHost object on your behalf.

To expose a service for use by callers, requires a complete service description (represented by the ServiceDescription class). The ServiceHost class creates a ServiceDescription from the service type and configuration information and then uses that description to create ChannelDispatcher objects for each endpoint in the description.

Use a ServiceHost object to load a service, configure endpoints, apply security settings, and start listeners to handle incoming requests.

http://www.devexpress.com/

2011-01-24T02:21:00.001-08:00

http://www.devexpress.com/

aspnet_isapi.dll and aspnet_wp.exe

2011-01-23T21:58:00.001-08:00

http://msdn.microsoft.com/en-us/magazine/cc301898.aspx

http://www.slb.com

2011-01-19T02:28:00.001-08:00

http://scrumforteamsystem.com/

2010-11-23T06:42:00.001-08:00

http://scrumforteamsystem.com/

http://www.elektor.com/

2010-10-29T04:38:00.001-07:00

http://www.elektor.com/

http://www.matrixmultimedia.com

2010-10-29T00:55:00.001-07:00

http://www.matrixmultimedia.com/

.Net Framework

2010-10-26T07:52:00.001-07:00

www.telerik.com

2010-07-20T06:03:00.000-07:00

http://www.telerik.com/team-productivity-tools/teampulse.aspx

Hyper-V Server

2010-07-01T06:16:00.000-07:00

Microsoft® Hyper-V™ Server 2008 R2 is a stand-alone product that provides a reliable and optimized virtualization solution enabling organizations to improve server utilization and reduce costs. Since Hyper-V Server is a dedicated stand-alone product, which contains only the Windows Hypervisor, Windows Server driver model and virtualization components, it provides a small footprint and minimal overhead. It easily plugs into customers’ existing IT environments, leveraging their existing patching, provisioning, management, support tools, processes, and skills. Some of the new key new features that are available in Microsoft Hyper-V Server 2008 R2 are live migration, cluster shared volume support and expanded processor and memory support for host systems.

IT Pros can easily to leverage their existing knowledge and skills with Microsoft virtualization products, as well as the collective knowledge of the community, minimizing any learning curve. In addition, with Microsoft providing comprehensive support for Microsoft applications and heterogeneous guest operating systems, customers can virtualize with confidence and peace of mind.

When to Use Hyper-V Server 2008 R2

Customers can use Microsoft Hyper-V Server 2008 R2 for the following scenarios:

Test and Development
Server Consolidation
Branch Office Consolidation
Hosted Desktop Virtualization (VDI)

Customers should use Windows Server 2008 R2 to get application failover capabilities or flexible and cost-effective virtualization rights (one free virtual instance for Standard Edition, four free virtual instances for Enterprise Editions, and unlimited virtual instances for Datacenter Edition with the purchase of a license of Windows Server 2008), and flexible and cost-effective virtualization rights.

Here is a list of the features in Hyper-V Server 2008 R2.

BizTalk RFID Server

2010-07-01T03:19:00.001-07:00

Comprehensive Device Management

You now have comprehensive device management and solution deployment that spans mobile and fixed readers. With BizTalk Server RFID management capabilities you can manage multiple providers and devices end emulate devices. In addition, you are able to monitor and troubleshoot deployments using System Center Operations Manager.

Capture Business Relevant Data

Create, deploy and change business rules and event filtering to expose business relevant data and take the appropriate action based on incoming events. Through BizTalk’s Business Activity Monitoring (BAM) you can obtain end to end process visibility and analytics of RFID event flow during business process execution.

Support for Industry Standards

BizTalk Server RFID provides support for EPC Global standards like EPCIS, Tag Data Translator (TDT) and Low Level Reader Protocol.

BizTalk RFID Mobile

2010-07-01T03:17:00.000-07:00

Microsoft BizTalk RFID Mobile is an extension of the Microsoft BizTalk Server RFID platform to mobile devices. BizTalk RFID Mobile is an extensible platform for development, deployment and management of RFID, barcode and other sensor applications on mobile devices.

Faster Time to Market

Write applications once on Windows Mobile and Windows CE and run on multiple devices. By developing RFID applications on BizTalk’s RFID platform there is now a consistent application development experience across fixed and mobile readers. You will most likely want to integrate your data with existing business processes.

Empower Workers to Do More

With BizTalk RFID Mobile in the palm of their hands mobile workers will have access to information when and where they need it so that they can make decisions in real-time. Even if they don’t have network access, mobile workers will be able to perform critical operations and forward data to the server once there is a connection.

Enhanced Business Intelligence

New scenarios are now possible. You will now be able to capture more business relevant data and integrate that data with existing processes through BizTalk Server or replicate data to a SQL Server database. Bridge the gap between your core enterprise processes and your physical operations and assets.

Microsoft BizTalk RFID

2010-07-01T03:14:00.001-07:00

Microsoft BizTalk RFID is an innovative device management and event processing platform at the edge of the enterprise. It is designed to provide a scalable, extensible platform for development, deployment, and management of rich RFID and sensor solutions.

Plug-and-play hardware eco-system with uniform device abstraction and management

Robust, scalable, secure server platform for RFID solutions

Extensive partner eco-system (ISVs/SI) for vertical solutions with low TCO, high ROI

BizTalk 2006 R2 RFID Demo

2010-07-01T02:55:00.000-07:00

BizTalk Server and WCF Integration

2010-07-01T01:03:00.000-07:00

http://msdn.microsoft.com/en-us/library/bb973215.aspx
Introduction
With the November 2006 release of .NET Framework 3.0, the wait is finally over for software professionals. The core components of this managed code programming model â€“ Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) â€“ has revolutionized the way software is programmed.

This article focuses on the different options available for communication between WCF and BTS06. While much of the discussion will also be applicable to BTS04, any discrepancies in implementation for BTS04 will be highlighted.

There is a WCF Adapter for BTS06 is available on the CodePlex Web site. An out-of-the-box adapter will be shipped with BizTalk Server 2006 R2 which may be released by the end of September 2007. An overview of the R2 WCF Adapter's capabilities is available at the following blog post. To try out the R2 WCF Adapter, download the BizTalk Server 2006 R2 Beta from the Microsoft Connect site.

However, you may need to integrate existing BizTalk-based applications with WCF to do the same. In this article we present various options to achieve interoperability in cases where upgrading to BizTalk Server 2006 R2 is not possible. The article merely outlines the approaches and does not deal with them in an exhaustive manner. Nor does it provide a benchmark to compare the approaches. You need to evaluate and choose one among the suggested techniques after taking into account the needs of your application.

Note: If you are upgrading to BizTalk 2006 R2, then working with WCF Adapter will be ideal due to the ease of use, deployment and management it offers.

ASP.NET 4 "Quick Hit" - Clean Web.Config Files

2010-06-21T02:11:00.001-07:00

Process Templates In TFS

2010-06-21T01:29:00.001-07:00

Programming Best Practices

2010-06-14T02:34:00.000-07:00

Belbinson Toby 14 Jun 2010
Stockholm, Sweden

Less Code Is Better

The less code that you write, the less that you have to read, the less that you have to maintain, and usually the program will be simpler, and will often run faster.

Rewrite It.

It finally compiles! You just finished that big hairy part of the project, and it seems to work! Yeah, there are a few messy areas and some parts are a little hazy, but you got it done!

...you just found a bug. It won't be too bad to fix, just go in and add another if-statement to detect for the special case, and you're good to go!

If it's broken, don't fix it. Rewrite it.

95% of the time you are better off rewriting all of the code. That little if-statement that you are adding, to fix an innocuous bug, may seem harmless, but it should be signalling disaster to you. It most likely means that your abstraction wasn't quite correct. So now you are making it a little bit harder to read. You are adding a little bit more code. It only takes a few minutes, and rewriting it would take hours or even days.

In the long run, you would've been much better off not fixing it, but rewriting it. Now that you have found a few more bugs, and added a few more patches, and it's been a few months, the code is getting hairy. Now you are having a hard time being sure that the new code isn't making more bugs. And it's taking longer and longer to work with the program.

If you would've just rewritten it to be correct, all these times, then you would have great code, solid abstractions, you would know the code inside and out, it would be readable and maintainable. After rewriting it a few times, the code just flows as well. It no longer takes as long to write it as it first did.

Sure, sometimes you end up dumping the project or you didn't end up making things that much worse, by not rewriting it, but it's near impossible to guess when the 5% will be. Don't play that game. Just rewrite it.

UPDATE: I've posted more of my thoughts on this in it's own essay.

Code Is For People To Read

Only as a side-effect is it for computers to run. The easier your code is to read, the better understanding you will have of it. You will have less bugs. It will be more maintainable.

Sure, coding super fast, inline assembly makes you feel macho, but being macho doesn't help when CPU architecture changes, and you have to go back in, and decipher the mess you made.

Correctness Wins

Do it the right way. If you don't have enough time to do things right, then don't do them.

It almost always costs more in the long run, to do things less than correctly. Most often the reason for incorrect code, is trying to do too much in too little time. This is the beginning of feature creep. You are entering the world of hazy abstractions.

Do yourself a favor, stop coding.

Stop Designing, Start Coding

Instead of spending all of your time on the whiteboard, drawing up elaborate plans, start writing code. Yes, your code is going to suck. It is going to be a mess. But what's the rule when our code is a mess?

Rewrite it.

Your program will always be better off if you spend a day writing it 6 times, rather than designing it 6 times and writing it once. Writing code, and forcing yourself to rewrite it if it is incorrect, forces you to figure out the abstractions, and allows you to do deal with the real problems, instead of guessing what they will be.

You aren't building a car. You can forget to hook up the brakes and still live.

Fortran for .NET Language System

2010-06-09T02:43:00.000-07:00

Fortran for .NET allows you to create applications for the Microsoft .NET Framework. Lahey and Fujitsu have combined advanced compiler technology with support for Forms designers and Web Services to enable Fortran organizations to develop .NET applications with Fortran as easily as with other Microsoft .NET languages. Fortran for .NET consists of a Fortran compiler and associated tools designed to help you create applications that run in the .NET Framework.

Fortran for .NET compiler
Fortran for .NET language
Visual Studio .NET integration
Windows Forms
ASP.NET Web Forms
ADO.NET
Fortran for .NET compiler options
Restrictions on Fortran for .NET Code
Hardware and software requirements for Enterprise and Academic Editions
What can you do with Fortran for .NET and why would you want to?
The Fortran for .NET language system is included in LF Fortran v7.1 Enterprise and Academic editions.
--------------------------------------------------------------------------------

Fortran for .NET compiler

Th Fortran for .NET compiler targets Microsoft's .NET Framework. The compiler does not directly generate processor dependent object code; rather, it generates Microsoft Intermediate Language (MSIL) code assemblies and code modules. The code in an assembly can be executed on any computer that supports an execution engine called the Common Language Runtime (CLR), such as the .NET Framework.

The CLR does much more than provide the ability to operate on different operating systems, it also provides the basis for interoperability between different .NET languages, interlanguage debugging, versioning, and application deployment, among other things.

Applications that are targeted for the CLR are called managed applications, or managed code. Managed applications are required to be type safe and to present standardized interfaces, so that interoperability and security requirements can be met. Because some older Fortran features (such as COMMON and EQUIVALENCE) can violate the CLRs rules for type safety and interfaces, certain restrictions had to be placed on .NET applications that do not allow 100% compatibility with Fortran standards. For details on restrictions, see Restrictions on Fortran for .NET Code.

COBOL for Microsoft .NET Framework

2010-05-19T04:08:00.000-07:00

Belbinson Toby

Logica Pvt Ltd
Stockholm, Sweden

May 2010

Summary: Discusses why COBOL and .NET are strong partners and explains how Fujitsu COBOL has been integrated into the .NET Framework. (12 printed pages)

Contents
Introduction
Why COBOL for .NET Makes Sense
What COBOL for .NET Looks Like
Migrating COBOL Code to the .NET Framework
How COBOL for .NET is Implemented
Getting Started with COBOL for .NET

Introduction

Microsoft’s .NET Framework not only enables the vision of companies sharing Web Services but also establishes a whole new development and execution environment for applications – whether on or off the Web. With components winning awards even before their full release, .NET is truly the latest and greatest happening in the application development world. COBOL, on the other hand, has been around almost from the beginning of business applications on computers and is unlikely to be mentioned by anyone talking about the “latest and greatest”. Why, then, have Microsoft and Fujitsu Software expended considerable effort in bringing these two technologies together? Has it been possible to integrate the “old” and “new” in a worthwhile manner? Does this combination of COBOL and .NET have anything to offer you, and how easy is it going to be for you to take advantage of those benefits?

This paper aims to answer these questions for you firstly by laying out why the .NET Framework is attractive to business applications and COBOL programmers, and what COBOL has to offer to .NET. It will then give you a feel for COBOL for .NET by showing you what it looks like in different .NET technologies such as ASP.NET, Web Services and class sharing, explaining how you might use COBOL in each of these areas. It will give you an insight into what was done to make COBOL work in the .NET environment and conclude by describing how you can experience COBOL for .NET yourself.

Why COBOL for .NET Makes Sense

To understand why COBOL and .NET come together well, it is best to start with what COBOL has to offer. The reasons that COBOL runs over 70% of the world’s production business applications are that it has always provided:

•Record-oriented data structures

•Built-in business-oriented data types: alphanumeric, alphanumeric-edited, decimal, numeric-edited, and packed-decimal.

•Simple control flow constructs

•Readable and maintainable code

Although often put down by speedy programmers, COBOL’s verbosity has been a big part of it providing readable and maintainable code. Maintainable code is a critical feature for business applications that can have life spans of many decades. Consider if you are in the position of committing your company’s core business processes to a programming language – do you want to select the “in” language of the moment which history has shown will be “out” in 10 years’ time, or do you want to select a language that has a 40 year track record, and which any programmer can understand?

Another factor in favor of using COBOL for business logic, is that COBOL programmers typically have a lot of experience in supporting business needs. Their focus tends to be more on implementing the business functions rather than getting into the latest technology (just because it’s the latest).

However, businesses still need to take advantage of the latest technology as this can often give them their competitive advantage or ensure that they aren’t disadvantaged relative to the competition. This, if anything, has been COBOL’ s weakness in the last decade – it has not always been able to take advantage of the latest technologies as the interfaces or architectures have not been accessible to COBOL.

The .NET Framework changes all this. Web applications need a secure, managed environment in which to operate. In providing this Microsoft decided not just to create an environment that supported a single programming language, but to create an environment that was capable of supporting all programming languages, and to extend it so that it could support console, Windows GUI, and Web HTML styles of applications as well as the typically interface-less Web services. Figure 1 gives an overview of what the .NET Framework provides.

This figure shows how Visual Studio .NET provides a common development environment for programming. Any language, such as COBOL, which is enabled for that development environment, can be developed with language-sensitive features including highlighting of text, project building and debugging. Then the code is compiled into a standard intermediate language called Microsoft Intermediate Language (MSIL) that is executed by the Common Language Run-time (CLR) in a secure, managed environment. MSIL is platform independent and is compiled to native code by the part of the run-time loading software.

One big benefit of the common execution environment is that its design is such that classes can be inherited from one language to another. .NET includes several frameworks, or libraries of classes, that any .NET language can use, including COBOL.

The net result is that .NET offers an environment in which you develop in the language that makes most sense for the task.

Now it should be obvious how COBOL can benefit from being a full player in the .NET framework. COBOL gets:

•An award winning development environment (Visual Studio .NET) that is designed for creating .NET applications.

•The ability to inherit the latest technologies from the framework classes.

•The option to invoke code written in other languages in a seamless manner, whenever that code provides useful functionality.

•The ability to support application needs wherever MSIL is supported - such as in ASP.NET pages and Web services.

.NET benefits too by gaining:

•The language that is best for many business logic implementations

•The ability to execute the valuable business logic contained in around 200 billion lines of COBOL code worldwide (Gartner Group estimate)

•The business expertise of hundreds of thousands of COBOL programmers

Thus COBOL and .NET make a strong partnership; one that is worth exploring to see how you can exploit it to your company's advantage.

What COBOL for .NET Looks Like

To show you what COBOL looks like in the .NET Framework this paper presents three examples of COBOL code in different .NET areas:

•Within an ASP.NET page, illustrating the provision of dynamic Web content using COBOL

•As a Web Service, demonstrating how simple it can be to package existing modules as Web services.

•Within the GUI Framework, showing how COBOL can inherit from other languages and how OO COBOL has been adapted to fit the object oriented .NET architecture.

ASP.NET (language="COBOL")

ASP.NET is the Microsoft successor to Active Server Pages (ASP), which were designed to deliver dynamic Web content. ASP faced a number of weaknesses in the areas of performance and programmability, and ASP.NET makes substantial improvements in those areas. Instead of being interpreted like ASP, ASP.NET compiles pages to native code. This change results in enormous performance benefits, with only a one-time cost to compile the page when it is first deployed. The other important side effect of the design choice (to compile instead of interpret) is that it opens the door for compiled languages to provide code in ASP.NET pages.

ASP.NET Example 1

The following is a sample ASP.NET page written using COBOL that displays "Welcome to ASP.NET (now in COBOL!)" in increasing font sizes:

<%@ page language="COBOL" %>

<script runat="server">

OBJECT.

DATA DIVISION.

WORKING-STORAGE SECTION.

77 Font-Size PIC S9(9) COMP-5.

END OBJECT.

</script>

<% PERFORM VARYING Font-Size FROM 1 BY 1 UNTIL Font-Size > 7 %>

<font size="<%=Font-Size%>"> Welcome to ASP.NET (now in COBOL!) </font>

<br>

<% END-PERFORM. %>

The "<%@" characters introduce the directive that allow us to set the programming language for the page to COBOL. The <script> block allows us to introduce COBOL code that declares the FONT-SIZE variable and the characters "<%" allow us to introduce inline COBOL code to loop over the HTML that displays "Welcome to ASP.NET (now in COBOL!)"

Fujitsu COBOL takes advantage of this important benefit by allowing COBOL programmers to embed COBOL code in ASP.NET pages.

Dynamically Templated GridView with ITemplate Interface.

2010-04-24T03:23:00.000-07:00

Writing a class which implements ITemplate
Here is the skeleton of class DynamicallyTemplatedGridViewHandler implementing ITemplate with a list of data members and methods.

Listing 2

public class DynamicallyTemplatedGridViewHandler : ITemplate
{
ListItemType ItemType;
string FieldName;
string InfoType;

public DynamicallyTemplatedGridViewHandler(ListItemType Item_type,
string field_name, string control_type);
public void InstantiateIn(System.Web.UI.Control Container);
private void OnDataBinding(object sender, EventArgs e);
}This class has three data members:

ListItemType ItemType;
string FieldName;
string InfoType;ItemType keeps the type of a list item type: Item, EditItem, Header, Footer, AlternatingItem, Pager, SelecetdItem or Separator. In this demo version we need only three of these; we need Header (For heading of each column), Item (for showing fields when GridView will be in normal mode) and EditItem (for showing fields when GridView will be in Edit mode).

FieldName keeps the name of each template field that will be displayed in the header.

InfoType keeps an indicator in string form for a type of information within a template field i.e. whether a template field has information of "Command" or "String" so that later data retrieval and data binding of that particular child control will be made accordingly. A "Command" (Edit, Delete, and Insert) requires instantiation in the Button control while he "String" requires a Label or TextBox.

Now, coming to the member methods listed above, there is a constructer which simply sets the aforementioned data members with those passed as parameters.

Listing 3

public DynamicallyTemplatedGridViewHandler(ListItemType item_type, string field_name,
string control_type)
{
ItemType = item_type;
FieldName = field_name;
InfoType = info_type;
}Here is the explanation of InstantiateIn the only method of ITemplate being implemented by our class DynamicallyTemplatedGridViewHandler.

InstantiateIn

InstantiateIn ensures that the list item type of each template is created in its appropriate control. For better understanding of functionality of this method see its name "InstantiateIn." It means "Instantiate Item In Literal/Label/TextBox/Button/." The choice will be according to the requirement. Like in the case of a Header, it is instantiated in Literal control as shown in this part of the implementation of InstantiateIn.

InstantiateIn takes a "Container," a Control type object as a parameter. Container's control collection is filled with all controls in which items of each type are instantiated. Its implementation in the current scenario is a little lengthy, yet it is quite easy as we have to do a similar type of job with each control; instantiate it, set its text property with FieldName and add it into Container's control collection.

For example, below the code of InstantiateIn shows that if the ItemType is a Header, then it creates a literal object called header_literal. After making it bold, set the text property of header_literal with FieldName. Finally, add this control to the control collection of the Container control passed as parameter to InstantiateIn method.

Similarly, we have to write instantiation code for ItemType if it is "Item" and "EditItem." In case the ItemType is "Item" (fields look when GridView is in normal mode), we need one more check inside it to see that InfoType tells whether the Item will be instantiated with a Button (Edit, Insert, and Delete) or Label. If InfoType is a Button then it creates three buttons for the aforementioned tasks. It is simple to do; create a button object, set its all properties accordingly, also add the button's click event handler and finally, add it into the control collection of the control (Container) passed as an argument.

Listing 4

public void InstantiateIn(System.Web.UI.Control Container)
{
switch (ItemType)
{
case ListItemType.Header:
Literal header_ltrl = new Literal();
header_ltrl.Text = "" + FieldName + "";
Container.Controls.Add(header_ltrl);
break;
case ListItemType.Item:
switch (InfoType)
{
case "Button":
ImageButton edit_button = new ImageButton();
edit_button.ID = "edit_button";
edit_button.ImageUrl = "~/images/edit.gif";
edit_button.CommandName = "Edit";
edit_button.Click += new ImageClickEventHandler(edit_button_Click);
edit_button.ToolTip = "Edit";
Container.Controls.Add(edit_button);
/*Similarly, add button for delete just set its
command to equal to "Delete." It is important to know when
"insert" button is added, its CommandName is set to "Edit" like
that of the "edi" button because we want the GridView to enter into
Edit mode and this time we also want the text boxes for corresponding fields
empty*/ ImageButton insert_button = new ImageButton();
insert_button.ID = "insert_button";
insert_button.ImageUrl = "~/images/insert.bmp";
insert_button.CommandName = "Edit";
insert_button.ToolTip = "Insert";
insert_button.Click += new ImageClickEventHandler(insert_button_Click);
Container.Controls.Add(insert_button);
default:
Label field_lbl = new Label();
field_lbl.ID = FieldName;
field_lbl.Text = String.Empty;
field_lbl.DataBinding += new EventHandler(OnDataBinding);
Container.Controls.Add(field_lbl);
break;
}
break;
case ListItemType.EditItem:
if (InfoType == "Button")
{
ImageButton update_button = new ImageButton();
update_button.ID = "update_button";
update_button.CommandName = "Update";
update_button.ImageUrl = "~/images/update.gif";
update_button.ToolTip = "Update";
update_button.OnClientClick =
"return confirm('Are you sure to update the record?')";
Container.Controls.Add(update_button);

// Similarly, add a button for Cancel

}
else
// if other key and non key fields then bind textboxes with texts
{
TextBox field_txtbox = new TextBox();
field_txtbox.ID = FieldName;
field_txtbox.Text = String.Empty;
// if to update then bind the textboxes with coressponding field texts
//otherwise for insert no need to bind it with text

if ((int)new Page().Session["InsertFlag"] == 0)
field_txtbox.DataBinding += new EventHandler(OnDataBinding);
Container.Controls.Add(field_txtbox);

}
break;
}
}When InfoType is not a Command it means we have to instantiate it with a label as in GridView's normal mode when each cell text of GridView's rows is displayed in label. Therefore, by default, control is instantiated with Label and is added into the Container. Since we have no more info types (other than command and string) then no further checks are required. We come to the outer check when ItemType is EditItem. Now, we need an inner check for info type (command or string). The template field will be instantiated in Button if the info type is Command; otherwise it requires TextBox for the cell text of edit item.

It is important to know that the CommandName of insert_button is set to "Edit" just to take advantage of the Edit mode that provides text boxes for all editable items. If the these text boxes are emptied, they can be used for insertion instead of editing without dedicating an extra row for it. This is easy and handy as it becomes a better approach when it is not known in advance how many columns there are in GridView's data source. I have taken a session variable InsertFlag that is set to 0 and 1 for Edit and Inert operations respectively.

Since we have to bind the labels in Item template and text boxes in EditItem template with corresponding cell values, the data binding event handler OnDataBinding of both label and text box populates the fields with cell values accordingly.

And you might also want to know how text boxes for each field get emptied when Insert button is clicked. The solution is simple; do not bind them with a database and apply a check while adding the data binding event handler of text box. Do not call OnDataBinding if the insert button is clicked.

Listing 5

if ((int)new Page().Session["InsertFlag"] == 0)
field_txtbox.DataBinding += new EventHandler(OnDataBinding);DataBinding Event Handler

The implementation of the data binding event handler "OnDataBindin"' is simple. First, we get the "bound_value_object" that is returned by the static method Eval of DataBinder class which takes two parameters. One is of type object called "data_item_container" (containing the DataItem that is assigned with sender control's NamingConatiner) and other is the string expression, FieldName. Once we get this bound_value_object, we assign its value (string) to the Text property of Label (if ItemType is Item; for normal mode) and TextBox (if ItemType is EditItem; for Edit mode).

Listing 6

private void OnDataBinding(object sender, EventArgs e)
{
object bound_value_obj = null;
Control ctrl = (Control)sender;
IDataItemContainer data_item_container =
(IDataItemContainer)ctrl.NamingContainer;
bound_value_obj = DataBinder.Eval(data_item_container.DataItem, FieldName);
switch (ItemType)
{
case ListItemType.Item:
Label field_ltrl = (Label)sender;
field_ltrl.Text = bound_value_obj.ToString();
break;
case ListItemType.EditItem:
TextBox field_txtbox = (TextBox)sender;
field_txtbox.Text = bound_value_obj.ToString();
break;
}
}The implementation of ITemplate is complete, although I want to mention that there are some event handlers, "insert_button_Click" and "edit_button_Click" for Insert and Edit buttons respectively. They do nothing except the former sets the Session[InsertFlag] to 1 and the later sets it to 0.

Some Interesting Codes

2010-04-18T03:07:00.000-07:00

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

/// <summary>
/// Developer : Belbinson Toby
/// </summary>
namespace Class
{

public interface IEmployee
{
         void Result();
}

public interface IDeveloper
{
        void Result();
}

public class Employee
{
        public void Result()
       {
          Console.WriteLine("Employee");
       }
}

public class Developer : Employee, IEmployee, IDeveloper
{

              void IEmployee.Result()
              {
                     Console.WriteLine("IEmployee");
              }

             void IDeveloper.Result()
            {
                     Console.WriteLine("IDeveloper");
            }

            public new void Result()
           {
                   Console.WriteLine("Developer");
           }

}

public class Program
{
static void Main(string[] args)
{

Developer objDeveloper = new Developer();
objDeveloper.Result();// This will call Result Method in Developer Class

Employee objEmployee = new Developer();
objEmployee.Result();// This will call Result Method in Employee Class

IEmployee objIe = new Developer();
objIe.Result();// This will call Result Method in IEmployee Class

IDeveloper objId = new Developer();
objId.Result();// // This will call Result Method in IDeveloper Class

Console.ReadLine();

}
}
}

Extension Methods (C# Programming Guide)

2010-04-07T06:33:00.000-07:00

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

Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.

The most common extension methods are the LINQ standard query operators that add query functionality to the existing System.Collections.IEnumerable and System.Collections.Generic.IEnumerable<T> types. To use the standard query operators, first bring them into scope with a using System.Linq directive. Then any type that implements IEnumerable<T> appears to have instance methods such as GroupBy, OrderBy, Average, and so on. You can see these additional methods in IntelliSense statement completion when you type "dot" after an instance of an IEnumerable<T> type such as List<T> or Array.

The following example shows how to call the standard query operator OrderBy method on an array of integers. The expression in parentheses is a lambda expression. Many standard query operators take lambda expressions as parameters, but this is not a requirement for extension methods. For more information, see Lambda Expressions (C# Programming Guide).

Constraints on Type Parameters (C# Programming Guide)

2010-04-07T06:31:00.000-07:00

http://msdn.microsoft.com/en-us/library/d5x73970(VS.80).aspx
When you define a generic class, you can apply restrictions to the kinds of types that client code can use for type arguments when it instantiates your class. If client code attempts to instantiate your class with a type that is not allowed by a constraint, the result is a compile-time error. These restrictions are called constraints. Constraints are specified using the where contextual keyword. The following table lists the six types of constraints:

Team Foundation Server...

2010-03-21T23:22:00.000-07:00

Team Foundation Server...

2010-03-21T23:14:00.001-07:00

Agile Scrum Methodology

2010-03-15T08:49:00.000-07:00

Use .NET's BackgroundWorker to Keep ASP.NET Cache in Sync with a SQL Server Database

2010-03-09T02:55:00.001-08:00

Introduction
Storing frequently accessed database data, like lookup lists, in ASP.NET’s cache is a great way to optimize a web application’s performance. But anytime you store database data in ASP.NET’s cache, you have to provide a way to update that cache. This ensures changes made in the database make it into the web application’s cache. This is handled using either notifications or polling.

Notifications are possible when using SQL Server 2005 with notification services and .NET’s SqlDependency object from the System.Data.SqlClient namespace. But notification services aren’t available in SQL Server 2008 or other databases. Even if you are using SQL Server 2005, employing this technology requires more server configuration and therefore complicates deployment.

Polling is often handled by setting an expiration of the cached item at some time interval such as hourly. That way the cache holds the data for an hour and then automatically dumps it. Then when the data is requested and the cache is empty, the data is read from the database and placed back into the cache. This approach works fairly well, but with two drawbacks. First, it requires the cache be refreshed even when it is not needed. Second, it runs on the same thread as the request so some unlucky user has to wait a little longer for their request to return while the data is read from the database and stored in the cache.

The BackgroundWorker object in .NET enables a better solution. When the web application starts, it spins off a background thread, and passes to it the application’s HttpContext object, enabling the thread, access to the application’s cache. When the web application ends, it stops the background thread. The background thread runs a continuous loop of sleeping for some time interval, and then polls the database to see if data has changed during that interval. If data has changed, the cache is refreshed. This solution is highly efficient because it runs on a background thread and refreshes the cache only when needed.

Writing CLS-Compliant Code

2010-03-09T02:21:00.001-08:00

Visual Studio Developer Center

Home Library Gallery Learn Downloads Support Community Forums

Classic | Lightweight Beta | ScriptFree

Printer Friendly Version
Add To Favorites
Send
Add Content...

MSDN Library

MSDN

MSDN Library

Development Tools and Languages

Visual Studio 2008

Visual Studio

.NET Framework Programming in Visua...

Overview of the .NET Framework

Cross-Language Interoperability

Writing CLS-Compliant Code

Collapse All

Language Filter

This page is specific to

Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:

.NET Framework Developer's Guide

Writing CLS-Compliant Code

Common Language Specification (CLS) compliance generally refers to the claim that CLS rules and restrictions are being followed. However, the concept has a more specific meaning depending on whether you are describing CLS-compliant code or CLS-compliant development tools, such as a compiler. CLS-compliant tools can help you write CLS-compliant code.

CLS-Compliant Code

If you want your code to be CLS-compliant, you must expose functionality in a way that is CLS-compliant in the following places:

Definitions of your public classes.
Definitions of the public members of public classes, and of members accessible to derived classes (family access).
Parameters and return types of public methods of public classes, and of methods accessible to derived classes.

The features you use in the definitions of your private classes, in the definitions of private methods on public classes, and in local variables do not have to follow the CLS rules. You can also use any language features you want in the code that implements your class and still have a CLS-compliant component.

Note:
Jagged arrays — that is, arrays of arrays — are CLS-compliant. In the .NET Framework version 1.0, the C# compiler mistakenly reports that they are not.

You can mark assemblies, modules, types, and members as either CLS-compliant or not CLS compliant using the CLSCompliantAttribute. All assemblies that are intended to be CLS-compliant should be marked as such. An assembly that is not marked as CLS-compliant is considered to be not CLS compliant. If no CLS attribute is applied to a type, that type is assumed to have the same CLS compliance as the assembly in which the type is defined. Similarly, if no CLS attribute is applied to a member, the member is considered to have the same CLS compliance as the type that defines it. You cannot mark a program element as CLS-compliant if its enclosing element is not marked as CLS-compliant. The example at the end of this topic illustrates the use of the CLSCompliantAttribute.

Assemblies, modules, and types can be CLS-compliant even if some parts of the assembly, module, or type are not CLS-compliant, as long as two conditions are met:

If the element is marked as CLS-compliant, the parts that are not CLS-compliant must be marked using the CLSCompliantAttribute with its argument set to false.
A comparable CLS-compliant alternative member must be supplied for each member that is not CLS-compliant.

If you design a CLS–compliant class library, your library will have a guarantee of interoperability with a wide range of programming languages; therefore, your library is likely to have a wider customer base than a version that is not CLS-compliant.

The .NET Framework provides a CLS-compliant class library. For more information about this class library, see .NET Framework Class Library.

CLS-Compliant Tools

Languages that target the runtime have agreed to support CLS features and follow the CLS rules directed to compilers. These language compilers simplify CLS compliance by making the CLS data types and features available for creating components. The levels of CLS compliance among compilers and other tools are described as follows:

CLS-compliant consumer tools.
Consumer tools are languages that enable developers to access all the features supplied by CLS-compliant libraries. Developers using these languages might not be able to extend CLS-compliant libraries by creating new types, but they can use any type defined by a compliant library. This level of compliance can be useful when you want to access a .NET Framework class library, but do not need to author new objects for consumption by others, such as when you are using Web Forms on an ASP.NET page or creating a Windows Forms user interface.
CLS-compliant extender tools.
Extender tools are languages that allow developers to both use and extend types defined in CLS-compliant libraries. Developers can use existing types as well as define new types. Extender tools must follow all the rules that consumer tools must follow, as well as some additional rules, which are described in the specification for the Common Language Infrastructure, Partition I - Architecture, available from the Microsoft Developer Network (MSDN) Web site.

When you design your own CLS-compliant components, it is helpful to use a CLS-compliant tool. Writing CLS-compliant components without this support is more difficult because otherwise you might not have access to all the CLS features you want to use.

Some CLS-compliant language compilers, such as the C# or Visual Basic compilers, enable you to specify that you intend your code to be CLS-compliant. These compilers can check for CLS compliance and let you know when your code uses functionality that is not supported by the CLS. The C# and Visual Basic compilers allow you to mark a program element as CLS-compliant, which will cause the compiler to generate a compile-time error if the code is not CLS-compliant. For example, the following code generates a compiler warning.

Visual Basic

Copy Code

<Assembly: CLSCompliant(True)>
 
<CLSCompliant(True)> Public Class MyCompliantClass
   Public Sub ChangeValue(value As UInt32)
   End Sub
 
   Public Shared Sub Main()
      Dim i As Integer = 2
      Console.WriteLine(i)
   End Sub   
End Class

Copy Code

using System;
 
// Assembly marked as compliant.
[assembly: CLSCompliant(true)]
 
// Class marked as compliant.
[CLSCompliant(true)]
public class MyCompliantClass {
   // ChangeValue exposes UInt32, which is not in CLS.
   // A compile-time warning results.
   public void ChangeValue(UInt32 value){ }
 
   public static void Main( ) {
   int i = 2;
   Console.WriteLine(i);
   }
}

This code generates the following C# warning:

Copy Code

warning CS3001: Argument type 'uint' is not CLS-compliant

or the following Visual Basic warning:

Copy Code

warning BC40028: Type of parameter 'value' is not CLS-compliant.

To remove the warning, you can indicate that ChangeValue is not compliant, as shown in the following example.

Visual Basic

Copy Code

' Assembly marked as compliant.
<Assembly: CLSCompliant(True)>
 
' Class marked as compliant.
<CLSCompliant(True)> Public Class MyCompliantClass
   ' Method marked as not compliant.
   <CLSCompliant(False)> Public Sub ChangeValue(value As UInt32)
   End Sub
 
   Public Shared Sub Main()
      Dim i As Integer = 2
      Console.WriteLine(i)
   End Sub   
End Class

Copy Code

using System;
 
// Assembly marked as compliant.
[assembly: CLSCompliantAttribute(true)]
 
// Class marked as compliant.
[CLSCompliantAttribute(true)]
public class MyCompliantClass {
   // Method marked as not compliant.
   [CLSCompliantAttribute(false)]
   public void ChangeValue(UInt32 value){ }
 
   public static void Main( ) {
   int i = 2;
   Console.WriteLine(i);
   }
}

This code produces no compiler warnings. The output is 2.

For more information about how to specify the CLS-compliance of your code, see the documentation for the language compiler you are using.

Concepts

Language Interoperability Overview

Other Resources

Cross-Language Interoperability

Tags

:

Add a tag

Community Content

Add new content

Annotations

BackgroundWorker Class

2010-03-09T00:52:00.000-08:00

Visual Basic (Declaration)

<HostProtectionAttribute(SecurityAction.LinkDemand, SharedState := True)> _
Public Class BackgroundWorker _
    Inherits Component

Visual Basic (Usage)

Dim instance As BackgroundWorker

[HostProtectionAttribute(SecurityAction.LinkDemand, SharedState = true)]
public class BackgroundWorker : Component

Visual C++

[HostProtectionAttribute(SecurityAction::LinkDemand, SharedState = true)]
public ref class BackgroundWorker : public Component

JScript

public class BackgroundWorker extends Component

Remarks

Note:
The HostProtectionAttribute attribute applied to this type or member has the following Resources property value: SharedState. The HostProtectionAttribute does not affect desktop applications (which are typically started by double-clicking an icon, typing a command, or entering a URL in a browser). For more information, see the HostProtectionAttribute class or SQL Server Programming and Host Protection Attributes.

Note:

The HostProtectionAttribute attribute applied to this type or member has the following Resources property value: SharedState. The HostProtectionAttribute does not affect desktop applications (which are typically started by double-clicking an icon, typing a command, or entering a URL in a browser). For more information, see the HostProtectionAttribute class or SQL Server Programming and Host Protection Attributes.

The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.
To execute a time-consuming operation in the background, create a BackgroundWorker and listen for events that report the progress of your operation and signal when your operation is finished. You can create the BackgroundWorker programmatically or you can drag it onto your form from the Components tab of the Toolbox. If you create the BackgroundWorker in the Windows Forms Designer, it will appear in the Component Tray, and its properties will be displayed in the Properties window.
To set up for a background operation, add an event handler for the DoWork event. Call your time-consuming operation in this event handler. To start the operation, call RunWorkerAsync. To receive notifications of progress updates, handle the ProgressChanged event. To receive a notification when the operation is completed, handle the RunWorkerCompleted event.

Note:
You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the ProgressChanged and RunWorkerCompleted events. BackgroundWorker events are not marshaled across AppDomain boundaries. Do not use a BackgroundWorker component to perform multithreaded operations in more than one AppDomain.

If your background operation requires a parameter, call RunWorkerAsync with your parameter. Inside the DoWork event handler, you can extract the parameter from the DoWorkEventArgs..::.Argument property.
For more information about BackgroundWorker, see How to: Run an Operation in the Background.

Examples

The following code example demonstrates the use of the BackgroundWorker class for executing a time-consuming operation asynchronously. The operation computes the selected Fibonacci number, reports progress updates as the calculation proceeds, and permits a pending calculation to be canceled.

Visual Basic

Imports System
Imports System.Collections
Imports System.ComponentModel
Imports System.Drawing
Imports System.Threading
Imports System.Windows.Forms
 
Public Class FibonacciForm
    Inherits System.Windows.Forms.Form
 
    Private numberToCompute As Integer = 0
    Private highestPercentageReached As Integer = 0
 
    Private numericUpDown1 As System.Windows.Forms.NumericUpDown
    Private WithEvents startAsyncButton As System.Windows.Forms.Button
    Private WithEvents cancelAsyncButton As System.Windows.Forms.Button
    Private progressBar1 As System.Windows.Forms.ProgressBar
    Private resultLabel As System.Windows.Forms.Label
    Private WithEvents backgroundWorker1 As System.ComponentModel.BackgroundWorker
 
 
    Public Sub New()
        InitializeComponent()
    End Sub 'New
 
    Private Sub startAsyncButton_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
    Handles startAsyncButton.Click
 
        ' Reset the text in the result label.
        resultLabel.Text = [String].Empty
 
        ' Disable the UpDown control until 
        ' the asynchronous operation is done.
        Me.numericUpDown1.Enabled = False
 
        ' Disable the Start button until 
        ' the asynchronous operation is done.
        Me.startAsyncButton.Enabled = False
 
        ' Enable the Cancel button while 
        ' the asynchronous operation runs.
        Me.cancelAsyncButton.Enabled = True
 
        ' Get the value from the UpDown control.
        numberToCompute = CInt(numericUpDown1.Value)
 
        ' Reset the variable for percentage tracking.
        highestPercentageReached = 0
 
 
        ' Start the asynchronous operation.
        backgroundWorker1.RunWorkerAsync(numberToCompute)
    End Sub 
 
    Private Sub cancelAsyncButton_Click( _
    ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
    Handles cancelAsyncButton.Click
 
        ' Cancel the asynchronous operation.
        Me.backgroundWorker1.CancelAsync()
 
        ' Disable the Cancel button.
        cancelAsyncButton.Enabled = False
 
    End Sub 'cancelAsyncButton_Click
 
    ' This event handler is where the actual work is done.
    Private Sub backgroundWorker1_DoWork( _
    ByVal sender As Object, _
    ByVal e As DoWorkEventArgs) _
    Handles backgroundWorker1.DoWork
 
        ' Get the BackgroundWorker object that raised this event.
        Dim worker As BackgroundWorker = _
            CType(sender, BackgroundWorker)
 
        ' Assign the result of the computation
        ' to the Result property of the DoWorkEventArgs
        ' object. This is will be available to the 
        ' RunWorkerCompleted eventhandler.
        e.Result = ComputeFibonacci(e.Argument, worker, e)
    End Sub 'backgroundWorker1_DoWork
 
    ' This event handler deals with the results of the
    ' background operation.
    Private Sub backgroundWorker1_RunWorkerCompleted( _
    ByVal sender As Object, ByVal e As RunWorkerCompletedEventArgs) _
    Handles backgroundWorker1.RunWorkerCompleted
 
        ' First, handle the case where an exception was thrown.
        If (e.Error IsNot Nothing) Then
            MessageBox.Show(e.Error.Message)
        ElseIf e.Cancelled Then
            ' Next, handle the case where the user canceled the 
            ' operation.
            ' Note that due to a race condition in 
            ' the DoWork event handler, the Cancelled
            ' flag may not have been set, even though
            ' CancelAsync was called.
            resultLabel.Text = "Canceled"
        Else
            ' Finally, handle the case where the operation succeeded.
            resultLabel.Text = e.Result.ToString()
        End If
 
        ' Enable the UpDown control.
        Me.numericUpDown1.Enabled = True
 
        ' Enable the Start button.
        startAsyncButton.Enabled = True
 
        ' Disable the Cancel button.
        cancelAsyncButton.Enabled = False
    End Sub 'backgroundWorker1_RunWorkerCompleted
 
    ' This event handler updates the progress bar.
    Private Sub backgroundWorker1_ProgressChanged( _
    ByVal sender As Object, ByVal e As ProgressChangedEventArgs) _
    Handles backgroundWorker1.ProgressChanged
 
        Me.progressBar1.Value = e.ProgressPercentage
 
    End Sub
 
    ' This is the method that does the actual work. For this
    ' example, it computes a Fibonacci number and
    ' reports progress as it does its work.
    Function ComputeFibonacci( _
        ByVal n As Integer, _
        ByVal worker As BackgroundWorker, _
        ByVal e As DoWorkEventArgs) As Long
 
        ' The parameter n must be >= 0 and <= 91.
        ' Fib(n), with n > 91, overflows a long.
        If n < 0 OrElse n > 91 Then
            Throw New ArgumentException( _
                "value must be >= 0 and <= 91", "n")
        End If
 
        Dim result As Long = 0
 
        ' Abort the operation if the user has canceled.
        ' Note that a call to CancelAsync may have set 
        ' CancellationPending to true just after the
        ' last invocation of this method exits, so this 
        ' code will not have the opportunity to set the 
        ' DoWorkEventArgs.Cancel flag to true. This means
        ' that RunWorkerCompletedEventArgs.Cancelled will
        ' not be set to true in your RunWorkerCompleted
        ' event handler. This is a race condition.
        If worker.CancellationPending Then
            e.Cancel = True
        Else
            If n < 2 Then
                result = 1
            Else
                result = ComputeFibonacci(n - 1, worker, e) + _
                         ComputeFibonacci(n - 2, worker, e)
            End If
 
            ' Report progress as a percentage of the total task.
            Dim percentComplete As Integer = _
                CSng(n) / CSng(numberToCompute) * 100
            If percentComplete > highestPercentageReached Then
                highestPercentageReached = percentComplete
                worker.ReportProgress(percentComplete)
            End If
 
        End If
 
        Return result
 
    End Function
 
 
    Private Sub InitializeComponent()
        Me.numericUpDown1 = New System.Windows.Forms.NumericUpDown
        Me.startAsyncButton = New System.Windows.Forms.Button
        Me.cancelAsyncButton = New System.Windows.Forms.Button
        Me.resultLabel = New System.Windows.Forms.Label
        Me.progressBar1 = New System.Windows.Forms.ProgressBar
        Me.backgroundWorker1 = New System.ComponentModel.BackgroundWorker
        CType(Me.numericUpDown1, System.ComponentModel.ISupportInitialize).BeginInit()
        Me.SuspendLayout()
        '
        'numericUpDown1
        '
        Me.numericUpDown1.Location = New System.Drawing.Point(16, 16)
        Me.numericUpDown1.Maximum = New Decimal(New Integer() {91, 0, 0, 0})
        Me.numericUpDown1.Minimum = New Decimal(New Integer() {1, 0, 0, 0})
        Me.numericUpDown1.Name = "numericUpDown1"
        Me.numericUpDown1.Size = New System.Drawing.Size(80, 20)
        Me.numericUpDown1.TabIndex = 0
        Me.numericUpDown1.Value = New Decimal(New Integer() {1, 0, 0, 0})
        '
        'startAsyncButton
        '
        Me.startAsyncButton.Location = New System.Drawing.Point(16, 72)
        Me.startAsyncButton.Name = "startAsyncButton"
        Me.startAsyncButton.Size = New System.Drawing.Size(120, 23)
        Me.startAsyncButton.TabIndex = 1
        Me.startAsyncButton.Text = "Start Async"
        '
        'cancelAsyncButton
        '
        Me.cancelAsyncButton.Enabled = False
        Me.cancelAsyncButton.Location = New System.Drawing.Point(153, 72)
        Me.cancelAsyncButton.Name = "cancelAsyncButton"
        Me.cancelAsyncButton.Size = New System.Drawing.Size(119, 23)
        Me.cancelAsyncButton.TabIndex = 2
        Me.cancelAsyncButton.Text = "Cancel Async"
        '
        'resultLabel
        '
        Me.resultLabel.BorderStyle = System.Windows.Forms.BorderStyle.Fixed3D
        Me.resultLabel.Location = New System.Drawing.Point(112, 16)
        Me.resultLabel.Name = "resultLabel"
        Me.resultLabel.Size = New System.Drawing.Size(160, 23)
        Me.resultLabel.TabIndex = 3
        Me.resultLabel.Text = "(no result)"
        Me.resultLabel.TextAlign = System.Drawing.ContentAlignment.MiddleCenter
        '
        'progressBar1
        '
        Me.progressBar1.Location = New System.Drawing.Point(18, 48)
        Me.progressBar1.Name = "progressBar1"
        Me.progressBar1.Size = New System.Drawing.Size(256, 8)
        Me.progressBar1.TabIndex = 4
        '
        'backgroundWorker1
        '
        Me.backgroundWorker1.WorkerReportsProgress = True
        Me.backgroundWorker1.WorkerSupportsCancellation = True
        '
        'FibonacciForm
        '
        Me.ClientSize = New System.Drawing.Size(292, 118)
        Me.Controls.Add(Me.progressBar1)
        Me.Controls.Add(Me.resultLabel)
        Me.Controls.Add(Me.cancelAsyncButton)
        Me.Controls.Add(Me.startAsyncButton)
        Me.Controls.Add(Me.numericUpDown1)
        Me.Name = "FibonacciForm"
        Me.Text = "Fibonacci Calculator"
        CType(Me.numericUpDown1, System.ComponentModel.ISupportInitialize).EndInit()
        Me.ResumeLayout(False)
 
    End Sub 'InitializeComponent
 
    <STAThread()> _
    Shared Sub Main()
        Application.Run(New FibonacciForm)
    End Sub 'Main
End Class 'FibonacciForm

using System;
using System.Collections;
using System.ComponentModel;
using System.Drawing;
using System.Threading;
using System.Windows.Forms;
 
namespace BackgroundWorkerExample
{    
    public class FibonacciForm : System.Windows.Forms.Form
    {    
        private int numberToCompute = 0;
        private int highestPercentageReached = 0;
 
        private System.Windows.Forms.NumericUpDown numericUpDown1;
        private System.Windows.Forms.Button startAsyncButton;
        private System.Windows.Forms.Button cancelAsyncButton;
        private System.Windows.Forms.ProgressBar progressBar1;
        private System.Windows.Forms.Label resultLabel;
        private System.ComponentModel.BackgroundWorker backgroundWorker1;
 
        public FibonacciForm()
        {    
            InitializeComponent();
 
            InitializeBackgroundWorker();
        }
 
        // Set up the BackgroundWorker object by 
        // attaching event handlers. 
        private void InitializeBackgroundWorker()
        {
            backgroundWorker1.DoWork += 
                new DoWorkEventHandler(backgroundWorker1_DoWork);
            backgroundWorker1.RunWorkerCompleted += 
                new RunWorkerCompletedEventHandler(
            backgroundWorker1_RunWorkerCompleted);
            backgroundWorker1.ProgressChanged += 
                new ProgressChangedEventHandler(
            backgroundWorker1_ProgressChanged);
        }
    
        private void startAsyncButton_Click(System.Object sender, 
            System.EventArgs e)
        {
            // Reset the text in the result label.
            resultLabel.Text = String.Empty;
 
            // Disable the UpDown control until 
            // the asynchronous operation is done.
            this.numericUpDown1.Enabled = false;
 
            // Disable the Start button until 
            // the asynchronous operation is done.
            this.startAsyncButton.Enabled = false;
 
            // Enable the Cancel button while 
            // the asynchronous operation runs.
            this.cancelAsyncButton.Enabled = true;
 
            // Get the value from the UpDown control.
            numberToCompute = (int)numericUpDown1.Value;
 
            // Reset the variable for percentage tracking.
            highestPercentageReached = 0;
 
            // Start the asynchronous operation.
            backgroundWorker1.RunWorkerAsync(numberToCompute);
        }
 
        private void cancelAsyncButton_Click(System.Object sender, 
            System.EventArgs e)
        {   
            // Cancel the asynchronous operation.
            this.backgroundWorker1.CancelAsync();
 
            // Disable the Cancel button.
            cancelAsyncButton.Enabled = false;
        }
 
        // This event handler is where the actual,
        // potentially time-consuming work is done.
        private void backgroundWorker1_DoWork(object sender, 
            DoWorkEventArgs e)
        {   
            // Get the BackgroundWorker that raised this event.
            BackgroundWorker worker = sender as BackgroundWorker;
 
            // Assign the result of the computation
            // to the Result property of the DoWorkEventArgs
            // object. This is will be available to the 
            // RunWorkerCompleted eventhandler.
            e.Result = ComputeFibonacci((int)e.Argument, worker, e);
        }
 
        // This event handler deals with the results of the
        // background operation.
        private void backgroundWorker1_RunWorkerCompleted(
            object sender, RunWorkerCompletedEventArgs e)
        {
            // First, handle the case where an exception was thrown.
            if (e.Error != null)
            {
                MessageBox.Show(e.Error.Message);
            }
            else if (e.Cancelled)
            {
                // Next, handle the case where the user canceled 
                // the operation.
                // Note that due to a race condition in 
                // the DoWork event handler, the Cancelled
                // flag may not have been set, even though
                // CancelAsync was called.
                resultLabel.Text = "Canceled";
            }
            else
            {
                // Finally, handle the case where the operation 
                // succeeded.
                resultLabel.Text = e.Result.ToString();
            }
 
            // Enable the UpDown control.
            this.numericUpDown1.Enabled = true;
 
            // Enable the Start button.
            startAsyncButton.Enabled = true;
 
            // Disable the Cancel button.
            cancelAsyncButton.Enabled = false;
        }
 
        // This event handler updates the progress bar.
        private void backgroundWorker1_ProgressChanged(object sender,
            ProgressChangedEventArgs e)
        {
            this.progressBar1.Value = e.ProgressPercentage;
        }
 
        // This is the method that does the actual work. For this
        // example, it computes a Fibonacci number and
        // reports progress as it does its work.
        long ComputeFibonacci(int n, BackgroundWorker worker, DoWorkEventArgs e)
        {
            // The parameter n must be >= 0 and <= 91.
            // Fib(n), with n > 91, overflows a long.
            if ((n < 0) || (n > 91))
            {
                throw new ArgumentException(
                    "value must be >= 0 and <= 91", "n");
            }
 
            long result = 0;
 
            // Abort the operation if the user has canceled.
            // Note that a call to CancelAsync may have set 
            // CancellationPending to true just after the
            // last invocation of this method exits, so this 
            // code will not have the opportunity to set the 
            // DoWorkEventArgs.Cancel flag to true. This means
            // that RunWorkerCompletedEventArgs.Cancelled will
            // not be set to true in your RunWorkerCompleted
            // event handler. This is a race condition.
 
            if (worker.CancellationPending)
            {   
                e.Cancel = true;
            }
            else
            {   
                if (n < 2)
                {   
                    result = 1;
                }
                else
                {   
                    result = ComputeFibonacci(n - 1, worker, e) + 
                             ComputeFibonacci(n - 2, worker, e);
                }
 
                // Report progress as a percentage of the total task.
                int percentComplete = 
                    (int)((float)n / (float)numberToCompute * 100);
                if (percentComplete > highestPercentageReached)
                {
                    highestPercentageReached = percentComplete;
                    worker.ReportProgress(percentComplete);
                }
            }
 
            return result;
        }
 
 
        #region Windows Form Designer generated code
        
        private void InitializeComponent()
        {
            this.numericUpDown1 = new System.Windows.Forms.NumericUpDown();
            this.startAsyncButton = new System.Windows.Forms.Button();
            this.cancelAsyncButton = new System.Windows.Forms.Button();
            this.resultLabel = new System.Windows.Forms.Label();
            this.progressBar1 = new System.Windows.Forms.ProgressBar();
            this.backgroundWorker1 = new System.ComponentModel.BackgroundWorker();
            ((System.ComponentModel.ISupportInitialize)(this.numericUpDown1)).BeginInit();
            this.SuspendLayout();
            // 
            // numericUpDown1
            // 
            this.numericUpDown1.Location = new System.Drawing.Point(16, 16);
            this.numericUpDown1.Maximum = new System.Decimal(new int[] {
            91,
            0,
            0,
            0});
            this.numericUpDown1.Minimum = new System.Decimal(new int[] {
            1,
            0,
            0,
            0});
            this.numericUpDown1.Name = "numericUpDown1";
            this.numericUpDown1.Size = new System.Drawing.Size(80, 20);
            this.numericUpDown1.TabIndex = 0;
            this.numericUpDown1.Value = new System.Decimal(new int[] {
            1,
            0,
            0,
            0});
            // 
            // startAsyncButton
            // 
            this.startAsyncButton.Location = new System.Drawing.Point(16, 72);
            this.startAsyncButton.Name = "startAsyncButton";
            this.startAsyncButton.Size = new System.Drawing.Size(120, 23);
            this.startAsyncButton.TabIndex = 1;
            this.startAsyncButton.Text = "Start Async";
            this.startAsyncButton.Click += new System.EventHandler(this.startAsyncButton_Click);
            // 
            // cancelAsyncButton
            // 
            this.cancelAsyncButton.Enabled = false;
            this.cancelAsyncButton.Location = new System.Drawing.Point(153, 72);
            this.cancelAsyncButton.Name = "cancelAsyncButton";
            this.cancelAsyncButton.Size = new System.Drawing.Size(119, 23);
            this.cancelAsyncButton.TabIndex = 2;
            this.cancelAsyncButton.Text = "Cancel Async";
            this.cancelAsyncButton.Click += new System.EventHandler(this.cancelAsyncButton_Click);
            // 
            // resultLabel
            // 
            this.resultLabel.BorderStyle = System.Windows.Forms.BorderStyle.Fixed3D;
            this.resultLabel.Location = new System.Drawing.Point(112, 16);
            this.resultLabel.Name = "resultLabel";
            this.resultLabel.Size = new System.Drawing.Size(160, 23);
            this.resultLabel.TabIndex = 3;
            this.resultLabel.Text = "(no result)";
            this.resultLabel.TextAlign = System.Drawing.ContentAlignment.MiddleCenter;
            // 
            // progressBar1
            // 
            this.progressBar1.Location = new System.Drawing.Point(18, 48);
            this.progressBar1.Name = "progressBar1";
            this.progressBar1.Size = new System.Drawing.Size(256, 8);
            this.progressBar1.Step = 2;
            this.progressBar1.TabIndex = 4;
            // 
            // backgroundWorker1
            // 
            this.backgroundWorker1.WorkerReportsProgress = true;
            this.backgroundWorker1.WorkerSupportsCancellation = true;
            // 
            // FibonacciForm
            // 
            this.ClientSize = new System.Drawing.Size(292, 118);
            this.Controls.Add(this.progressBar1);
            this.Controls.Add(this.resultLabel);
            this.Controls.Add(this.cancelAsyncButton);
            this.Controls.Add(this.startAsyncButton);
            this.Controls.Add(this.numericUpDown1);
            this.Name = "FibonacciForm";
            this.Text = "Fibonacci Calculator";
            ((System.ComponentModel.ISupportInitialize)(this.numericUpDown1)).EndInit();
            this.ResumeLayout(false);
 
        }
        #endregion
 
        [STAThread]
        static void Main()
        {
            Application.Run(new FibonacciForm());
        }
    }
}

Visual C++

#using <System.Drawing.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>
 
using namespace System;
using namespace System::Collections;
using namespace System::ComponentModel;
using namespace System::Drawing;
using namespace System::Threading;
using namespace System::Windows::Forms;
 
public ref class FibonacciForm: public System::Windows::Forms::Form
{
private:
 
   int numberToCompute;
   int highestPercentageReached;
 
   System::Windows::Forms::NumericUpDown^ numericUpDown1;
   System::Windows::Forms::Button^ startAsyncButton;
   System::Windows::Forms::Button^ cancelAsyncButton;
   System::Windows::Forms::ProgressBar^ progressBar1;
   System::Windows::Forms::Label ^ resultLabel;
   System::ComponentModel::BackgroundWorker^ backgroundWorker1;
 
public:
   FibonacciForm()
   {
      InitializeComponent();
      numberToCompute = highestPercentageReached = 0;
      InitializeBackgoundWorker();
   }
 
 
private:
 
   // Set up the BackgroundWorker object by 
   // attaching event handlers. 
   void InitializeBackgoundWorker()
   {
      backgroundWorker1->DoWork += gcnew DoWorkEventHandler( this, &FibonacciForm::backgroundWorker1_DoWork );
      backgroundWorker1->RunWorkerCompleted += gcnew RunWorkerCompletedEventHandler( this, &FibonacciForm::backgroundWorker1_RunWorkerCompleted );
      backgroundWorker1->ProgressChanged += gcnew ProgressChangedEventHandler( this, &FibonacciForm::backgroundWorker1_ProgressChanged );
   }
 
   void startAsyncButton_Click( System::Object^ /*sender*/, System::EventArgs^ /*e*/ )
   {
 
      // Reset the text in the result label.
      resultLabel->Text = String::Empty;
 
      // Disable the UpDown control until 
      // the asynchronous operation is done.
      this->numericUpDown1->Enabled = false;
 
      // Disable the Start button until 
      // the asynchronous operation is done.
      this->startAsyncButton->Enabled = false;
 
      // Enable the Cancel button while 
      // the asynchronous operation runs.
      this->cancelAsyncButton->Enabled = true;
 
      // Get the value from the UpDown control.
      numberToCompute = (int)numericUpDown1->Value;
 
      // Reset the variable for percentage tracking.
      highestPercentageReached = 0;
 
      // Start the asynchronous operation.
      backgroundWorker1->RunWorkerAsync( numberToCompute );
   }
 
   void cancelAsyncButton_Click( System::Object^ /*sender*/, System::EventArgs^ /*e*/ )
   {  
      // Cancel the asynchronous operation.
      this->backgroundWorker1->CancelAsync();
 
      // Disable the Cancel button.
      cancelAsyncButton->Enabled = false;
   }
 
   // This event handler is where the actual,
   // potentially time-consuming work is done.
   void backgroundWorker1_DoWork( Object^ sender, DoWorkEventArgs^ e )
   {
      // Get the BackgroundWorker that raised this event.
      BackgroundWorker^ worker = dynamic_cast<BackgroundWorker^>(sender);
 
      // Assign the result of the computation
      // to the Result property of the DoWorkEventArgs
      // object. This is will be available to the 
      // RunWorkerCompleted eventhandler.
      e->Result = ComputeFibonacci( safe_cast<Int32>(e->Argument), worker, e );
   }
 
   // This event handler deals with the results of the
   // background operation.
   void backgroundWorker1_RunWorkerCompleted( Object^ /*sender*/, RunWorkerCompletedEventArgs^ e )
   {
      // First, handle the case where an exception was thrown.
      if ( e->Error != nullptr )
      {
         MessageBox::Show( e->Error->Message );
      }
      else
      if ( e->Cancelled )
      {
         // Next, handle the case where the user cancelled 
         // the operation.
         // Note that due to a race condition in 
         // the DoWork event handler, the Cancelled
         // flag may not have been set, even though
         // CancelAsync was called.
         resultLabel->Text = "Cancelled";
      }
      else
      {
         // Finally, handle the case where the operation 
         // succeeded.
         resultLabel->Text = e->Result->ToString();
      }
 
      // Enable the UpDown control.
      this->numericUpDown1->Enabled = true;
 
      // Enable the Start button.
      startAsyncButton->Enabled = true;
 
      // Disable the Cancel button.
      cancelAsyncButton->Enabled = false;
   }
 
   // This event handler updates the progress bar.
   void backgroundWorker1_ProgressChanged( Object^ /*sender*/, ProgressChangedEventArgs^ e )
   {
      this->progressBar1->Value = e->ProgressPercentage;
   }
 
   // This is the method that does the actual work. For this
   // example, it computes a Fibonacci number and
   // reports progress as it does its work.
   long ComputeFibonacci( int n, BackgroundWorker^ worker, DoWorkEventArgs ^ e )
   {
      // The parameter n must be >= 0 and <= 91.
      // Fib(n), with n > 91, overflows a long.
      if ( (n < 0) || (n > 91) )
      {
         throw gcnew ArgumentException( "value must be >= 0 and <= 91","n" );
      }
 
      long result = 0;
 
      // Abort the operation if the user has cancelled.
      // Note that a call to CancelAsync may have set 
      // CancellationPending to true just after the
      // last invocation of this method exits, so this 
      // code will not have the opportunity to set the 
      // DoWorkEventArgs.Cancel flag to true. This means
      // that RunWorkerCompletedEventArgs.Cancelled will
      // not be set to true in your RunWorkerCompleted
      // event handler. This is a race condition.
      if ( worker->CancellationPending )
      {
         e->Cancel = true;
      }
      else
      {
         if ( n < 2 )
         {
            result = 1;
         }
         else
         {
            result = ComputeFibonacci( n - 1, worker, e ) + ComputeFibonacci( n - 2, worker, e );
         }
 
         // Report progress as a percentage of the total task.
         int percentComplete = (int)((float)n / (float)numberToCompute * 100);
         if ( percentComplete > highestPercentageReached )
         {
            highestPercentageReached = percentComplete;
            worker->ReportProgress( percentComplete );
         }
      }
 
      return result;
   }
 
   void InitializeComponent()
   {
      this->numericUpDown1 = gcnew System::Windows::Forms::NumericUpDown;
      this->startAsyncButton = gcnew System::Windows::Forms::Button;
      this->cancelAsyncButton = gcnew System::Windows::Forms::Button;
      this->resultLabel = gcnew System::Windows::Forms::Label;
      this->progressBar1 = gcnew System::Windows::Forms::ProgressBar;
      this->backgroundWorker1 = gcnew System::ComponentModel::BackgroundWorker;
      (dynamic_cast<System::ComponentModel::ISupportInitialize^>(this->numericUpDown1))->BeginInit();
      this->SuspendLayout();
 
      // 
      // numericUpDown1
      // 
      this->numericUpDown1->Location = System::Drawing::Point( 16, 16 );
      array<Int32>^temp0 = {91,0,0,0};
      this->numericUpDown1->Maximum = System::Decimal( temp0 );
      array<Int32>^temp1 = {1,0,0,0};
      this->numericUpDown1->Minimum = System::Decimal( temp1 );
      this->numericUpDown1->Name = "numericUpDown1";
      this->numericUpDown1->Size = System::Drawing::Size( 80, 20 );
      this->numericUpDown1->TabIndex = 0;
      array<Int32>^temp2 = {1,0,0,0};
      this->numericUpDown1->Value = System::Decimal( temp2 );
 
      // 
      // startAsyncButton
      // 
      this->startAsyncButton->Location = System::Drawing::Point( 16, 72 );
      this->startAsyncButton->Name = "startAsyncButton";
      this->startAsyncButton->Size = System::Drawing::Size( 120, 23 );
      this->startAsyncButton->TabIndex = 1;
      this->startAsyncButton->Text = "Start Async";
      this->startAsyncButton->Click += gcnew System::EventHandler( this, &FibonacciForm::startAsyncButton_Click );
 
      // 
      // cancelAsyncButton
      // 
      this->cancelAsyncButton->Enabled = false;
      this->cancelAsyncButton->Location = System::Drawing::Point( 153, 72 );
      this->cancelAsyncButton->Name = "cancelAsyncButton";
      this->cancelAsyncButton->Size = System::Drawing::Size( 119, 23 );
      this->cancelAsyncButton->TabIndex = 2;
      this->cancelAsyncButton->Text = "Cancel Async";
      this->cancelAsyncButton->Click += gcnew System::EventHandler( this, &FibonacciForm::cancelAsyncButton_Click );
 
      // 
      // resultLabel
      // 
      this->resultLabel->BorderStyle = System::Windows::Forms::BorderStyle::Fixed3D;
      this->resultLabel->Location = System::Drawing::Point( 112, 16 );
      this->resultLabel->Name = "resultLabel";
      this->resultLabel->Size = System::Drawing::Size( 160, 23 );
      this->resultLabel->TabIndex = 3;
      this->resultLabel->Text = "(no result)";
      this->resultLabel->TextAlign = System::Drawing::ContentAlignment::MiddleCenter;
 
      // 
      // progressBar1
      // 
      this->progressBar1->Location = System::Drawing::Point( 18, 48 );
      this->progressBar1->Name = "progressBar1";
      this->progressBar1->Size = System::Drawing::Size( 256, 8 );
      this->progressBar1->Step = 2;
      this->progressBar1->TabIndex = 4;
 
      // 
      // backgroundWorker1
      // 
      this->backgroundWorker1->WorkerReportsProgress = true;
      this->backgroundWorker1->WorkerSupportsCancellation = true;
 
      // 
      // FibonacciForm
      // 
      this->ClientSize = System::Drawing::Size( 292, 118 );
      this->Controls->Add( this->progressBar1 );
      this->Controls->Add( this->resultLabel );
      this->Controls->Add( this->cancelAsyncButton );
      this->Controls->Add( this->startAsyncButton );
      this->Controls->Add( this->numericUpDown1 );
      this->Name = "FibonacciForm";
      this->Text = "Fibonacci Calculator";
      (dynamic_cast<System::ComponentModel::ISupportInitialize^>(this->numericUpDown1))->EndInit();
      this->ResumeLayout( false );
   }
};
 
[STAThread]
int main()
{
   Application::Run( gcnew FibonacciForm );
}

ASP.NET Forms Authentication Overview

2010-03-03T23:28:00.000-08:00

http://msdn.microsoft.com/en-us/library/7t6b43z4.aspx
Forms authentication lets you authenticate users by using your own code and then maintain an authentication token in a cookie or in the page URL. Forms authentication participates in the ASP.NET page life cycle through the FormsAuthenticationModule class. You can access forms authentication information and capabilities through the FormsAuthentication class.
To use forms authentication, you create a login page that collects credentials from the user and that includes code to authenticate the credentials. Typically you configure the application to redirect requests to the login page when users try to access a protected resource, such as a page that requires authentication. If the user's credentials are valid, you can call methods of the FormsAuthentication class to redirect the request back to the originally requested resource with an appropriate authentication ticket (cookie). If you do not want the redirection, you can just get the forms authentication cookie or set it. On subsequent requests, the user's browser passes the authentication cookie with the request, which then bypasses the login page.
You configure forms authentication by using the authentication configuration element. In the simplest case, you have a login page. In the configuration file, you specify a URL to redirect unauthenticated requests to the login page. You then define valid credentials, either in the Web.config file or in a separate file. The following example shows a section from a configuration file that specifies a login page and authentication credentials for the Authenticate method. The passwords have been encrypted by using the HashPasswordForStoringInConfigFile method.

Copy Code

<authentication mode="Forms">
   <forms name="SavingsPlan" loginUrl="/Login.aspx">
      <credentials passwordFormat="SHA1">
         <user name="Kim"
               password="07B7F3EE06F278DB966BE960E7CBBD103DF30CA6"/>
         <user name="John"
               password="BA56E5E0366D003E98EA1C7F04ABF8FCB3753889"/>
      </credentials>
   </forms>
</authentication>

After successful authentication, the FormsAuthenticationModule module sets the value of the User property to a reference to the authenticated user. The following code example shows how to programmatically read the identity of the forms-authenticated user.
C#

Visual Basic

Copy Code

Dim authUser2 As String = User.Identity.Name

Copy Code

String authUser2 = User.Identity.Name;

Forms Authentication, ASP.NET Membership, and Login Controls

A convenient way to work with forms authentication is to use ASP.NET membership and ASP.NET login controls. ASP.NET membership lets you store and manage user information and includes methods to authenticate users. ASP.NET login controls work with ASP.NET membership. They encapsulate the logic to prompt users for credentials, validate users, recover or replace passwords, and so on. In effect, ASP.NET membership and ASP.NET login controls provide a layer of abstraction over forms authentication. These features replace most or all the work that you would ordinarily have to do to use forms authentication. For more information, see Managing Users by Using Membership and the ASP.NET Login Controls Overview.

Forms Authentication and the Authentication Service

You can also access forms authentication as a Windows Communication Framework (WCF) service by using the ASP.NET authentication service. The authentication service enables you to use forms authentication from any application that can send and consume messages in SOAP format. The authentication service accepts user credentials and returns a forms authentication cookie.

ASP.NET Authentication

2010-03-03T23:23:00.001-08:00

http://msdn.microsoft.com/en-us/library/eeyk640h.aspx
Authentication is the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Once an identity has been authenticated, the authorization process determines whether that identity has access to a given resource.
ASP.NET implements authentication through authentication providers, the code modules that contain the code necessary to authenticate the requestor's credentials. The topics in this section describe the authentication providers built into ASP.NET.

In This Section

Term	Definition
Windows Authentication Provider	Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications.
Forms Authentication Provider	Provides information on how to create an application-specific login form and perform authentication using your own code. A convenient way to work with forms authentication is to use ASP.NET membership and ASP.NET login controls, which together provide a way to collect user credentials, authenticate them, and manage them, using little or no code. For more information, see Managing Users by Using Membership and ASP.NET Login Controls Overview.

Term

Definition

Windows Authentication Provider

Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications.

Forms Authentication Provider

Provides information on how to create an application-specific login form and perform authentication using your own code. A convenient way to work with forms authentication is to use ASP.NET membership and ASP.NET login controls, which together provide a way to collect user credentials, authenticate them, and manage them, using little or no code. For more information, see Managing Users by Using Membership and ASP.NET Login Controls Overview.

You might also consider using Windows Live ID for user authentication. For information about how to use Windows Live ID to authenticate users for you website

Exception Handling Application Block

2010-03-03T22:57:00.000-08:00

This topic includes a series of brief sections that provide information to help you decide whether the Exception Handling Application Block is suitable for your requirements. This topic includes the following sections:

In addition to this introductory material, the documentation contains the following topics:

Developing Applications Using the Exception Handling Application Block. This topic explains how to configure the Exception Handling Application Block, how to add the block to your applications, how to determine appropriate exception handling policies, how to specify different handling actions, and how to send an exception to the Exception Handling Block.
Key Scenarios. This topic shows different ways to use the Exception Handling Application Block in your own applications.
Design of the Exception Handling Application Block. This topic explains the decisions that went into designing the application block and the rationale behind those decisions.
Extending and Modifying the Exception Handling Application Block. This topic explains how to extend the application block by adding custom handlers and formatters. It also gives some advice about how to modify the source code.
Deployment and Operations. This topic explains how to deploy and update the application block assemblies.
Exception Handling QuickStarts. This topic explains how to install and configure the QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common exception handling operations in an application.

For details of the system requirements for the Exception Handling Application Block, see System Requirements. For details of the dependencies for the Exception Handling Application Block, see Application Block Dependencies.

Common Scenarios

The Exception Handling Application Block is designed to address the most common tasks developers face when they write applications that use exception handling. These tasks are arranged according to scenarios. Each scenario gives an example of a real-world situation, discusses the exception handling functions the situation requires, and shows the code that accomplishes the task.
The goal of arranging these tasks according to scenarios is to give the code some context. Instead of displaying an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code and describe situations that are familiar to many developers whose applications must handle exceptions.
The scenarios are the following:

Using Exception Handlers

The Exception Handling Application Block is designed to support the typical code contained in catch statements in application components. Instead of repeating this code (such as logging exception information) throughout identical catch blocks in an application component, the application block allows developers to encapsulate this logic as reusable exception handlers. Exception handlers are .NET classes that encapsulate exception handling logic and implement the Exception Handling Application Block interface named IExceptionHandler. The Exception Handling Application Block includes four exception handlers:

Wrap handler. This exception handler wraps one exception around another.
Replace handler. This exception handler replaces one exception with another.
Logging handler. This exception handler formats exception information, such as the message and the stack trace. Then the logging handler passes this information to the Enterprise Library Logging Application Block so that it can be published.
Fault Contract Exception Handler. This exception handler is designed for use at Windows Communication Foundation (WCF) service boundaries, and generates a new Fault Contract from the exception.

Users can extend the Exception Handling Application Block by implementing their own handlers. The Enterprise Library configuration tools provide the ability to configure the Exception Handling Application Block to use custom handlers. Developers do not have to modify the application block source code or rebuild the application block.

Using Exception Policies

The Exception Handling Application Block lets you associate exception types with named policies. You do this by using the configuration tools. Policies specify the exception handlers that execute when the application block processes a particular exception type. You can chain these handlers together so that a series of them execute when the associated exception type is handled. The following are some examples of named policies and descriptions of what they might provide:

Base policy. This policy logs the exception and rethrows the original exception.
Secure policy. This policy logs the exception, replaces the original exception with a custom exception, and throws the new exception.
Expressive policy. This policy wraps the original exception inside another exception and throws the new exception.

Example Application Code

The following code shows how to execute the policy named "Data Access Policy" when an exception occurs.

try
{
  // Run code.
}
catch(Exception ex)
{
  bool rethrow = ExceptionPolicy.HandleException(ex, " Data Access Policy");
  if (rethrow)
    throw;
}

Visual Basic

Try
  ' Run code.
Catch ex As Exception
  Dim rethrow As Boolean = ExceptionPolicy.HandleException(ex, " Data Access Policy")
  If (rethrow) Then
    Throw
  End If
End Try

Note:
If you use the Unity Integration approach to create instances of objects from the Exception Handling Application Block, you must use the non-static faÃ§ade named ExceptionManager. This class exposes the same API as the ExceptionPolicy class static faÃ§ade. For more information about using the Unity Application Block to create and inject instances of Enterprise Library objects, see Creating Objects Using the Unity Application Block.

Note:

If you use the Unity Integration approach to create instances of objects from the Exception Handling Application Block, you must use the non-static faÃ§ade named ExceptionManager. This class exposes the same API as the ExceptionPolicy class static faÃ§ade. For more information about using the Unity Application Block to create and inject instances of Enterprise Library objects, see Creating Objects Using the Unity Application Block.

When to Use the Exception Handling Application Block

For information about how to develop exception management strategies, see the Design Guidelines for Exceptions. Although it does not specifically discuss the Exception Handling Application Block, it can help you to define a clear, consistent approach to handling exceptions. Use the Exception Management Application Block to help implement your strategy.
The Exception Handling Application Block is best used in situations that require uniform and flexible procedures for handling exceptions. For example, you might want consistent exception handling procedures for all components in a particular tier of an application's architecture. In addition, because of changing security or other operational issues, you might want the ability to change policies as needed, without requiring changes to the application source code. The Exception Handling Application Block, in conjunction with the Enterprise Library configuration tools, lets you accomplish both tasks.
For example, you could use the configuration tools to define a policy that uses handlers to replace exceptions that contain sensitive information with versions that do not include that information. The application block then implements this policy across the components that contain code that specifies this policy should be used.
The Exception Handling Application Block is not limited to cross-tier applications. It can also be used within a particular application. For example, you can define policies that log exception information or display exception information to the user.
In either case, policies are configured without changing the application's code. This makes them easy to maintain or change when new situations occur. Note that, in all cases, you should use the application block to perform only those tasks that are specific to exception handling and that do not intersect with the application's business logic. For example, you can remove the handlers that log an exception or wrap one exception in another without affecting such basic capabilities as updating a customer database.
Figure 1 illustrates examples of cross-layer and single-application component exception handling.

Figure 1
Examples of exception handling policies
In this example, exceptions that occur in the data access layer are logged and then wrapped inside another exception that provides more meaningful information to the calling layer. Within the business component layer, the exceptions are logged before they are propagated. Any exceptions that occur in the business component layer and that contain sensitive information are replaced with exceptions that no longer contain this information. These are sent to the user interface (UI) layer and displayed to the user.
Without the Exception Handling Application Block, typical exception handling code for a data access component might look like the following example.

Note:
The code does not include implementations of the custom DataAccessException exception type, or the RunQuery, FormatException, and the Logging.Log methods. These methods represent typical ways to retrieve a DataSet and to log information.

DataSet customersDataSet;
try
{
  customersDataSet = RunQuery("GetAllCustomers");
}
catch(Exception ex)
{
  string formattedInfo = FormatException(ex);
  Logging.Log(formattedInfo);
  throw new DataAccessException("Database access failure for query GetAllCustomers", e);
}

Visual Basic

Dim customersDataSet As DataSet
 
Try
  customerDataSet = RunQuery("GetAllCustomers")
Catch ex As Exception
  Dim formattedInfo As String = FormatException(ex)
  Logger.Log(formattedInfo)
  Throw New DataAccessException("Database access failure for query GetAllCustomers", e)
End Try

Code similar to this would be repeated in all the routines that perform different data access queries. To change the behavior of the exception handling code, you must update each routine that contained this code.
On the other hand, with the Exception Handling Application Block, the same application would have the following code.

Note:
The code does not include an implementation of the RunQuery method. This method represents a typical way to retrieve a DataSet.

Copy Code

DataSet customersDataSet;
 
try
{
  customersDataSet = RunQuery("GetAllCustomers");
}
catch(Exception ex)
{
  bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
  if (rethrow)
    throw;
}

Visual Basic

Copy Code

Dim customersDataSet As DataSet
 
Try
  customerDataSet = RunQuery("GetAllCustomers")
Catch ex As Exception
  Dim rethrow As Boolean = ExceptionPolicy.HandleException(ex, "Data Access  Policy")
  If (rethrow) Then
    Throw
  End If
End Try

The behavior of the exception handling code is determined by an exception handling policy named Data Access Policy. The application would have configuration settings for the Data Access Policy to indicate that exceptions of type System.Exception are passed to the Logging Exception Handler for the Exception Handling Application Block. To change the behavior of the exception handling code, you change configuration information only; you do not have to update application source code.
The Exception Handling Application Block is a complement to exception handling recovery code; it is not a replacement for it. If exceptions occur because of truly unusual circumstances, it can be impossible for an application to recover gracefully and finish the unit of work it has started. However, it is sometimes possible to recover. An example is an exception that occurs because a file is locked. The recovery code might direct the application to retry the file after waiting for some period of time. In such cases, exception handling recovery code should be implemented within the application code; it should not be implemented as a handler used by the Exception Handling Application Block. This is because it requires access to local variables, parameters, and other contextual data. This data is out of scope and inaccessible to handlers run by the Exception Handling Application Block.

The Difference Between the HAVING and WHERE Clauses in a SQL Query

2010-03-03T22:45:00.001-08:00

Though the HAVING clause specifies a condition that is similar to the purpose of a WHERE clause, the two clauses are not interchangeable. Listed below are some differences to help distinguish between the two:

1.The WHERE clause specifies the criteria which individual records must meet to be selcted by a query. It can be used without the GROUP BY clause. The HAVING clause cannot be used without the GROUP BY clause.

2.The WHERE clause selects rows before grouping. The HAVING clause selects rows after grouping.

3.The WHERE clause cannot contain aggregate functions. The HAVING clause can contain aggregate functions.

ASP.NET Page Life Cycle Overview

2010-02-25T03:02:00.000-08:00

In general terms, the page goes through the stages outlined in the following table. In addition to the page life-cycle stages, there are application stages that occur before and after a request but are not specific to a page. For more information, see ASP.NET Application Life Cycle Overview for IIS 7.0.

Stage
Description

Page request
The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled (therefore beginning the life of a page), or whether a cached version of the page can be sent in response without running the page.

Start
In the start step, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. Additionally, during the start step, the page's UICulture property is set.

Page initialization
During page initialization, controls on the page are available and each control's UniqueID property is set. Any themes are also applied to the page. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.

Load
During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.

Validation
During validation, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.

Postback event handling
If the request is a postback, any event handlers are called.

Rendering
Before rendering, view state is saved for the page and all controls. During the rendering phase, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream of the page's Response property.

Unload
Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.

ASP.NET Application Life Cycle Overview

2010-02-25T03:00:00.001-08:00

http://msdn.microsoft.com/en-us/library/ms178473(VS.80).aspx

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

2010-02-25T02:26:00.000-08:00

How Does It Work?
http://msdn.microsoft.com/en-us/library/aa302376.aspx#secnetap04_topic2

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation
Published: November 2002
Last Revised: January 2006

Applies to:
Microsoft® ASP.NET
Microsoft® Windows® 2000
See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.

Summary: This appendix provides additional material to explain in more detail how certain key concepts and processes discussed within the main body of the guide actually work. (9 printed pages)

Contents
IIS and ASP.NET Processing
ASP.NET Pipeline Processing
IIS and ASP.NET Processing
Note The information in this section applies to Internet Information Services (IIS) 5, running on Windows® 2000.

ASP.NET Web applications and Web services are processed by code that executes in a single instance of the ASP.NET worker process (aspnet_wp.exe), although on multi-processor computers, you can configure multiple instances, one per processor.

IIS authenticates callers and creates a Windows access token for the caller. If anonymous access is enabled within IIS, then a Windows access token for the anonymous Internet user account (typically, IUSR_MACHINE) is created by IIS.

Requests for ASP.NET file types are handled by an ASP.NET ISAPI extension (aspnet_isapi.dll), which runs in the IIS (inetinfo.exe) process address space. This uses a named pipe to communicate with the ASP.NET worker process as shown in Figure 1. IIS passes the Windows access token that represents the caller to the ASP.NET worker process. The ASP.NET Windows authentication module uses this to construct a WindowsPrincipal object and the ASP.NET File authorization module uses it to perform Windows access checks to ensure the caller is authorized to access the requested file.

Figure 1. IIS and ASP.NET communication
Note Access tokens are process relative. As a result, the ASP.NET ISAPI DLL running in inetinfo.exe calls DuplicateHandle to duplicate the token handle into the aspnet_wp.exe process address space and then passes the handle value through the named pipe.

Application Isolation

Separate application domains within the worker process (one per IIS virtual directory, or in other words, one per ASP.NET Web application or Web service) are used to provide isolation.

This is in contrast to classic ASP, where the application protection level, configured within the IIS metabase determined whether the ASP application should execute in process with IIS (inetinfo.exe), out of process in a dedicated instance of Dllhost.exe, or in a shared (pooled) instance of Dllhost.exe.

Important The process isolation level setting within IIS has no affect on the way ASP.NET Web applications are processed.

The ASP.NET ISAPI Extension

The ASP.NET ISAPI extension (aspnet_isapi.dll) runs in the IIS process address space (inetinfo.exe) and forwards requests for ASP.NET file types to the ASP.NET worker process through a named pipe.

Specific ASP.NET file types are mapped to the ASP.NET ISAPI extension by mappings defined within the IIS metabase. Mappings for standard ASP.NET file types (including .aspx, .asmx, .rem, .soap) are established when the .NET Framework is installed.

To view application mappings

1.From the Administrative Tools programs group, start Internet Information Services.

2.Right-click the default Web site on your Web server computer, and then click Properties.

3.Click the Home Directory tab, and then click Configuration.

A list of mappings is displayed. You can see which file types are mapped to Aspnet_isapi.dll.

IIS 6.0 and Windows Server

IIS 6.0 on Windows Server will introduce some significant changes to the current process arrangement.

You will be able to configure multiple application pools, each served by one or more process instances (w3wp.exe). This will provide additional fault tolerance and manageability benefits and will allow you to isolate separate applications in separate processes.

ASP.NET is integrated with the IIS 6.0 Kernel mode HTTP listener, which will allow requests to be passed directly from the operating system to the ASP.NET worker process.

ASP.NET Pipeline Processing

ASP.NET authentication and authorization mechanisms are implemented using HTTP module objects, which are invoked as part of the standard ASP.NET pipeline processing. Individual Web requests and responses pass through a pipeline of objects as shown in Figure 2.

Figure 2. ASP.NET pipeline processing

The ASP.NET pipeline model consists of an HttpApplication object, various HTTP module objects, and an HTTP handler object, together with their associated factory objects, which have been omitted from Figure 2 for clarity. An HttpRuntime object is used at the start of the processing sequence and an HttpContext object is used throughout the lifecycle of a request to convey details about the request and response.

The following list explains the responsibilities and operations performed by the objects associated with the HTTP processing pipeline:

The HttpRuntime object examines the request received from IIS and dispatches it to an appropriate instance of the HttpApplication object to process the request. There is a pool of HttpApplication objects in each application domain in Aspnet_wp.exe. There is a one-to-one mapping between application domains, HttpApplication objects and IIS virtual directories. In other words, ASP.NET treats separate IIS virtual directories as separate applications.

Note There is one instance of HttpRuntime in every Web application domain.

The HttpApplication objects control the pipeline processing. An individual HttpApplication object is created to handle each simultaneous HTTP request. HttpApplication objects are pooled for performance reasons.

HTTP module objects are filters that process HTTP request and response messages as they flow through the pipeline. They can view or alter the content of the request and response messages. HTTP modules are classes that implement IHttpModule.

HTTP handler objects are the endpoints for HTTP requests and provide the request processing for specific file types. For example, one handler processes requests for *.aspx files while another processes requests for *.asmx files. The HTTP response message is generated and returned from the HTTP handler. HTTP handlers are classes that implement IHttpHandler.

An HttpContext object is used throughout the pipeline to represent the current Web request and response. It is available to all modules in the pipeline and the handler object at the end of the pipeline. The HttpContext object exposes various properties including the User property which contains an IPrincipal object that represents the caller.

The Anatomy of a Web Request

The ASP.NET ISAPI library (Aspnet_isapi.dll) runs inside the IIS process address space (Inetinfo.exe). It dispatches requests to the HttpRuntime object within the ASP.NET worker process (Aspnet_wp.exe). The following set of actions occurs in response to each Web request received by ASP.NET:

The HttpRuntime object examines the request and forwards it to an instance of an HttpApplication object.

There is at least one HttpApplication object instance per application domain (the objects are pooled) and one application domain per IIS virtual directory. The initial request for a file in a particular virtual directory results in a new application domain and a new HttpApplication object being created.

A list of HTTP modules is read from Machine.config (they are contained within the <httpModules> element). Additional custom HTTP modules can be added to Web.config for a specific application. The default <httpModules> element within Machine.config is shown in the following code snippet. Copy Code <httpModules>

<add name="OutputCache"

type="System.Web.Caching.OutputCacheModule"/>

<add name="Session"

type="System.Web.SessionState.SessionStateModule"/>

<add name="WindowsAuthentication"

type="System.Web.Security.WindowsAuthenticationModule"/>

<add name="FormsAuthentication"

type="System.Web.Security.FormsAuthenticationModule"/>

<add name="PassportAuthentication"

type="System.Web.Security.PassportAuthenticationModule"/>

<add name="UrlAuthorization"

type="System.Web.Security.UrlAuthorizationModule"/>

<add name="FileAuthorization"

type="System.Web.Security.FileAuthorizationModule"/>

</httpModules>

The authentication modules hook the AuthenticateRequest event, while the authorization modules hook the AuthorizeRequest event.

The request passes through every module in the pipeline, although only a single authentication module is loaded. This depends on the configuration of the <authentication> element in Web.config. For example, the <authentication> element that follows results in the WindowsAuthenticationModule being loaded.

Copy Code <authentication mode="Windows" />

The activated authentication module is responsible for creating an IPrincipal object and storing it in the HttpContext.User property. This is vital, because the downstream authorization modules use this IPrincipal object in order to make authorization decisions.

In the absence of authentication (for example, where anonymous access is enabled within IIS and ASP.NET is configured with <authentication mode="None" />), there's a special non configured module that puts a default anonymous principal into the HttpContext. User property. As a result, HttpContext.User is always non-null after authentication.

If you implement a custom authentication module, code within the custom module must create an IPrincipal object and store it in HttpContext.User,

Note ASP.NET also wires up Thread.CurrentPrincipal based on HttpContext.User after the AuthenticateRequest event.

The HttpApplication fires the AuthenticateRequest event, which can be hooked in global.asax. This allows you to inject custom processing code; for example, to load the set of roles associated with the current user. However, note that the WindowsAuthenticationModule does this automatically. The role list is obtained from the set of Windows groups in which the authenticated Windows user is a member.

After the appropriate authentication module has finished its processing, the authorization modules are called if the request hasn't been aborted.

When the UrlAuthorizationModule is called, it checks for an <authorization> tag in Machine.config and Web.config. If present, it retrieves the IPrincipal object from HttpContext.User and checks to see whether the user is authorized to access the requested resource using the specified verb (GET, POST, and so on).

If the user is not authorized, the UrlAuthorizationModule calls HttpApplication.CompleteRequest, which aborts normal message processing. The UrlAuthorizationModule returns an HTTP 401 status code.

Next, the FileAuthorizationModule is called. It checks whether the IIdentity object in HttpContext.User.Identity is an instance of the WindowsIdentity class.

If the IIdentity object is not a WindowsIdentity, the FileAuthorizationModule performs no further processing.

If a WindowsIdentity is present, the FileAuthorizationModule calls the AccessCheck API (through P/Invoke) to see if the authenticated caller (whose access token has been passed to ASP.NET by IIS and is exposed by the WindowsIdentity object) is authorized to access the requested file. If the file's security descriptor contains at least a Read ACE in its DACL, the request is allowed to proceed. Otherwise the FileAuthorizationModule calls HttpApplication.CompleteRequest and returns a 401 status code.

Forms authentication processing

The FormsAuthenticationModule is activated when the following element is in Web.config.

Copy Code <authentication mode="Forms" />

Remember that for Forms authentication, you implement the Application_Authenticate event in Global.asax. For Forms authentication, the following sequence occurs:

Within this code, you can construct an IPrincipal object and store it in HttpContext.User. This typically contains the role list retrieved from a custom data store (normally a SQL Server database or Active Directory). The IPrincipal object is typically an instance of the GenericPrincipal class but could also be a custom IPrincipal class.

The FormsAuthenticationModule checks to see if you have created an IPrincipal object. If you have, it is used by the downstream authorization modules. If you haven't, the FormsAuthenticationModule constructs a GenericPrincipal (with no roles) and stores it in the context.

If there is no role information, any authorization checks (such as PrincipalPermssion demands) that demand role membership, will fail.

The UrlAuthorizationModule handles the AuthorizeRequest event. Its authorization decisions are based on the IPrincipal object contained within HttpContext.User.

Windows authentication processing

The WindowsAuthenticationModule is activated when the following element is in Web.config.

Copy Code <authentication mode="Windows" />

For Windows authentication, the following sequence occurs:

1.The WindowsAuthenticationModule creates a WindowsPrincipal object using the Windows access token passed to ASP.NET by IIS.

2.It uses P/Invoke to call Win32 functions to obtain the list of Windows group that the user belongs to. These are used to populate the WindowsPrincipal role list.

3.It stores the WindowsPrincipal object in HttpContext.User, ready to be used by the downstream authorization modules.

Event Handling

The HttpApplication object fires the set of events shown in Table 1. Individual HTTP modules can hook these events (by providing their own event handlers).

Table 1. Events fired by HttpApplication objects

Event Notes

BeginRequest Fired before request processing starts

AuthenticateRequest To authenticate the caller

AuthorizeRequest To perform access checks

ResolveRequestCache To get a response from the cache

AcquireRequestState To load session state

PreRequestHandlerExecute Fired immediately before the request is sent to the handler object

PostRequestHandlerExecute Fired immediately after the request is sent to the handler object

ReleaseRequestState To store session state

UpdateRequestCache To update the response cache

EndRequest Fired after processing ends

PreSendRequestHeaders Fired before buffered response headers are sent

PreSendRequestContent Fired before buffered response body sent

Note The HTTP handler executes in between the PreRequestHandlerExecute and PostRequestHandlerExecute events.

The last two events are non-deterministic and could occur at any time (for example, as a result of a Response.Flush). All other events are sequential.

You do not need to implement an HTTP module simply in order to hook one of these events. You can also add event handlers to Global.asax. In addition to the events listed in Table 1 (which can all be hooked by individual HTTP module objects), the HttpApplication object fires Application_OnStart and Application_OnEnd handlers, which will be familiar to ASP developers. These can be handled only within Global.asax. Finally, you can also implement custom event handlers within Global.asax for events fired by individual HTTP module objects. For example, the session state module fires Session_OnStart and Session_OnEnd events.

Implementing a Custom HTTP Module

To create your own HTTP module and insert it into the ASP.NET processing pipeline

1.Create a class that implements IHttpModule.

2.Place the assembly that contains the module in your application's \bin subdirectory or you can install it into the Global Assembly Cache.

3.Add an <HttpModules> element to your application's web.config, as shown below. Copy Code <system.web>

<httpModules>

<add name="modulename"

type="namespace. classname, assemblyname" />

</httpModules>

</system.web>

Implementing a Custom HTTP Handler

You may need to implement a custom HTTP handler, for example to handle the processing of files with the .data file extension.

To implement a custom HTTP handler

1.Add a mapping to the IIS metabase to map the .data file extension to the ASP.NET ISAPI extension (Aspnet_isapi.dll).

Right-click your application's virtual directory in the IIS MMC snap-in, click the Configuration button, and then click Add to create a new mapping for .data files to C:\Winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll.

Note If you select the Check that file exists check box when adding the mapping, then the file must be physically present. This is usually what is wanted unless you have virtualized paths that don't map to a physical file. Virtualized paths ending with .rem or .soap are used by .NET Remoting.

2.Create a class that implements IHttpHandler (and optionally IHttpAsyncHandler if you want to handle requests asynchronously).

3.Place the assembly that contains the handler in your application's \bin subdirectory or you can install it into the Global Assembly Cache.

4.Add the handler to the processing pipeline by adding an <httpHandlers> section to your application's Web.config file. Copy Code <system.web>

<httpHandlers>

<add verb="*" path="*.data" type="namespace.classname, assemblyname" />

</httpHandlers>

</system.web>

Understanding IIS Isolation Levels

2010-02-25T01:10:00.001-08:00

Internet Information Server introduced the notion "Isolation Level", which is also present in IIS4 under a different name. IIS5 supports three isolation levels, that you can set from the Home Directory tab of the site's Properties dialog:

•Low (IIS Process): ASP pages run in INetInfo.Exe, the main IIS process, therefore they are executed in-process. This is the fastest setting, and is the default under IIS4. The problem is that if ASP crashes, IIS crashes as well and must be restarted (IIS5 has a reliable restart feature that automatically restarts a server when a fatal error occurs).

•Medium (Pooled): In this case ASP runs in a different process, which makes this setting more reliable: if ASP crashes IIS won't. All the ASP applications at the Medium isolation level share the same process, so you can have a web site running with just two processes (IIS and ASP process). IIS5 is the first Internet Information Server version that supports this setting, which is also the default setting when you create an IIS5 application. Note that an ASP application that runs at this level is run under COM+, so it's hosted in DLLHOST.EXE (and you can see this executable in the Task Manager).

•High (Isolated): Each ASP application runs out-process in its own process space, therefore if an ASP application crashes, neither IIS nor any other ASP application will be affected. The downside is that you consume more memory and resources if the server hosts many ASP applications. Both IIS4 and IIS5 supports this setting: under IIS4 this process runs inside MTS.EXE, while under IIS5 it runs inside DLLHOST.EXE.

When selecting an isolation level for your ASP application, keep in mind that out-process settings - that is, Medium and High - are less efficient then in-process (Low). However, out-process communication has been vastly improved under IIS5, and in fact IIS5's Medium isolation level often deliver better results than IIS4's Low isolation. In practice, you shouldn't set the Low isolation level for an IIS5 application unless you really need to serve hundreds pages per second.

Session State Managemnet

2010-02-25T01:01:00.000-08:00

Session State

ASP.NET provides the cross-request state information (shopping carts, data scrolling, and so on) infrastructure that Web applications require, with built-in session-state functionality that enables you to take the following actions:

Automatically identify and classify requests coming from a single browser client into a logical application session on the server.

Store session-scoped data on the server for use across multiple browser requests.

Raise appropriate session-lifetime management events (Session_OnStart, Session_OnEnd, and so on) that can be handled in application code.

Note The Session_OnEnd event is supported only the in-process session-state mode. This event is not raised if you use State Server or SQL Server modes.

Automatically release session data if the browser does not revisit an application within a specified time-out period.

This topic provides an overview of session state, describes how active ASP.NET sessions are identified and tracked, explains the session-state store and general structure, and concludes with a high-level code example.

Session State Overview

HTTP is a stateless protocol, which means that it does not automatically indicate whether a sequence of requests is all from the same client or even whether a single browser instance is still actively viewing a page or site. As a result, building Web applications that need to maintain some cross-request state information (shopping carts, data scrolling, and so on) can be extremely challenging without additional infrastructure help.

ASP.NET provides the following support for sessions:

A session-state facility that is easy to use, familiar to ASP developers, and consistent with other .NET Framework APIs.

A reliable session-state facility that can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data.

A scalable session-state facility that can be used in both Web farm (multicomputer) and Web garden (multiprocess) scenarios and that enables administrators to allocate more processors to a Web application to improve its scalability.

A session-state facility that works with browsers that do not support HTTP cookies.

A throughput equivalent to that of ASP (or better) for core session-state scenarios (50/50 read/write when putting items into shopping carts, modifying last page visited, validating credit card details, and so on).

Session state, however, does not persist across Web application boundaries. If a Web application switches to another application during execution, the session information is not available to the new application.

Identifying a Session

Each active ASP.NET session is identified and tracked using a 120-bit SessionID string containing only the ASCII characters that are allowed in URLs. SessionID values are generated using an algorithm that guarantees uniqueness so that sessions do not collide, and randomness so that a malicious user cannot use a new SessionID to calculate the SessionID of an existing session.

The SessionID strings are communicated across client-server requests either by means of an HTTP cookie or a modified URL with the SessionID string embedded, depending on how you configure the application settings.

Session-State Store

ASP.NET provides a simple and easy-to-use session-state model that you can use to store arbitrary data and objects across multiple Web requests. It accomplishes this using a dictionary-based, in-memory cache of object references that live within the IIS process. When using the in-process session-state mode consider the following limitations:

When using the in-process session-state mode, session-state data is lost if aspnet_wp.exe or the application domain restarts. These restarts commonly occur in the following circumstances:

Setting an attribute in the element of the application's Web.config file that causes a new process to start when a condition is met, such as memoryLimit.

The Global.asax or Web.config file is modified.

Changes to the \Bin directory of the Web application.

Antivirus software scans and modifies the Global.asax file, the Web.config file, or a file in the \Bin directory of the Web application.

If you enable Web garden mode in the element of the application's Web.config file, do not use in-process session-state mode. Otherwise, random data loss can occur.

Instead of keeping live objects, the .NET State Server simply stores session state in memory when in out-of-proc mode. In this mode the worker process talks directly to the State Server. In SQL mode, session states are stored in a SQL Server database and the worker process talks directly to SQL. The ASP.NET worker processes are then able to take advantage of this simple storage service by serializing and saving (using .NET serialization services) all objects within a client's Session collection at the end of each Web request. When the client revisits the server, the relevant ASP.NET worker process retrieves these objects from the State Server as binary streams, deserializes them into live instances, and places them back into a new Session collection object exposed to the request handler.

In SQL mode, session state can also be configured to work in a failover cluster. A failover cluster is two or more identical, redundant Web servers that store their session data on a separate computer in a SQL Server database. For information on how to set up this configuration, see Configuring SQL Server Mode.

By cleanly separating the storage of session data from the application's use of it, ASP.NET supports several powerful scenarios that were unavailable with earlier versions of ASP:

Recovery from application crashes, because the memory used for session state is not within the ASP.NET worker process.

Because all state is stored separately from an individual worker process, it is not lost if the process crashes due to an access violation or is forcibly restarted by the IIS Admin Service in the event of a deadlock or memory leak.

Partitioning an application across multiple worker processes.

Because all state is stored separately from worker processes, you can cleanly partition an application across multiple processes. Such partitioning can dramatically improve both the availability and the scalability of an application on multiple-process computers. Moreover, because it associates each worker process with a single computer, ASP.NET is able to eliminate cross-processor lock contention, one of the major scalability bottlenecks in earlier versions of ASP.

Partitioning an application across multiple Web farm computers.

Because all state is stored separately from worker processes, you can partition an application across multiple worker processes running on multiple computers. The model for communicating state between a worker process and a state service running on different computers is almost the same as that for processes and servers running on the same computer. In either case there can only be one State Server per Web farm.

Session State Structure

ASP.NET-based applications use an event-based execution organization to enable multiple .NET Framework class modules to participate in the processing of a single Web request.

The SessionState Module

The .NET Framework implements session state through the SessionStateModule class (derived from IHttpModule), which participates in the execution of each request received by a .NET-based application. The SessionStateModule is responsible for either generating or obtaining unique SessionID strings and for storing and retrieving state data from an external state provider.

Session State Collections

The SessionState class exposes two state collections: Contents and StaticObjects. The Contents collection exposes all variable items that have been added to the session-state collection directly through code. For example:

[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.

Session("Message") = "MyMsg"

Session("AppStartTime") = Now

[C#]

// C# code from within a page, a handler, or Global.asax.

Session["Message"] = "MyMsg";

Session["AppStartTime"] = DateTime.Now;For compatibility with earlier versions of ASP, these values also can be accessed through a Contents property on the application object, as in the following example.

[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.

Session.Contents("Message") = "MyMsg"

Session.Contents("AppStartTime") = Now

[C#]

// C# code from within a page, a handler, or Global.asax.

Session.Contents["Message"] = "MyMsg";

Session.Contents["AppStartTime"] = DateTime.Now;The StaticObjects collection exposes all variable items that have been added to the session-state collection through

The ASP.NET Worker Process

2010-02-25T00:47:00.001-08:00

ASP.NET runs within a process known as the ASP.NET worker process. All ASP.NET functionality runs within the scope of this process.

A regular Web server contains only a single ASP.NET worker process. This is different from both Web farms and Web gardens:

A Web farm contains multiple ASP.NET worker processes.
Each server in the group of servers handles a separate ASP.NET worker process.

A Web garden contains multiple ASP.NET worker processes.
Each CPU in the SMP server handles a separate ASP.NET worker process.

Choosing an ASP.NET worker process

When a Web client connects to a Web farm or Web garden, one of the multiple ASP.NET worker processes is selected to run the request.

In a Web farm, Network Load Balancing determines the ASP.NET worker process selected.
In a Web garden, the ASP.NET worker process selected is determined by ASP.NET.
State management with multiple ASP.NET worker processes

When moving from a scenario with a single ASP.NET worker process (a normal Web server) to a scenario with multiple ASP.NET worker processes (a Web farm or Web garden), complications with state management are introduced.

Web pages are stateless, so a Web server must persist state through other means. Typical means to manage state on the Web server include Session State and the ASP.NET Cache.

Note Issues of persistence and state (within a single Web server) are discussed in detail in the section Which Persistence Approach Should I Use with Crystal Reports?.
Both Session and Cache are contained within the memory space of a single ASP.NET worker process. But in a Web farm or Web garden, multiple ASP.NET worker processes work together simultaneously. The Session or Cache within any individual ASP.NET worker process cannot manage state across multiple processes.

Therefore, an additional layer is required for state management: an out-of-process Session State server that stores and retrieves state information for every ASP.NET worker process in the Web farm or Web garden.

Web Farm Architecture

2010-02-25T00:45:00.001-08:00

A Web farm has multiple servers that are exposed to browser clients as a single virtual server, with one virtual Media Access Card and TCP/IP address.

Behind this virtual layer, each server in the Web farm receives every network packet, but only processes a subset of those packets. The ability to equally share the workload is what gives Web farms their superior processing power.

This distribution of packets is managed by Network Load Balancing. Network Load Balancing does the following:

It balances the client requests between servers.
It determines which server will process which request.
It ensures that server resource use and client wait times are optimized.
It provides a superior alternative to client affinity.
Note In a client affinity scenario, connecting clients are restricted to return to the same server each time.
Client affinity is usually turned off, because it can create a bottleneck of requests for a particular server.
Each server on a Web farm has a Network Load Balancing network device driver, which communicates with the other servers, and each server typically has two network cards. The second card allows internal communications for Network Load Balancing to be done over a separate, internal network.

The Network Load Balancing network device driver is provided in the following operating systems:

Windows 2000 Advanced Server.
Windows Advanced Server 2003.
Web garden architecture

A Web garden is like a Web farm, except that rather than use several server machines linked together, it uses single machine with multiple CPUs.

This single SMP (symmetric multiprocessing) server uses ASP.NET to run a separate ASP.NET worker process on each CPU. The server manages multiple client requests against the multiple CPUs on the server.

Can .dll files check-in to TFS Source Control?

2010-02-20T02:59:00.000-08:00

The answer is yes.

When creating a web project in Visual Studio .NET 2005, the bin folder gets exposed to TFS source control.

Normally, the bin folder is how the web project keeps track of the project references. When a project reference is added to the project, the .dll is copied to the bin directory.

In a source controlled environment, this copy is "noticed" by Visual Studio 2005 and exposed to the source control process. This means that you can check in all the .dlls added to the bin folder.

The Bin folder is not visible on the Source Control Window. So, when you checked in the .dll files, the files will be drop on the drop release folder.

I don't see why we need to put bin folder into our source control. It is not a wise idea bro. If you want to put your dll, let say external dll or third party library such as nhibernate.dll or P&P EntLib dlls, put it in another folder other than bin, obj, debug..etc..if you 're developing multitier apps or seperate your module into several projects, it is much easier because you can just Add Reference to you projects instead of refer to dll.
In our development team here, we organise all our tools, and libraries properly, put it into the right folder.Example: put all the externall dlls into a folder named 'Library'. When new developer join our team. they can just get latest the root folder, then he can compile the solution without any problem.

Should I use an abstract class or an interface?

2010-02-11T06:01:00.000-08:00

The functionality available through the use of abstract classes and of interfaces is quite similar. However, each has its pros and cons.

Contents [hide]
1 Inheritance
1.1 Single inheritance
1.2 Value type polymorphism
2 Separation of contract and implementation
3 Versioning
4 Design flexibility
5 Visual C# Best Practices
5.1 Use an abstract class
5.2 Use an interface
6 Summary
7 See also

Inheritance
A C# class may only subclass—inherit from—one other class. Therefore, by inheriting from (subclassing) an abstract class, the derived class has used up its ability to participate in a meaningful type hierarchy.

On the other hand, a class can implement—inherit from—any number of interfaces. And, it can still inherit from (subclass) a base class which makes sense.

Single inheritance
C# supports single inheritance: C# does not support multiple inheritance from multiple classes like C++ does. But, by using abstract classes and interfaces, C# programs can achieve most of the same functionality without the confusion and maintenance problems associated with multiple inheritance.

Value type polymorphism
.NET value types are objects descending from Object; but, they cannot inherit from other types. They can implement interfaces. Thus, primitives—such as Int32— can implement the IComparable interface, for example, making them comparable.

Separation of contract and implementation
Interfaces separate the syntax rather than the semantic contract from the implementation. Classes can be designed to decouple the semantic contract from the implementation. For example, abstract classes can be separated in a different assembly than their concrete implementations.

Versioning
An abstract class can contain an interface plus implementations. This simplifies versioning. An abstract class can be extended by adding new nonabstract methods with default implementations. Also, a convenience method is easily added to an abstract class.

An interface cannot be modified without breaking its contract with the classes which implement it. Once an interface has been shipped, its member set is permanently fixed. An API based on interfaces can only be extended by adding new interfaces.

Design flexibility
Interfaces offer more design flexibility; precisely because, they can be implemented by any class regardless of its type hierarchy.

Visual C# Best Practices
Use abstract classes and interfaces in combination to optimize your design trade-offs.
Use an abstract class
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)
Use an abstract class to define a common base class for a family of types.
Use an abstract class to provide default behavior.
Subclass only a base class in a hierarchy to which the class logically belongs.
Use an interface
When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.
Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.
Use an interface to design a polymorphic hierarchy for value types.
Use an interface when an immutable contract is really intended.
A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.
Summary
The following table compares the features of abstract classes and interfaces.

Abstract class Interface
Derived classes exhaust their single base class inheritance option. Classes can implement multiple interfaces without using up their base class option. But, there are no default implementations.
Cannot be instantiated except as part of subclasses. Only derived classes can call an abstract class constructor. Cannot be instantiated.
Defines abstract member signatures which derived classes must implement. Otherwise, the derived class itself will be abstract. Defines abstract member signatures—all of which—implementing classes must implement. Otherwise, a compiler error results.
New non-abstract members may be added that derived classes will inherit without breaking version compatibility. Extending an interface with new members breaks version compatibility.
Optionally, provide default (virtual) member implementation. All members are virtual and cannot provide implementations.
Can include data fields. Cannot include data fields. However, abstract properties may be declared.

Security in C#

2008-12-21T10:01:00.000-08:00

Security is an indispensable aspect of every C# applications, and must be considered at every phase of development: not merely when design and implementation are complete.

C# Specific Security Recommendations

This list is in not an exhaustive list of potential security problems. It highlights some common issues of which C# developers need to be aware.

Use the checked keyword to control the overflow-checking context for integral-type arithmetic operations and conversions.
Always use the most restrictive data type for parameters. For example, when passing a value into a method that describes the size of a data structure, use unsigned integer rather than integer.
Do not make decisions based on filenames. Filenames can be expressed in many different ways, and your test for a particular file may be bypassed.
Never, ever hardcode passwords or other sensitive information into your application.
Always validate input that is used to generate SQL queries.
Validate all inputs into your methods. The regular expression methods in System.Text.RegularExpressions namespace are useful for confirming input is of the correct form, such as an email address.
Don't display exception information: it provides any would-be attacker with valuable clues.
Ensure your application works while running with the least possible privileges. Few applications require a user to be logged in as an administrator.
Don't use your own encryption algorithms, use the System.Security.Cryptography classes.
Give your Assemblies strong names.
Don't store sensitive information in XML or other configuration files.
Check managed code that wraps native code carefully. Confirm the native code is secure, especially with regard to buffer overruns.
Use caution when using delegates passed from outside your application.
Run FxCop on your assemblies to ensure compliance with Microsoft .NET Framework Design Guidelines. FxCop can also find and warn against over 200 code defects.

Reflection in C#

2008-12-21T10:00:00.000-08:00

Reflection provides objects (of type Type) that encapsulate assemblies, modules and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object and invoke its methods or access its fields and properties. If you are using attributes in your code, Reflection enables you to access them. For more information, see Attributes.

Here's a simple example of Reflection using the static method GetType - inherited by all types from the Object base class - to obtain the type of a variable:

// Using GetType to obtain type information:
int i = 42;
System.Type type = i.GetType();
System.Console.WriteLine(type);

The output is:

System.Int32

In this example, Reflection is used to obtain the full name of a loaded assembly:

// Using Reflection to get information from an Assembly:
System.Reflection.Assembly o = System.Reflection.Assembly.Load("mscorlib.dll");
System.Console.WriteLine(o.GetName());

The output is:

mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Reflection Overview

Reflection is useful in the following situations:

When you need to access attributes in your program's metadata. See the topic Accessing Attributes With Reflection.
For examining and instantiating types in an assembly.
For building new types at runtime. Use classes in System.Reflection.Emit.
For performing late binding, accessing methods on types created at run time. See the topic Dynamically Loading and Using Types.

Performance in C#

2008-12-21T09:59:00.000-08:00

This section covers two issues that can adversely effect performance, and links to resources on performance issues.

Boxing and Unboxing

Boxing and unboxing are computationally expensive processes. When a value type is boxed, an entirely new object must be created. This can take up to 20 times longer than an assignment. When unboxing, the casting process can take four times as long as an assignment. For more information, see Boxing and Unboxing.

Destructors

Empty destructors should not be used. When a class contains a destructor, an entry is created in the Finalize queue. When the destructor is called, the garbage collector is invoked to process the queue. If the destructor is empty, this simply results in a loss of performance. For more information, see Destructors.

Threading In C#

2008-12-21T09:58:00.000-08:00

Threading enables your C# program to perform concurrent processing so you can do more than one operation at a time. For example, you can use threading to monitor input from the user, perform background tasks, and handle simultaneous streams of input. The System.Threading namespace provides classes and interfaces that support multithreaded programming and enable you to easily perform tasks such as creating and starting new threads, synchronizing multiple threads, suspending threads, and aborting threads.

To incorporate threading in your C# code, simply create a function to be executed outside the main thread and point a new Thread object at it. The following code example creates a new thread in a C# application

System.Threading.Thread newThread;
newThread = new System.Threading.Thread(anObject.AMethod);

The following code example starts a new thread in a C# application:

Copy Code

newThread.Start();

Multithreading solves problems with responsiveness and multi-tasking, but can also introduce resource sharing and synchronization issues because threads are interrupted and resumed without warning according to a central thread scheduling mechanism. For more information, see Thread Synchronization. See Using Threads and Threading for overview information.

Overview

Threads have the following properties:

Threads enable your C# program to perform concurrent processing.
The .NET Framework's System.Threading namespace makes using threads easier.
Threads share the application's resources. For more information, see Using Threads and Threading.

Interoperability in C#

2008-12-21T09:57:00.000-08:00

Interoperability enables you to preserve and leverage existing investments in unmanaged code. Code running under the control of the common language runtime (CLR) is called "managed code", and code running outside the CLR is "unmanaged code". COM, COM+, C++ components, ActiveX components, and Win32 API are examples of unmanaged code.

The .NET Framework enables interoperability with unmanaged code through platform invoke services, the System.Runtime.InteropServices namespace, and the CLR and through COM Interoperability (COM interop).

There are two ways to use unmanaged APIs from managed code: through platform invoke and through It Just Works (IJW) in C++. Platform invoke enables managed code to call functions exported from an unmanaged dynamic link library (DLL), such as Win32 API and custom DLLs. The CLR handles DLL loading and parameter marshaling. For performance, check if there is an equivalent function available in the .NET Framework rather than using platform invoke. For more information, see A Closer Look at Platform Invoke.
COM interop, which enables managed code to interact with COM objects through COM interfaces and COM clients. There are two ways to use COM components from managed code:
- For calling OLE Automation compatible COM components, use COM interop or tlbimp.exe. The CLR handles COM component activation and parameter marshaling.
- For IDL based COM components, use IJW and C++. Every public managed class that implements IUnknown, IDispatch, and other standard COM interfaces can be called from unmanaged code through COM interop. For more information, see Microsoft .NET/COM Migration and Interoperability.

For more information, see Interoperating with Unmanaged Code and Improving Interop Performance.

Both PInvoke and COM interop use marshaling to translate arguments such as integers, strings, arrays, structures, and pointers between managed and unmanaged code. For more information, see Interop Marshaling Overview.

Exceptions and Exception Handling in C#

2008-12-21T09:56:00.000-08:00

The C# language's exception handling features provide a way to deal with any unexpected or exceptional situations that arise while a program is running. Exception handling uses the try, catch, and finally keywords to attempt actions that may not succeed, to handle failures, and to clean up resources afterwards. Exceptions can be generated by the common language runtime (CLR), by third-party libraries, or by the application code using the throw keyword.

In this example, a method tests for a division by zero, and catches the error. Without the exception handling, this program would terminate with a DivideByZeroException was unhandled error.

int SafeDivision(int x, int y)
{
   try
   {
       return (x / y);
   }
   catch (System.DivideByZeroException dbz)
   {
       System.Console.WriteLine("Division by zero attempted!");
       return 0;
   }
}

Exceptions Overview

Exceptions have the following properties:

When your application encounters an exceptional circumstance, such as a division by zero or low memory warning, an exception is generated.
Use a try block around the statements that might throw exceptions.
Once an exception occurs within the try block, the flow of control immediately jumps to an associated exception handler, if one is present.
If no exception handler for a given exception is present, the program stops executing with an error message.
If a catch block defines an exception variable, you can use it to get more information on the type of exception that occurred.
Actions that may result in an exception are executed with the try keyword.
An exception handler is a block of code that is executed when an exception occurs. In C#, the catch keyword is used to define an exception handler.
Exceptions can be explicitly generated by a program using the throw keyword.
Exception objects contain detailed information about the error, including the state of the call stack and a text description of the error.
Code in a finally block is executed even if an exception is thrown, thus allowing a program to release resources.

Collection Classes in C#

2008-12-21T09:55:00.002-08:00

The .NET Framework provides specialized classes for data storage and retrieval. These classes provide support for stacks, queues, lists, and hash tables. Most collection classes implement the same interfaces, and these interfaces may be inherited to create new collection classes that fit more specialized data storage needs.

Note
Applications that target version 2.0 and later of the .NET Framework should use the generic collection classes in the System.Collections.Generic namespace, which provide greater type-safety and efficiency than their non-generic counterparts.

ArrayList list = new ArrayList();
list.Add(10);
list.Add(20);

Collection Classes Overview

Collection Classes have the following properties

Collection classes are defined as part of the System.Collections or System.Collections.Generic namespace.
Most collection classes derive from the interfaces ICollection, IComparer, IEnumerable, IList, IDictionary, and IDictionaryEnumerator and their generic equivalents.
Using generic collection classes provides increased type-safety and in some cases can provide better performance, especially when storing value types. For more information, see Benefits of Generics.

Attributes in C#

2008-12-21T09:55:00.001-08:00

Attributes provide a powerful method of associating declarative information with C# code (types, methods, properties, and so forth). Once associated with a program entity, the attribute can be queried at run time using a technique called Reflection.

Attributes exist in two forms: attributes that are defined in the Common Language Runtime's base class library and custom attributes that you can create, to add extra information to your code. This information can later be retrieved programmatically.

In this example, the attribute System.Reflection.TypeAttributes.Serializable is used to apply a specific characteristic to a class:

[System.Serializable]
public class SampleClass
{
   // Objects of this type can be serialized.
}

Attribute Overview

Attributes have the following properties:

Attributes add metadata to your program. Metadata is information embedded in your program such as compiler instructions or descriptions of data.
Your program can examine its own metadata using Reflection. See Accessing Attributes With Reflection.
Attributes are commonly used when interacting with COM.

Assemblies and the Global Assembly Cache in C#

2008-12-21T09:53:00.002-08:00

An assembly is a fundamental building block of any .NET Framework application. For example, when you build a simple C# application, Visual Studio creates an assembly in the form of a single portable executable (PE) file, specifically an EXE or DLL.

Assemblies contain metadata that describe their own internal version number and details of all the data and object types they contain. For more information see Assembly Manifest.

Assemblies are only loaded as they are required. If they are not used, they are not loaded. This means that assemblies can be an efficient way to manage resources in larger projects.

Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly. For more information on modules, see the topic How to: Build a Multifile Assembly.

Assemblies Overview

Assemblies have the following properties:

Assemblies are implemented as .exe or .dll files.
You can share an assembly between applications by placing it in the Global Assembly Cache.
Assemblies must be strong-named before they can be placed in the Global Assembly Cache. For more information, see Strong-Named Assemblies.
Assemblies are only loaded into memory if they are required.
You can programmatically obtain information about an assembly using reflection. For more information, see the topic Reflection.
If you want to load an assembly only to inspect it, use a method such as ReflectionOnlyLoadFrom.
You can use two versions of the same assembly in a single application. For more information, see extern alias.

Application Domains in C#

2008-12-21T09:53:00.001-08:00

Application domains provide a flexible and secure method of isolating running applications.

Application domains are usually created and manipulated by run-time hosts. Occasionally, you may want your application to programmatically interact with your application domains, for example, to unload a component without having to stop your application from running.

Application domains aid security, separating applications from each other and each other's data. A single process can run several application domains, with the same level of isolation that would exist in separate processes. Running multiple applications within a single process increases server scalability.

In the following code example, you create a new application domain and then load and execute a previously built assembly, HelloWorld.exe, that is stored on drive C.

static void Main()
{
   // Create an Application Domain:
   System.AppDomain newDomain = System.AppDomain.CreateDomain("NewApplicationDomain");

   // Load and execute an assembly:
   newDomain.ExecuteAssembly(@"c:\HelloWorld.exe");

   // Unload the application domain:
   System.AppDomain.Unload(newDomain);
}

Application Domains Overview

Application domains have the following properties:

An assembly must be loaded into an application domain before it can be executed. For more information, see Assemblies and the Global Assembly Cache (C# Programming Guide).
Faults in one application domain cannot affect other code running in another application domain.
Individual applications can be stopped and code unloaded without stopping the entire process. You cannot unload individual assemblies or types, only entire application domains.

XML Documentation Comments in C#

2008-12-21T09:51:00.000-08:00

In Visual C# you can create documentation for your code by including XML tags in special comment fields in your source code directly before the code block they refer to. For example:

/// 
///  This class performs an important function.
/// 

public class MyClass{}

When you compile with /doc the compiler will search for all XML tags in your source code and create an XML documentation file.

Note
The XML doc comments are not metadata; they are not included in the compiled assembly and therefore they are not accessible through reflection.

Unsafe Code and Pointers in C#

2008-12-13T23:42:00.001-08:00

Unsafe Code and Pointers

To maintain type safety and security, by default C# does not support pointer arithmetic. However, by using the unsafe keyword, it is possible to define an unsafe context in which pointers can be used. For more information about pointers, see the topic Pointer types.

Note
In the common language runtime (CLR), unsafe code is referred to as unverifiable code. Unsafe code in C# is not necessarily dangerous; it is simply code whose safety cannot be verified by the CLR. The CLR will therefore only execute unsafe code if it is within a fully trusted assembly. If you use unsafe code, it is your responsibility to ensure that your code does not introduce security risks or pointer errors. For more information, see Security and C#.

Note

In the common language runtime (CLR), unsafe code is referred to as unverifiable code. Unsafe code in C# is not necessarily dangerous; it is simply code whose safety cannot be verified by the CLR. The CLR will therefore only execute unsafe code if it is within a fully trusted assembly. If you use unsafe code, it is your responsibility to ensure that your code does not introduce security risks or pointer errors. For more information, see Security and C#.

Unsafe Code Overview

Unsafe code has the following properties:

Methods, types, and code blocks can be defined as unsafe.
In some cases, unsafe code may increase an application's performance by removing array bounds checks.
Unsafe code is required when calling native functions that require pointers.
Using unsafe code introduces security and stability risks.
In order for C# to compile unsafe code, the application must be compiled with /unsafe.

Nullable Types in C#

2008-12-13T23:37:00.000-08:00

Nullable Types

Nullable types are instances of the System.Nullable struct. A nullable type can represent the normal range of values for its underlying value type, plus an additional null value. For example, a Nullable, pronounced "Nullable of Int32," can be assigned any value from -2147483648 to 2147483647, or it can be assigned the null value. A Nullable can be assigned the values true or false, or null. The ability to assign null to numeric and Boolean types is particularly useful when dealing with databases and other data types containing elements that may not be assigned a value. For example, a Boolean field in a database can store the values true or false, or it may be undefined.
C#
Copy Code

class NullableExample
{
static void Main()
{
int? num = null;
if (num.HasValue == true)
{
System.Console.WriteLine("num = " + num.Value);
}
else
{
System.Console.WriteLine("num = Null");
}

//y is set to zero
int y = num.GetValueOrDefault();

// num.Value throws an InvalidOperationException if num.HasValue is false
try
{
y = num.Value;
}
catch (System.InvalidOperationException e)
{
System.Console.WriteLine(e.Message);
}
}
}

The above will display the output:

num = Null

Nullable object must have a value.
Nullable Types Overview

Nullable types have the following characteristics:

*

Nullable types represent value-type variables that can be assigned the value of null. You cannot create a nullable type based on a reference type. (Reference types already support the null value.)
*

The syntax T? is shorthand for System.Nullable, where T is a value type. The two forms are interchangeable.
*

Assign a value to a nullable type in the same way as for an ordinary value type, for example int? x = 10; or double? d = 4.108;
*

Use the System.Nullable.GetValueOrDefault property to return either the assigned value, or the default value for the underlying type if the value is null, for example int j = x.GetValueOrDefault();
*

Use the HasValue and Value read-only properties to test for null and retrieve the value, for example if(x.HasValue) j = x.Value;
o

The HasValue property returns true if the variable contains a value, or false if it is null.
o

The Value property returns a value if one is assigned, otherwise a System.InvalidOperationException is thrown.
o

The default value for a nullable type variable sets HasValue to false. The Value is undefined.
*

Use the ?? operator to assign a default value that will be applied when a nullable type whose current value is null is assigned to a non-nullable type, for example int? x = null; int y = x ?? -1;

Namespaces in C#

2008-12-13T23:33:00.001-08:00

Namespaces

Namespaces are heavily used in C# programming in two ways. First, the .NET Framework uses namespaces to organize its many classes, as follows:

System.Console.WriteLine("Hello World!");

System is a namespace and Console is a class contained within that namespace. The using keyword can be used so that the entire name is not required, like this:

using System;

Console.WriteLine("Hello");
Console.WriteLine("World!");

For more information, see the topic using Directive (C# Reference).

Second, declaring your own namespaces can help you control the scope of class and method names in larger programming projects. Use the namespace keyword to declare a namespace, as in the following example:

namespace SampleNamespace
{
   class SampleClass
   {
       public void SampleMethod()
       {
           System.Console.WriteLine(
             "SampleMethod inside SampleNamespace");
       }
   }
}

Namespaces Overview

A namespace has the following properties:

They organize large code projects.
They are delimited with the . operator.
The using directive means you do not need to specify the name of the namespace for every class.
The global namespace is the "root" namespace: global::system will always refer to the .NET Framework namespace System.

Iterators in C#

2008-12-13T23:32:00.001-08:00

Iterators

Iterators are a new feature in C# 2.0. An iterator is a method, get accessor or operator that enables you to support foreach iteration in a class or struct without having to implement the entire IEnumerable interface. Instead, you provide just an iterator, which simply traverses the data structures in your class. When the compiler detects your iterator, it will automatically generate the Current, MoveNext and Dispose methods of the IEnumerable or IEnumerable interface.

Iterators Overview

An iterator is a section of code that returns an ordered sequence of values of the same type.
An iterator can be used as the body of a method, an operator, or a get accessor.
The iterator code uses the yield return statement to return each element in turn. yield break ends the iteration. For more information, see yield.
Multiple iterators can be implemented on a class. Each iterator must have a unique name just like any class member, and can be invoked by client code in a foreach statement as follows: foreach(int x in SampleClass.Iterator2){}
The return type of an iterator must be IEnumerable, IEnumerator, IEnumerable, or IEnumerator.

The yield keyword is used to specify the value, or values, returned. When the yield return statement is reached, the current location is stored. Execution is restarted from this location the next time the iterator is called.

Iterators are especially useful with collection classes, providing an easy way to iterate non-trivial data structures such as binary trees.

Related Sections

For more information:

Example

In this example, the class DaysOfTheWeek is a simple collection class that stores the days of the week as strings. After each iteration of a foreach loop, the next string in the collection is returned.

public class DaysOfTheWeek : System.Collections.IEnumerable
{
   string[] m_Days = { "Sun", "Mon", "Tue", "Wed", "Thr", "Fri", "Sat" };

   public System.Collections.IEnumerator GetEnumerator()
   {
       for (int i = 0; i < m_Days.Length; i++)
       {
           yield return m_Days[i];
       }
   }
}

class TestDaysOfTheWeek
{
   static void Main()
   {
       // Create an instance of the collection class
       DaysOfTheWeek week = new DaysOfTheWeek();

       // Iterate with foreach
       foreach (string day in week)
       {
           System.Console.Write(day + " ");
       }
   }
}

Output

Sun Mon Tue Wed Thr Fri Sat

Generics in C#

2008-12-13T23:31:00.001-08:00

Generics

Generics are a new feature in version 2.0 of the C# language and the common language runtime (CLR). Generics introduce to the .NET Framework the concept of type parameters, which make it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code. For example, by using a generic type parameter T you can write a single class that other client code can use without incurring the cost or risk of runtime casts or boxing operations, as shown here:

// Declare the generic class
public class GenericList
{
   void Add(T input) { }
}
class TestGenericList
{
   private class ExampleClass { }
   static void Main()
   {
       // Declare a list of type int
       GenericList<int> list1 = new GenericList<int>();

       // Declare a list of type string
       GenericList<string> list2 = new GenericList<string>();

       // Declare a list of type ExampleClass
       GenericList list3 = new GenericList();
   }
}

Generics Overview

Use generic types to maximize code reuse, type safety, and performance.
The most common use of generics is to create collection classes.
The .NET Framework class library contains several new generic collection classes in the System.Collections.Generic namespace. These should be used whenever possible in place of classes such as ArrayList in the System.Collections namespace.
You can create your own generic interfaces, classes, methods, events and delegates.
Generic classes may be constrained to enable access to methods on particular data types.
Information on the types used in a generic data type may be obtained at run-time by means of reflection.

Events in C#

2008-12-13T23:30:00.001-08:00

Events

Events provide a way for a class or object to notify other classes or objects when something of interest happens. The class that sends (or raises) the event is called the publisher and the classes that receive (or handle) the event are called subscribers.

In a typical C# Windows Forms or Web application, you subscribe to events raised by controls such as buttons and list boxes. You can use the Visual C# integrated development environment (IDE) to browse the events that a control publishes and select the ones that you want to handle. The IDE automatically adds an empty event handler method and the code to subscribe to the event. For more information, see How to: Subscribe to and Unsubscribe from Events (C# Programming Guide).

Events Overview

Events have the following properties:

The publisher determines when an event is raised; the subscribers determine what action is taken in response to the event.
An event can have multiple subscribers. A subscriber can handle multiple events from multiple publishers.
Events that have no subscribers are never called.
Events are commonly used to signal user actions such as button clicks or menu selections in graphical user interfaces.
When an event has multiple subscribers, the event handlers are invoked synchronously when an event is raised. To invoke events asynchronously, see Calling Synchronous Methods Asynchronously.
Events can be used to synchronize threads.
In the .NET Framework class library, events are based on the EventHandler delegate and the EventArgs base class.

Delegates In C#

2008-12-13T23:29:00.000-08:00

Delegates

A delegate is a type that references a method. Once a delegate is assigned a method, it behaves exactly like that method. The delegate method can be used like any other method, with parameters and a return value, as in this example:

public delegate int PerformCalculation(int x, int y);

Any method that matches the delegate's signature, which consists of the return type and parameters, can be assigned to the delegate. This makes is possible to programmatically change method calls, and also plug new code into existing classes. As long as you know the delegate's signature, you can assign your own delegated method.

This ability to refer to a method as a parameter makes delegates ideal for defining callback methods. For example, a sort algorithm could be passed a reference to the method that compares two objects. Separating the comparison code allows the algorithm to be written in a more general way.

Delegates Overview

Delegates have the following properties:

Delegates are similar to C++ function pointers, but are type safe.
Delegates allow methods to be passed as parameters.
Delegates can be used to define callback methods.
Delegates can be chained together; for example, multiple methods can be called on a single event.
Methods don't need to match the delegate signature exactly. For more information, see Covariance and Contravariance
C# version 2.0 introduces the concept of Anonymous Methods, which permit code blocks to be passed as parameters in place of a separately defined method.