C# on the Move

Tuesday, December 2, 2008

'Sys' is undefined -Ajax

You might receive the error 'Sys' is undefined
when running ASP.NET AJAX Web pages or trying to AJAX enable your exisitng Web Applicaitons.

This error occurs specifically when you try upgrading
your existing ASP.NET 2.0 Applications to AJAX by using the ASP.NET AJAX controls
like UpdatePanel, etc., The common cause for this error is that you havent
updated the Web.Config file of the application to enable the runtime understand
ASP.NET AJAX. Let me explain a little more.

When you install ASP.NET AJAX your Visual Studio
2005 gets the toolbox updated with ASP.NET AJAX Server side controls like ScriptManager,
ScriptManagerProxy, UpdatePanel, UpdateProgress etc., You already have your existing
ASP.NET 2.0 application pages and you can add ScriptManager, UpdatePanel and other
controls from Toolbox to your pages. When you run the page, you would get
'Sys' is undefined javascript error. The reason being that,
your web.config of the existing ASP.NET 2.0 application misses certain settings
that require to be added to make it understand the ASP.NET AJAX Server side controls
like UpdatePanel, UpdateProgress etc.,

To resolve the issue, I am providing herebelow the
steps:-

Open the Web.Config file and start adding the following
settings to the same:- (Forewarning: Modifying
Web.Config incorrectly makes your site inaccessible and I would suggest you take
a back up of your existing web.config file before making the following changes.
This article is intended for people with prior experience in dealing with web.config
file, settings etc., and if you arent very convenient working with the Web.Config
file, make your administrator or other experienced developers make these changes)

1. Below the <configuration>
tag, add the following settings:-

What we have done in this step is registering the
System.Web.Extensions namespace, the assembly and its various handlers that
are useful in handling AJAX for your ASP.NET 2.0 Application.

2. Then, below the <system.web>
add the following settings:-

In this step, we registered the tagprefix
of ASP for the ASP.NET AJAX Server controls like UpdatePanel so that we can use
the same <asp: prefix while using the same in your
pages. Ex.- <asp:UpdatePanel>

3. Then find the <compilation
debug="false" /> and you need to replace this line with the following
settings:-

This step enables compilation for your website and
adds the reference assembly for System.Web.Extensions.

4. Then below the compilation settings (above step),
add the following:-

What we have done here is to register the Http Handler
and specify that Web Services might be handled using Javascript (asynchronous callback)
as well as add the ScriptModule Http Module.

5. Then, after the </system.web>
end tag, add the following system.web.extensions settings:-

<system.web.extensions>

<scripting>

<webServices>













</webServices>



</scripting>

</system.web.extensions>

In this step, we have additional steps where we
can play with JSON Serialization settings and enabling some of the Application Services
like AuthenticationService, ProfileService etc.,

6. Thereafter, add the following system.webServer
settings:-

<system.webServer>

<validation validateIntegratedModeConfiguration="false"/>

<modules>

<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

</modules>

<handlers>

<remove name="WebServiceHandlerFactory-Integrated"/>

<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd"
preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

</handlers>

</system.webServer>

The above steps registers the ScriptHandlerFactory
for Webservices and the AXD that needs to handle the requests.

Once you have added the above steps to your web.config
file, you would be able to add ScriptManager, UpdatePanel and other ASP.NET AJAX
Controls and would be able to run the page. This should solve the 'Sys' is
undefined error message.

These settings are not required if you are creating
a "File - New - AJAX Enabled Website" using Visual Studio 2005
since all the above settings are added automatically to your web.config file.

Similarly, with Visual Studio "Orcas" any ASP.NET
Website created will automatically have these settings as a part of the web.config
file enabling you to directly use the ASP.NET AJAX Server side controls as well
as the client scripts.

This error may also occur, if you are running beta
versions of ASP.NET AJAX such as RC1, and earlier CTP versions. I would strongly
suggest you to upgrade to the released version of ASP.NET AJAX which can be downloaded
from http://ajax.asp.net and update / modify your web.config files accordingly.

Finally, this error occurs due to the fact that
'Sys' is the root namespace for Microsoft AJAX Library and the web.config settings
specify the Handlers / Modules and the System.Web.Extensions DLL references so that
the runtime can understand and render accordingly.

Monday, October 6, 2008

Getting Client's IP in ASP.NET

ASP .Net web page:

Dim strClientIP As String
strClientIP = Request.UserHostAddress()
Response.Write(strClientIP)

ASP .NET web services:

Context.Request.ServerVariables ["REMOTE_ADDR"]

string ip;

ip=Request.ServerVariables("HTTP_X_FORWARDED_FOR");
if(ip==string.Empty)
{
ip=Request.ServerVariables("REMOTE_ADDR");
}

REMOTE_ADDR does not always provide the users IP but rather the ISPs' IP address so first test HTTP_X_FORWARDED_FOR as this one is the real user IP.

Friday, April 11, 2008

ASP.NET Page Life Cycle Overview

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend. Additionally, if you develop custom controls, you must be familiar with the page life cycle in order to correctly initialize controls, populate control properties with view-state data, and run any control behavior code. (The life cycle of a control is based on the page life cycle, but the page raises more events for a control than are available for an ASP.NET page alone.)

General Page Life-cycle Stages

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 5.0 and 6.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 UICultureproperty 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.

Life-cycle Events

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code.

Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true (or if it is not defined, since by default it is true), page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init. For more information on automatic event wire-up, see ASP.NET Web Server Control Event Model.

The following table lists the page life-cycle events that you will use most frequently. There are more events than those listed; however, they are not used for most page processing scenarios. Instead, they are primarily used by server controls on the ASP.NET Web page to initialize and render themselves. If you want to write your own ASP.NET server controls, you need to understand more about these stages. For information about creating custom controls, see Developing Custom ASP.NET Server Controls.

Page Event

Typical Use

PreInit

Use this event for the following:

Check the IsPostBack property to determine whether this is the first time the page is being processed.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.

Read or set profile property values.

Note:
If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

Init

Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties.

InitComplete

Raised by the Page object. Use this event for processing tasks that require all initialization be complete.

PreLoad

Use this event if you need to perform processing on your page or control before the Load event.

After the Page raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.

Load

The Page calls the OnLoad event method on the Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded.

Use the OnLoad event method to set properties in controls and establish database connections.

Control events

Use these events to handle specific control events, such as a Button control's Click event or a TextBox control'sTextChanged event.

Note:
In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.

LoadComplete

Use this event for tasks that require that all other controls on the page be loaded.

PreRender

Before this event occurs:

The Page object calls EnsureChildControls for each control and for the page.
Each data bound control whose DataSourceID property is set calls its DataBind method. For more information, see Data Binding Events for Data-Bound Controls later in this topic.

The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.

SaveStateComplete

Before this event occurs, ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.

Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.

Render

This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup that is sent to the browser.

If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. For more information, see Developing Custom ASP.NET Server Controls.

A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.

Unload

This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections.

For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks.

Note:
During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

Additional Page Life Cycle Considerations

Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events.

Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Loadevents for its child controls (top-down).

You can customize the appearance or content of a control by handling the events for the control, such as the Click event for the Button control and theSelectedIndexChanged event for the ListBox control. Under some circumstances, you might also handle a control's DataBinding or DataBound events. For more information, see the class reference topics for individual controls and Developing Custom ASP.NET Server Controls.

When inheriting a class from the Page class, in addition to handling events raised by the page, you can override methods from the page's base class. For example, you can override the page's InitializeCulture method to dynamically set culture information. Note that when creating an event handler using thePage_event syntax, the base implementation is implicitly called and therefore you do not need to call it in your method. For example, the base page class's OnLoad method is always called, whether you create a Page_Load method or not. However, if you override the page OnLoad method with theoverride keyword (Overrides in Visual Basic), you must explicitly call the base method. For example, if you override the OnLoad method on the page, you must call base.Load (MyBase.Load in Visual Basic) in order for the base implementation to be run.

Catch-up Events for Added Controls

If controls are created dynamically at run time or are authored declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to theControls collection.

In general, you do not need to be concerned about this unless you have nested data-bound controls. If a child control has been data bound, but its container control has not yet been data bound, the data in the child control and the data in its container control can be out of sync. This is true particularly if the data in the child control performs processing based on a data-bound value in the container control.

For example, suppose you have a GridView that displays a company record in each row along with a list of the company officers in a ListBox control. To fill the list of officers, you would bind the ListBox control to a data source control (such as SqlDataSource) that retrieves the company officer data using the CompanyID in a query.

If the ListBox control's data-binding properties, such as DataSourceID and DataMember, are set declaratively, the ListBox control will try to bind to its data source during the containing row's DataBinding event. However, the CompanyID field of the row does not contain a value until the GridView control'sRowDataBound event occurs. In this case, the child control (the ListBox control) is bound before the containing control (the GridView control) is bound, so their data-binding stages are out of sync.

To avoid this condition, put the data source control for the ListBox control in the same template item as the ListBox control itself, and do not set the data binding properties of the ListBox declaratively. Instead, set them programmatically at run time during the RowDataBound event, so that the ListBoxcontrol does not bind to its data until the CompanyID information is available.

For more information, see Binding to Data Using a Data Source Control.

Data Binding Events for Data-Bound Controls

To help you understand the relationship between the page life cycle and data binding events, the following table lists data-related events in data-bound controls such as the GridView, DetailsView, and FormView controls.

Control Event	Typical Use
DataBinding	This event is raised by data-bound controls before the PreRender event of the containing control (or of the Page object) and marks the beginning of binding the control to the data. Use this event to manually open database connections, if required. (The data source controls often make this unnecessary.)
RowCreated (GridView only) or ItemCreated(DataList, DetailsView, SiteMapPath, DataGrid,FormView, Repeater, and ListView controls)	Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.
RowDataBound (GridView only) or ItemDataBound(DataList, SiteMapPath, DataGrid, Repeater, andListView controls)	When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls for displaying related data within the row or item.
DataBound	This event marks the end of data-binding operations in a data-bound control. In aGridView control, data binding is complete for all rows and any child controls. Use this event to format data bound content or to initiate data binding in other controls that depend on values from the current control's content. (For details, see "Catch-up Events for Added Controls" earlier in this topic.)

The Login control can use settings in the Web.config file to manage membership authentication automatically. However, if your application requires you to customize how the control works, or if you want to understand how Login control events relate to the page life cycle, you can use the events listed in the following table.

Control Event	Typical Use
LoggingIn	This event is raised during a postback, after the page's LoadComplete event has occurred. It marks the beginning of the login process. Use this event for tasks that must occur prior to beginning the authentication process.
Authenticate	This event is raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.
LoggedIn	This event is raised after the user name and password have been authenticated. Use this event to redirect to another page or to dynamically set the text in the control. This event does not occur if there is an error or if authentication fails.
LoginError	This event is raised if authentication was not successful. Use this event to set text in the control that explains the problem or to direct the user to a different page.

C# on the Move

Tuesday, December 2, 2008

'Sys' is undefined -Ajax

Monday, October 6, 2008

Getting Client's IP in ASP.NET

Friday, April 11, 2008

ASP.NET Page Life Cycle Overview

Catch-up Events for Added Controls

More Blogs

Blog Archive

About Me

Found Useful?