Tipsy little box

Just another weblog

How to cache in ASP.NET November 12, 2009

Filed under: Technical Corner — evacion @ 9:03 pm

SUMMARY
This step-by-step article describes how to control the caching of Web pages and data objects in ASP.NET. When you cache Web pages, you avoid re-creating information when you make a later request. Caching is an important technique for building high performance and scalable server applications. When you make the first request for the page, you can store data objects, pages, or part of the page to the memory. You can store these items on a Web server, on a proxy server, or on the browser.

ASP.NET provides easier methods to control caching. You can use the @ OutputCache directive to control page output caching in ASP.NET. Use the HttpCachePolicy class to store arbitrary objects, such as datasets, to server memory. You can store the cache in applications such as the client browser, the proxy server, and Microsoft Internet Information Services (IIS). By using the Cache-Control HTTP Header, you can control caching.

Cache ASP.NET pages

You can use the @ OutputCache directive to cache, or you can cache programmatically through code by using Visual Basic .NET or Visual C# .NET. The @ OutputCache directive contains a Location attribute. This attribute determines the location for cached item. You can specify the following locations:

  • Any – This stores the output cache in the client’s browser, on the proxy server (or any other server) that participates in the request, or on the server where the request is processed. By default, Any is selected.
  • Client – This stores output cache in the client’s browser.
  • Downstream – This stores the output cache in any cache-capable devices (other than the origin server) that participate in the request.
  • Server – This stores the output cache on the Web server.
  • None – This turns off the output cache.

The following are code samples for the @ OutputCache directive and equivalent programmatic code.
To store the output cache for a specified duration

Declarative Approach:
<%@ OutputCache Duration=”60″ VaryByParam=”None” %>
Programmatic Approach:
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);

To store the output cache on the browser client where the request originated
Declarative Approach:
<%@ OutputCache Duration=”60″ Location=”Client” VaryByParam=”None” %>
Programmatic Approach:
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Private);

To store the output cache on any HTTP 1.1 cache-capable devices including the proxy servers and the client that made request

Declarative Approach:
<%@ OutputCache Duration=”60″ Location=”Downstream” VaryByParam=”None” %>
Programmatic Approach:
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetNoServerCaching();

To store the output cache on the Web server

Declarative Approach:
<%@ OutputCache Duration=”60″ Location=”Server” VaryByParam=”None” %>
Programmatic Approach:
TimeSpan freshness = new TimeSpan(0,0,0,60);
DateTime now = DateTime.Now;
Response.Cache.SetExpires(now.Add(freshness));
Response.Cache.SetMaxAge(freshness);
Response.Cache.SetCacheability(HttpCacheability.Server);
Response.Cache.SetValidUntilExpires(true);

To cache the output for each HTTP request that arrives with a different City:

Declarative Approach:
<%@ OutputCache duration=”60″ varybyparam=”City” %>
Programmatic Approach:
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.VaryByParams["City"] = true;

For the VaryByCustom attribute, the VaryByHeader attribute, and the VaryByParam attribute in the @ OutputCache directive, the HttpCachePolicy class provides the VaryByHeaders property and the VaryByParams property, and the SetVaryByCustom method.

Turn off client and proxy caching
To turn off the output cache for an ASP.NET Web page at the client location and at the proxy location, set the Location attribute value to none, and then set the VaryByParam value to none in the @ OutputCache directive. Use the following code samples to turn off client and proxy caching.

Declarative Approach:
<%@ OutputCache Location=”None” VaryByParam=”None” %>
Programmatic Approach:
Response.Cache.SetCacheability(HttpCacheability.NoCache);

Cache arbitrary objects in server memory
ASP.NET includes a powerful, easy-to-use caching mechanism that you can use to store objects that require a lot of server resources to create in memory. The Cache class implements this method. Instances are private to each application and the lifetime is tied to the corresponding application.

Source: http://msdn.microsoft.com/en-us/kb/kb00323290.aspx

 

Understanding ASP.NET Dynamic Compilation November 11, 2009

Filed under: Technical Corner — evacion @ 10:31 am

In order for your Web application to service requests, ASP.NET must first parse and compile the code of your Web application into one or more assemblies. When the code is compiled, it is translated into a language-independent and CPU-independent representation called Microsoft Intermediate Language (MSIL). At run time, MSIL runs in the context of the .NET Framework, which translates MSIL into CPU-specific instructions for the processor on the computer running the application.

ASP.NET dynamic compilation enables you to modify your source code without having to explicitly compile your code before you deploy your Web application. If you modify a source file, ASP.NET automatically recompiles the file and updates all linked resources. The IIS server does not have to be restarted for the changes to take effect unless the <processModel> section has been changed.

You can extend the ASP.NET build system by creating custom build providers for new file types that are called during compilation.

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

 

Compile-time vs run-time November 11, 2009

Filed under: Technical Corner — evacion @ 10:28 am

The difference between compile time and run time is an example of what pointy-headed theorists call the phase distinction. It is one of the hardest concepts to learn, especially for people without much background in programming languages. To approach this problem, I find it helpful to ask

  1. What invariants does the program satisfy?
  2. What can go wrong in this phase?
  3. If the phase succeeds, what are the postconditions (what do we know)?
  4. What are the inputs and outputs, if any?

Compile time

  1. The program need not satisfy any invariants. In fact, it needn’t be a well-formed program at all. You could feed this HTML to the compiler and watch it barf…
  2. What can go wrong at compile time:
    • Syntax errors
    • Typechecking errors
    • (Rarely) compiler crashes
  3. If the compiler succeeds, what do we know?
    • The program was well formed—a meaningful program in whatever language.
    • It’s possible to start running the program. (The program might fail immediately, but at least we can try.)
  4. What are the inputs and outputs?
    • Input was the program being compiled, plus any header files, interfaces, libraries, or other voodoo that it needed to import in order to get compiled.
    • Output is hopefully assembly code or relocatable object code or even an executable program. Of if something goes wrong, output is a bunch of error messages.

Run time

  1. We know nothing about the program’s invariants—they are whatever the programmer put in. Run-time invariants are rarely enforced by the compiler alone; it needs help from the programmer.
  2. What can go wrong are run-time errors:

    • Division by zero
    • Deferencing a null pointer
    • Running out of memory

    Also there can be errors that are detected by the program itself:

    • Trying to open a file that isn’t there
    • Trying find a web page and discovering that an alleged URL is not well formed
  3. If run-time succeeds, the program finishes (or keeps going) without crashing.
  4. Inputs and outputs are entirely up to the programmer. Files, windows on the screen, network packets, jobs sent to the printer, you name it. If the program launches missiles, that’s an output, and it happens only at run time.

source: http://stackoverflow.com/questions/846103/runtime-vs-compile-time  

 

Importing Data From Excel with C# September 30, 2009

Filed under: ASP.NET, C# — evacion @ 1:16 pm

The following code block accepts an Excel file path and returns an ordinary DataTable object, which can be manipulated easily by the code that calls this method. The first row of the Excel document becomes the columns in the DataTable object and each row thereafter are DataRow objects.

ImportingFromExcel

If you like, take a look at both techniques for working with Excel data and see what one speaks to you.

(Source: http://blogs.popart.com/2008/07/importing-data-from-excel-with-c/ )

 

Delegates and Events in C# / .NET September 16, 2009

Filed under: ASP.NET, C# — evacion @ 5:22 pm

Delegates
A delegate in C# is similar to a function pointer in C or C++. Using a delegate allows the programmer to encapsulate a reference to a method inside a delegate object. The delegate object can then be passed to code which can call the referenced method, without having to know at compile time which method will be invoked.

Call a Function directly – No Delegate

In most cases, when we call a function, we specify the function to be called directly. If the class MyClass has a function named Process, we’d normally call it like this (SimpleSample.cs):

using System;
namespace evacion.NoDelegate{

public class MyClass {
public void Process() {
Console.WriteLine(“Process() begin”);
Console.WriteLine(“Process() end”);
}
}

public class Test {
static void Main(string[] args) {
MyClass myClass = new MyClass();
myClass.Process();
}
}
}

That works well in most situations. Sometimes, however, we don’t want to call a function directly – we’d like to be able to pass it to somebody else so that they can call it. This is especially useful in an event-driven system such as a graphical user interface, when I want some code to be executed when the user clicks on a button, or when I want to log some information but can’t specify how it is logged.
The very basic Delegate
An interesting and useful property of a delegate is that it does not know or care about the class of the object that it references. Any object will do; all that matters is that the method’s argument types and return type match the delegate’s. This makes delegates perfectly suited for “anonymous” invocation.
The signature of a single cast delegate is shown below:

delegate result-type identifier ([parameters]);
where:
result-type: The result type, which matches the return type of the function.
identifier: The delegate name.
parameters: The Parameters, that the function takes.
Examples:
public delegate void SimpleDelegate ()
This declaration defines a delegate named SimpleDelegate, which will encapsulate any method that takes
no parameters and returns no value.
public delegate int ButtonClickHandler (object obj1, object obj2)
This declaration defines a delegate named ButtonClickHandler, which will encapsulate any method that takes
two objects as parameters and returns an int.
A delegate will allow us to specify what the function we’ll be calling looks like without having to specify which function to call. The declaration for a delegate looks just like the declaration for a function, except that in this case, we’re declaring the signature of functions that this delegate can reference.

There are three steps in defining and using delegates:

Declaration
Instantiation
Invocation
A very basic example (SimpleDelegate1.cs):

using System;
namespace evacion.BasicDelegate{
// Declaration
public delegate void SimpleDelegate();

class TestDelegate {
public static void MyFunc(){
Console.WriteLine(“I was called by delegate …”);
}
public static void Main(){
// Instantiation
SimpleDelegate simpleDelegate = new SimpleDelegate(MyFunc);
// Invocation
simpleDelegate();
}
}
}

Compile an test:
# csc SimpleDelegate1.cs
# SimpleDelegate1.exe
I was called by delegate …

Calling Static Functions
For our next, more advanced example (SimpleDelegate2.cs), declares a delegate that takes a single string parameter and has no return type:

using System;
namespace evacion.SimpleDelegate{
// Delegate Specification
public class MyClass {
// Declare a delegate that takes a single string parameter
// and has no return type.

public delegate void LogHandler(string message);

// The use of the delegate is just like calling a function directly,
// though we need to add a check to see if the delegate is null
// (that is, not pointing to a function) before calling the function.

public void Process(LogHandler logHandler){
if (logHandler != null){
logHandler(“Process() begin”);
}
if (logHandler != null){
logHandler (“Process() end”);
}
}
}
// Test Application to use the defined Delegate
public class TestApplication {
// Static Function: To which is used in the Delegate. To call the Process()
// function, we need to declare a logging function: Logger() that matches
// the signature of the delegate.

static void Logger(string s){
Console.WriteLine(s);
}
static void Main(string[] args){
MyClass myClass = new MyClass();
// Crate an instance of the delegate, pointing to the logging function.
// This delegate will then be passed to the Process() function.

MyClass.LogHandler myLogger = new MyClass.LogHandler(Logger);
myClass.Process(myLogger);
}
}
}

Compile an test:
# csc SimpleDelegate2.cs
# SimpleDelegate2.exe
Process() begin
Process() end

Calling Member Functions
In the simple example above, the Logger( ) function merely writes the string out. A different function might want to log the information to a file, but to do this, the function needs to know what file to write the information to (SimpleDelegate3.cs)

using System;
using System.IO;
namespace evacion.SimpleDelegate{
// Delegate Specification
public class MyClass{
// Declare a delegate that takes a single string parameter
// and has no return type.

public delegate void LogHandler(string message);
// The use of the delegate is just like calling a function directly,
// though we need to add a check to see if the delegate is null
// (that is, not pointing to a function) before calling the function.

public void Process(LogHandler logHandler) {
if (logHandler != null) {
logHandler(“Process() begin”);
}
if (logHandler != null) {
logHandler (“Process() end”);
}
}
}
// The FileLogger class merely encapsulates the file I/O
public class FileLogger {
FileStream fileStream;
StreamWriter streamWriter;
// Constructor
public FileLogger(string filename) {
fileStream = new FileStream(filename, FileMode.Create);
streamWriter = new StreamWriter(fileStream);
}
// Member Function which is used in the Delegate
public void Logger(string s) {
streamWriter.WriteLine(s);
}
public void Close() {
streamWriter.Close();
fileStream.Close();
}
}
// Main() is modified so that the delegate points to the Logger()
// function on the fl instance of a FileLogger. When this delegate
// is invoked from Process(), the member function is called and
// the string is logged to the appropriate file.
public class TestApplication {
static void Main(string[] args) {
FileLogger fl = new FileLogger(“process.log”);
MyClass myClass = new MyClass();
// Crate an instance of the delegate, pointing to the Logger()
// function on the fl instance of a FileLogger.

MyClass.LogHandler myLogger = new MyClass.LogHandler(fl.Logger);
myClass.Process(myLogger);
fl.Close();
}
}
}

The cool part here is that we didn’t have to change the Process() function; the code to all the delegate is the same regardless of whether it refers to a static or member function.

Compile an test:
# csc SimpleDelegate3.cs
# SimpleDelegate3.exe
# cat process.log
Process() begin
Process() end

Multicasting

Being able to point to member functions is nice, but there are more tricks you can do with delegates. In C#, delegates are multicast, which means that they can point to more than one function at a time (that is, they’re based off the System.MulticastDelegate type). A multicast delegate maintains a list of functions that will all be called when the delegate is invoked. We can add back in the logging function from the first example, and call both delegates. Here’s what the code looks like:

using System;
using System.IO;
namespace evacion.SimpleDelegate{
// Delegate Specification
public class MyClass{
// Declare a delegate that takes a single string parameter
// and has no return type.

public delegate void LogHandler(string message);
// The use of the delegate is just like calling a function directly,
// though we need to add a check to see if the delegate is null
// (that is, not pointing to a function) before calling the function.

public void Process(LogHandler logHandler){
if (logHandler != null){
logHandler(“Process() begin”);
}
if (logHandler != null) {
logHandler (“Process() end”);
}
}
}
// The FileLogger class merely encapsulates the file I/O
public class FileLogger{
FileStream fileStream;
StreamWriter streamWriter;
// Constructor
public FileLogger(string filename) {
fileStream = new FileStream(filename, FileMode.Create);
streamWriter = new StreamWriter(fileStream);
}
// Member Function which is used in the Delegate
public void Logger(string s){
streamWriter.WriteLine(s);
}

public void Close() {
streamWriter.Close();
fileStream.Close();
}
}
// Test Application which calls both Delegates
public class TestApplication {
// Static Function which is used in the Delegate
static void Logger(string s) {
Console.WriteLine(s);
}
static void Main(string[] args) {
FileLogger fl = new FileLogger(“process.log”);
MyClass myClass = new MyClass();
// Crate an instance of the delegates, pointing to the static
// Logger() function defined in the TestApplication class and
// then to member function on the fl instance of a FileLogger.

MyClass.LogHandler myLogger = null;
myLogger += new MyClass.LogHandler(Logger);
myLogger += new MyClass.LogHandler(fl.Logger);
myClass.Process(myLogger);
fl.Close();
}
}
}

Compile an test:
# csc SimpleDelegate4.cs
# SimpleDelegate4.exe
Process() begin
Process() end
# cat process.log
Process() begin
Process() end

Events
The Event model in C# finds its roots in the event programming model that is popular in asynchronous programming. The basic foundation behind this programming model is the idea of “publisher and subscribers.” In this model, you have publishers who will do some logic and publish an “event.” Publishers will then send out their event only to subscribers who have subscribed to receive the specific event.
In C#, any object can publish a set of events to which other applications can subscribe. When the publishing class raises an event, all the subscribed applications are notified. The following figure shows this mechanism.

events

Conventions

The following important conventions are used with events:

  • Event Handlers in the .NET Framework return void and take two parameters.
  • The first paramter is the source of the event; that is the publishing object.
  • The second parameter is an object derived from EventArgs.
  • Events are properties of the class publishing the event.
  • The keyword event controls how the event property is accessed by the subscribing classes.

Simple Event
Let’s modify our logging example from above to use an event rather than a delegate:

using System;
using System.IO;
namespace evacion.SimpleEvent{
/* ========= Publisher of the Event ============== */
public class MyClass {
// Define a delegate named LogHandler, which will encapsulate
// any method that takes a string as the parameter and returns no value

public delegate void LogHandler(string message);
// Define an Event based on the above Delegate
public event LogHandler Log;
// Instead of having the Process() function take a delegate
// as a parameter, we’ve declared a Log event. Call the Event,
// using the OnXXXX Method, where XXXX is the name of the Event.

public void Process() {
OnLog(“Process() begin”);
OnLog(“Process() end”);
}
// By Default, create an OnXXXX Method, to call the Event
protected void OnLog(string message) {
if (Log != null) {
Log(message);
}
}
}
// The FileLogger class merely encapsulates the file I/O
public class FileLogger {
FileStream fileStream;
StreamWriter streamWriter;
// Constructor
public FileLogger(string filename) {
fileStream = new FileStream(filename, FileMode.Create);
streamWriter = new StreamWriter(fileStream);
}
// Member Function which is used in the Delegate
public void Logger(string s) {
streamWriter.WriteLine(s);
}
public void Close() {
streamWriter.Close();
fileStream.Close();
}
}
/* ========= Subscriber of the Event ============== */
// It’s now easier and cleaner to merely add instances
// of the delegate to the event, instead of having to
// manage things ourselves

public class TestApplication {
static void Logger(string s) {
Console.WriteLine(s);
}
static void Main(string[] args) {
FileLogger fl = new FileLogger(“process.log”);
MyClass myClass = new MyClass();
// Subscribe the Functions Logger and fl.Logger
myClass.Log += new MyClass.LogHandler(Logger);
myClass.Log += new MyClass.LogHandler(fl.Logger);
// The Event will now be triggered in the Process() Method
myClass.Process();
fl.Close();
}
}
}

Compile an test:
# csc SimpleEvent.cs
# SimpleEvent.exe
Process() begin
Process() end
# cat process.log
Process() begin
Process() end

The Second Change Event Example
Suppose you want to create a Clock class that uses events to notify potential subscribers whenever the local time changes value by one second. Here is the complete, documented example:

using System;
using System.Threading;
namespace evacion.SecondChangeEvent{
/* ======================= Event Publisher =============================== */
// Our subject — it is this class that other classes
// will observe. This class publishes one event:
// SecondChange. The observers subscribe to that event.

public class Clock {
// Private Fields holding the hour, minute and second
private int _hour;
private int _minute;
private int _second;
// The delegate named SecondChangeHandler, which will encapsulate
// any method that takes a clock object and a TimeInfoEventArgs
// object as the parameter and returns no value. It’s the
// delegate the subscribers must implement.

public delegate void SecondChangeHandler (
object clock,
TimeInfoEventArgs timeInformation
);

// The event we publish
public event SecondChangeHandler SecondChange;
// The method which fires the Event
protected void OnSecondChange(
object clock,
TimeInfoEventArgs timeInformation
) {
// Check if there are any Subscribers
if (SecondChange != null) {
// Call the Event
SecondChange(clock,timeInformation);
}
}

// Set the clock running, it will raise an
// event for each new second

public void Run() {
for(;;) {
// Sleep 1 Second
Thread.Sleep(1000);
// Get the current time
System.DateTime dt = System.DateTime.Now;
// If the second has changed
// notify the subscribers

if (dt.Second != _second) {
// Create the TimeInfoEventArgs object
// to pass to the subscribers

TimeInfoEventArgs timeInformation =
new TimeInfoEventArgs(
dt.Hour,dt.Minute,dt.Second);

// If anyone has subscribed, notify them
OnSecondChange (this,timeInformation);
}
// update the state
_second = dt.Second;
_minute = dt.Minute;
_hour = dt.Hour;
}
}
}
// The class to hold the information about the event
// in this case it will hold only information
// available in the clock class, but could hold
// additional state information

public class TimeInfoEventArgs : EventArgs {
public TimeInfoEventArgs(int hour, int minute, int second) {
this.hour = hour;
this.minute = minute;
this.second = second;
}
public readonly int hour;
public readonly int minute;
public readonly int second;
}
/* ======================= Event Subscribers =============================== */
// An observer. DisplayClock subscribes to the
// clock’s events. The job of DisplayClock is
// to display the current time

public class DisplayClock {
// Given a clock, subscribe to
// its SecondChangeHandler event

public void Subscribe(Clock theClock) {
theClock.SecondChange +=
new Clock.SecondChangeHandler(TimeHasChanged);

}
// The method that implements the
// delegated functionality

public void TimeHasChanged(
object theClock, TimeInfoEventArgs ti)
{
Console.WriteLine(“Current Time: {0}:{1}:{2}”,
ti.hour.ToString(),
ti.minute.ToString(),
ti.second.ToString());
}
}
// A second subscriber whose job is to write to a file
public class LogClock {
public void Subscribe(Clock theClock) {
theClock.SecondChange +=
new Clock.SecondChangeHandler(WriteLogEntry);
}
// This method should write to a file
// we write to the console to see the effect
// this object keeps no state

public void WriteLogEntry(
object theClock, TimeInfoEventArgs ti) {
Console.WriteLine(“Logging to file: {0}:{1}:{2}”,
ti.hour.ToString(),
ti.minute.ToString(),
ti.second.ToString());
}
}
/* ======================= Test Application =============================== */
// Test Application which implements the
// Clock Notifier – Subscriber Sample

public class Test {
public static void Main() {
// Create a new clock
Clock theClock = new Clock();
// Create the display and tell it to
// subscribe to the clock just created

DisplayClock dc = new DisplayClock();
dc.Subscribe(theClock);
// Create a Log object and tell it
// to subscribe to the clock

LogClock lc = new LogClock();
lc.Subscribe(theClock);
// Get the clock started
theClock.Run();
}
}
}

Conclusion
The Clock class from the last sample could simply print the time rather tahn raising an event, so why bother with the introduction of using delegates? The advantage of the publisg / subscribe idiom is that any number of classes can be notified when an event is raised. The subscribing classes do not need to know how the Clock works, and the Clock does not need to know what they are going to do in response to the event. Similarly a button can publish an Onclick event, and any number of unrelated objects can subscribe to that event, receiving notification when the button is clicked.
The publisher and the subscribers are decoupled by the delegate. This is highly desirable as it makes for more flexible and robust code. The clock can chnage how it detects time without breaking any of the subscribing classes. The subscribing classes can change how they respond to time changes without breaking the Clock. The two classes spin indepentdently of one another, which makes for code that is easier to maintain.

(Source: http://www.akadia.com/services/dotnet_delegates_and_events.html )

 

Cross-Page Postbacks in ASP.NET 2.0 September 16, 2009

Filed under: ASP.NET, C# — evacion @ 11:28 am

By default, an ASP.NET web form posts back to itself whenever a postback operation occurs. That behavior wasn’t terribly common in web pages before ASP.NET appeared, and isn’t always what you want to have happen: What if you want to post a web form to another web page in the application? ASP.NET made that fairly difficult in ASP.NET 1.0, but ASP.NET 2.0 makes developers lives easier in this regard by adding a new feature called “cross-page postbacks” that allows a web page to post its data back to a different web page. In cross-page postbacks, the page that initiates the postback is called the source page and the page to which the client posts is called the target page. Conveniently, the target page can still retrieve any control values posted by the source web page in a cross-page postback operation. In other words, from a development point of view, you can process the posted data in much the same way you would process any normal ASP.NET postback. The new feature means ASP.NET 2.0 developers now have three techniques for transferring processing from one web page to another in an application: Response.Redirect, Server.Transfer, and the new cross-page postback features.

The Response.Redirect Method

The Response.Redirect method is by far the simplest method of redirecting processing from a source page to a different destination or target page in the same or even across different applications. When the web server receives a request for redirection, it sends a response header to the client that causes the client to send a new request back to the server. In other words, a redirect causes two request/response cycles: one for the original and one for the new redirected request.
ASP.NET makes redirects easy. The following code snippet illustrates how to use the Response.Redirect method:
protected void Redirect_Click(object sender, EventArgs e) {
Response.Redirect(“menu.aspx”);
}
Note that the redirect request is a GET request, meaning that you can’t post data from the original page via the Response.Redirect command. You can work around that to pass data from the source to the target by using query strings in the Response.Redirect method call as shown below:

protected void Redirect_Click(object sender, EventArgs e) {
Response.Redirect(“menu.aspx?userName=” + UserName.Text));
}

The preceding example passes a query string as a parameter to the Response.Redirect method along with the target URL. The target can now use code such as the following to retrieve the source’s data as shown below:

protected void Page_Load(object sender, EventArgs e) {
string userName = Request["userName"];
//Other code
}

The Server.Transfer Method
Instead of relying on the client to make a request to a new page, Server.Transfer is a server-side redirection technique that simply changes the code’s “focus” on the web server to a new page. Server.Transfer is far more efficient than Response.Redirect when the target page resides on the same web server, because it avoids the extra roundtrip and uses only server resources for the redirection. Note that it has a side effect—the URL shown in the web browser does not change either—meaning clients may think they posted their data to one page while actually posting it to a different page. In most cases, that’s not a problem, but it can make debugging more difficult.
Server.Transfer also preserves the HttpContext of the initiating page; therefore the target page can access the control values of the source page. Specifically, you can use the FormsCollection property to retrieve the source control values from the target page when using the Server.Transfer technique. First, make sure you use the overloaded Server.Transfer method, which accepts two parameters—the target URL, and a Boolean preserveForm value which tells the server to preserve the query string and any control values from the source page. Set the preserveForm parameter to true in the source web page as shown below:
Server.Transfer(“Menu.aspx”,true);
Then, from the target page, to retrieve the value of a textbox control called txtUserName for example, use the following code:
object obj = Request.Form["txtUserName"];

Response.Redirect vs. Server.Transfer
Because Response.Redirect requires an extra round trip, you should avoid it for high-volume web sites due to associated performance and scalability issues. However, this is the only technique that you can use to redirect from one web server to another. In contrast, Server.Transfer is more efficient, but can transfer execution only to a different web page on the same server. In essence, you’d use Server.Transfer to eliminate unnecessary roundtrips when both the source and the target web page reside on the same server (they can be in different ASP.NET applications on that server), and use Response.Redirect when you need to redirect to a different server.

Cross-page Postbacks
In ASP.NET 2.0, the cross-page postback feature lets you configure page controls that implement the new IButtonControl interface to post to a different target page from the originating web form. Like Response.Redirect, cross-page postbacks are a client-based transfer mechanism—but like Server.Transfer, the target web page can (usually) access the control values of the source page. To set up a cross-page postback, you specify the target URL in the PostBackUrl property of the source web page.
Implementing Cross-page Postbacks
This section discusses how to implement cross-page postbacks in an ASP.NET 2.0 application. If you’re not already thoroughly familiar with ASP.NET postback operations, you can find out more here.
To begin with, assume that you have two web pages—a source and a target. The source web page initiates the cross-page postback operation using a Button control. You first have to set the PostBackUrl property for the button to the target web page’s URL. Incidentally, all web controls that implement the System.Web.UI.WebControls.IButtonControl interface have the cross-page postback feature enabled by default. The following code snippet shows how to set the property.

When you set the PostBackUrl property, the ASP.NET framework binds the corresponding control to a new JavaScript function named WebForm_DoPostBackWithOptions, generating HTML similar to the following:

With that HTML in place, when a user clicks the button, the browser will submit to the target URL (Target.aspx) rather than to the source URL.

Retrieving Source Control Values from the Target Page
ASP.NET 2.0 provides a new property called PreviousPage that returns a reference to the type of the source page whenever a cross-page post back occurs in your web application. Note that this property contains null (it’s not initialized) when the source and the target web pages are in different applications. Also note that when the target page accesses the PreviousPage property to retrieve the control values of the source page, the ASP.NET runtime loads and executes the source page. That fires the ProcessChildRequest event handler. Moreover, it also fires the Page_Init, Page_Load and any other source page button click events.
So that you can avoid doing all that work accidentally, it’s best to check the IsCrossPostBack Boolean property to determine whether a cross-page postback has actually occurred; the value is true if the target page was requested by a cross-page postback has actually occurred. The value is false if control reached the target web page another way (such as a normal request, a Response.Redirect, or a Server.Transfer). Here’s an example that illustrates how to use this property:

if ( PreviousPage.IsCrossPagePostBack) {
//Some code
}
The PreviousPage property works for both Server.Transfer and cross-page postbacks in ASP.NET 2.0. In ASP.NET 2.0, you can use the PreviousPageProperty after a Server.Transfer operation to retrieve the control values of the source page from within the target page. Here’s an example:

protected void Redirect_Click(object sender, EventArgs e) {
Server.Transfer(“menu.aspx”);
}

The receiving web page can now retrieve the control values of the sender web page as shown in the code snippet below:

protected void Page_Load(object sender, EventArgs e) {
if (PreviousPage != null) {
TextBox txtBox = (TextBox)
PreviousPage.FindControl(“txtUserName”);
if (textBox != null)
string userName = textBox.Text;
//Other code
}
}
Notice that the preceding code has to cast the txtUserName control to a TextBox type to access the value. There’s a better way, as you’ll see.

A Better Approach: Using PreviousPageType
The PreviousPageType property provides strongly typed access to a source web page in a cross-page postback operation, letting you retrieve control values from the source page without any typecasting overhead. The code snippets below illustrate how you can use this property.
In the source page you might write:

Note that clicking the button redirects the user to a “Menu.aspx” target page. The target page can retrieve the username and password values using this code:

protected void Page_Load(object sender, System.EventArgs e){
String userName = PreviousPage.txtUserName.Text;
String password = PreviousPage.txtPassword.Text;
//Other code
}

In the preceding code, the PreviousPageType property returns a strongly typed reference to the source web page, eliminating the need to cast.

ViewState Preserved
For cross-page postbacks, ASP.NET 2.0 embeds a hidden input field named __POSTBACK that contains the ViewState information of the source web page—provided the source page contains a server control with a non-null PostBackUrl property value. The target page can use that __POSTBACK information to retrieve the ViewState information of the source web page as shown below:

if(PreviousPage!=null && PreviousPage.IsCrossPagePostBack &&
PreviousPage.IsValid) {
TextBox txtBox = PreviousPage.FindControl(“txtUserName”);
Response.Write(txtBox.Text);
}

The preceding code checks to ensure that the PreviousPage property is not null. Incidentally, the PreviousPage property contains null if the target page is not in the same application. The IsCrossPagePostBack property will be true only if processing reached the target page due to a cross-page postback operation.
The Cross Page Postback feature, one of the most powerful features in ASP.NET 2.0, allows a web page to postback to another web page and still enable retrieval of the values of the server controls of the source web page from within the target web page seamlessly.

(Source: http://www.devx.com/dotnet/Article/33835/1763/page/1 )

 

C# Heap(ing) Vs Stack(ing) in .NET August 20, 2009

Filed under: Technical Corner — evacion @ 4:05 pm

Interesting article about heap, stack and Garbage Collector can be found here: http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx

Other source: Top 20 .NET Garbage Collection (GC) Articles

 

POST-Redirect-GET Pattern August 18, 2009

Filed under: Technical Corner — evacion @ 3:33 pm

HTTP supports several methods that define the nature of the current request. The two most important ones are GET and POST. GET is the primary method to get content (so called entities) from the server such as HTML pages, images, CSS style sheets etc. The POST method on the other hand is meant to transport entities to the server, for example login credentials or a blog comment. On the server side a POST request often results in an update of certain data (databases, session state).

Both GET and POST can return an entity as a response. For GET this is obvious – it’s what the method exists for in the first place. For POST it might sound reasonable in the first place as well, but it brings a pile of problems.

A simple scenario

Imagine you fill in a sign-up form of some web based e-mail service and POST it to the server using a submit button. The server processes the new account and updates its database. Maybe it even logs you in directly. In response of the POST request the server directly shows you a view of your inbox. Here’s a diagram of what happens between browser and server:

post

  • The browser POSTs form data to an URL called signup.aspx
  • The server processes the request
  • The server responds with a status code of 200 (OK) and sends back a view of the new users inbox rendered as HTML

You leave the computer to have a coffee and when you come back 5 minutes later you refresh the page (using CTRL+R or F5 or whatever shortcut your browser uses) to see whether you already have new messages. You are a bit puzzled why this (or a similar) message box appears:

confirm

You click on OK and are even more confused as the page that appears says “This user name is already taken” instead of showing your inbox .

What has happened? Remember that the page you saw was the response of a POST request (submitting the sign up form). When you refreshed the page and confirmed to “resend the data” you actually repeated the POST request with the same form data. The server processed the “new” account and found that the user name is already in use (by yourself!), therefore it showed an error. “But wait”, you say, “I just wanted the server to refresh the view of my inbox, what have I done wrong? ” The answer is: nothing! The problem is that the application abused the POST response to transport an entity back to the client that should have been accessed with a GET request in the first place.

POST related issues

Here are some of the problems that occur if you abuse POST requests to return entities:

1. Refreshing the page results in a re-transmission of the POST data

This is what I described above. Hitting “refresh page” for a reponse based on a POST request will re-issue the POST request. Instead of refreshing what you see this will repeat what you did to reach the current page. This is not “refresh page” anymore, it becomes “repeat last action” – which is most likely not what the user wants. If you see a summary page after you have submitted an order in an online store, you don’t want F5 to drop another order, do you?

2. POST responses are hard to bookmark

Bookmarks (or favourites etc.) normally only remember the URL of the bookmarked page (along with some user supplied meta data). Because a POST request transports data in the request body instead as query parameters in the URL like GET does, bookmarking the result of a POST will not work in most cases.

3. POST responses pollute the browser history

If the browser keeps the result of a POST request in it’s history, going back to that history entry will normally result in POST data to be retransmitted. This again causes the same issues as mentioned in point 1.

POST-Redirect-GET

“But I need POSTs to send forms to the server – how can I avoid the problems mentioned above?” you might say. Here’s where the POST-Redirect-GET (PRG hereafter) pattern enters the stage.

Instead of sending entity content with the POST response after we processed the request, we return the URL of a new location which the browser should visit afterwards. Normally this new location shows the result of the POST or an updated view of some domain model.

This can be achieved by not returning a result code of 200 (success) but instead returning a status code that indicates a new location for the result, for example 303 (“See other”) or 302(“Found”/”Moved temporarily”), the latter of which is used most often nowadays. Together with the 30x result code a Location header is sent which contains the URL of the page to which the request is redirected. Only the headers are sent, no body is included.

If the browser sees the 30x status code, it will look for the Location header and issue a GET request to the URL mentioned there. Finally the user will see the body of that GET request in the browser.

The browser-server communication would look like this:

PRG

  • The browser POSTs to signup.aspx
  • The server updates some state etc.
  • The response is 302 redirect with a Location header value of inbox.aspx
  • The browser realizes that the response is redirected and issues a GET to inbox.aspx
  • The server returns 200 together with the content of the resource.

What do we gain?

  • The page can be safely refreshed. Refreshing will cause another GET to inbox.aspx which won’t cause any updates on the server
  • The result page can be easily bookmarked. Because the current resource is defined by the URL a bookmark to this URL is likely to be valid.
  • The browser history stays clean. Responses that have a redirect status code (such as 302) will not be put into the browser cache by most browsers. Only the location to which the response is redirecting is. Therefore signup.aspx won’t be added to the history and we can safely go back and forth through the history without having to resubmit any POST data

The problem with ASP.NET WebForms
Now that you know about POST-Redirect-GET you are of course eager to use it (at least I hope I could convince you). But as an ASP.NET WebForms developer you will soon run into problems: ASP.NET WebForms is fundamentally based on POSTs to the server. In essence, all ASP.NET web pages are wrapped in one huge

element with “method” set to “POST”. Whenever you click a button, you essentially POST all form fields to the server. Of course you can redirect from a Button.Click handler. If you do so, you’re applying PRG. At the same time you’re working quite against the WebForms philosophy, especially the ViewState (which will get lost as soon as you redirect), which will force you to rethink a lot of your application logic. And if you don’t rely on all this postback behaviour inherent to ASP.NET WebForms you might as well ask why you’re using WebForms in the first place.
This makes clear why a lot of developers (including me) think that WebForms are inherently “broken” (viewstate, ubiquitous postbacks and the hard-to-mock HttpContext are just a few reasons). If you share these concerns but like .NET just as I do, you might want to look at alternate .NET based web frameworks such as Castle MonoRail or ASP.NET MVC.

See entire article: http://blog.andreloker.de/post/2008/06/Post-Redirect-Get.aspx

 

Why does C# have both ‘ref’ and ‘out’? August 12, 2009

Filed under: ASP.NET, C# — evacion @ 10:23 am

Ref and out parameter passing modes are used to allow a method to alter variables passed in by the caller. The difference between ref and out is subtle but important. Each parameter passing mode is designed to apply to a slightly different programming scenario. The important difference between out and ref parameters is the definite assignment rules used by each.
The caller of a method which takes an out parameter is not required to assign to the variable passed as the out parameter prior to the call; however, the callee is required to assign to the out parameter before returning.
Here’s a simple example:

 class OutExample{
      // Splits a string containing a first and last name separated
      // by a space into two distinct strings, one containing the first name and one containing the last name

      static void SplitName(string fullName, out string firstName, out string lastName){
            // NOTE: firstName and lastName have not been assigned to yet.  Their values cannot be used.
            int spaceIndex = fullName.IndexOf(‘ ‘);
            firstName = fullName.Substring(0, spaceIndex).Trim();
            lastName = fullName.Substring(spaceIndex).Trim();
      }

      static void Main(){
            string fullName = “Yuan Sha”;
            string firstName;
            string lastName;

            // NOTE: firstName and lastName have not been assigned yet.  Their values may not be used.
            SplitName(fullName, out firstName, out lastName);
            // NOTE: firstName and lastName have been assigned, because the out parameter passing mode guarantees it.
            System.Console.WriteLine(“First Name ‘{0}’. Last Name ‘{1}’”, firstName, lastName);
      }
}

One way to think of out parameters is that they are like additional return values of a method. They are very convenient when a method returns more than one value, in this example firstName and lastName. Out parameters can be abused however. As a matter of good programming style if you find yourself writing a method with many out parameters then you should think about refactoring your code. One possible solution is to package all the return values into a single struct.
In contrast ref parameters are considered initially assigned by the callee. As such, the callee is not required to assign to the ref parameter before use. Ref parameters are passed both into and out of a method.
Here’s an example:

class RefExample{
      static object FindNext(object value, object[] data, ref int index){
            // NOTE: index can be used here because it is a ref parameter
            while (index < data.Length){
                  if (data[index].Equals(value)){
                        return data[index];
                  }
                   index += 1;
            }
             return null;
      }

      static void Main(){
            object[] data = new object[] {1,2,3,4,2,3,4,5,3};
            int index = 0;
            // NOTE: must assign to index before passing it as a ref parameter
            while (FindNext(3, data, ref index) != null){
                  // NOTE: that FindNext may have modified the value of index
                  System.Console.WriteLine(“Found at index {0}”, index);
                  index += 1;
            }
            System.Console.WriteLine(“Done Find”);
      }
}

The two parameter passing modes addressed by out and ref are subtly different, however they are both very common. The subtle difference between these modes leads to some very common programming errors. These include:

  • not assigning a value to an out parameter in all control flow paths
  • not assigning a value to variable which is used as a ref parameter

Because the C# language assigns different definite assignment rules to these different parameter passing modes, these common coding errors are caught by the compiler as being incorrect C# code.
The crux of the decision to include both ref and out parameter passing modes was that allowing the compiler to detect these common coding errors was worth the additional complexity of having both ref and out parameter passing modes in the language.

Source: http://msdn.microsoft.com/en-us/vcsharp/aa336814.aspx

 

Source of a PostBack June 11, 2009

Filed under: ASP.NET, C# — evacion @ 3:08 pm
Tags:

Basics of what a PostBack event is:  Most ASP.NET Controls are “Server Controls”. This means that when an action occurs, the Page, which hosts all its controls inside. But, how does the Page class “know” which control was “clicked, changed, or whatever”? Very simply, each control generates plain old client-side Javascript. Since HTTP is stateless and there is no “invisible connection” between the server-side classes and the client-side HTML document in your browser, how can a client-side event be handled on the server side? In ASP.NET, this is done by using hidden form fields. A client-side event, such as an “onclick” or “onchange” event, can be captured by a JavaScript event handler. ASP.Net provides the javascript __doPostBack() function. This records the name of the object that fired the event, as well as any additional event information, places it into the hidden form fields __EVENTTARGET and __EVENTARGUMENT, and then submits the form, initiating our PostBack.
On the server side, any controls that implement either the IPostBackDataHandler or IPostBackEventHandler interfaces (which means that they can process client-side events) will have the appropriate method called to examine the PostBack data and see if they have raised the client-side event. If so, the corresponding server-side event is raised and the event handler method is called. You can create your own custom PostBack by simply calling the ASP.NET “GetPostBackEventReference” method.

 Global.asax.cs codebehind file:

using System;
using System.Collections;
using System.ComponentModel;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;

namespace WhichControlPostedBack{
 public class Global : System.Web.HttpApplication{
  private System.ComponentModel.IContainer components = null;

  public Global(){
   InitializeComponent();
  } 

public static System.Web.UI.Control GetPostBackControl(System.Web.UI.Page page){
  Control control = null;
  string ctrlname = page.Request.Params["__EVENTTARGET"];
  if (ctrlname != null && ctrlname != String.Empty){
   control = page.FindControl(ctrlname);
  }
  // if __EVENTTARGET is null, the control is a button type and we need to 
  // iterate over the form collection to find it
  else{
   string ctrlStr=String.Empty;
   Control c=null;
   foreach (string ctl in page.Request.Form){
    // handle ImageButton controls ...
    if (ctl.EndsWith(".x") || ctl.EndsWith(".y")){
     ctrlStr = ctl.Substring(0,ctl.Length-2);
     c= page.FindControl(ctrlStr);
    }
    else{
     c = page.FindControl(ctl);
    }
          if (c is System.Web.UI.WebControls.Button || 
		c is System.Web.UI.WebControls.ImageButton){
     control = c;
     break;
    }
   }
  }
  return control;
 }
  private void InitializeComponent(){
   this.components = new System.ComponentModel.Container();
  }
 }
}

Its a static method – which means you can reference it without a class instance, simply by calling Global.GetPostBackControl(this), with the “this” being a reference to the Page class that you are in. Typically we would do this as follows, in the Page_Load event handler method:

private void Page_Load(object sender, System.EventArgs e){
if(IsPostBack)
Label1.Text=Global.GetPostBackControl(this).ID.ToString();
} 

source: ASP.NET: Which Control Posted Back?