AutoEventWireup - Page Attribute

By default the ‘AutoEventWireup = true’. It means that without attaching the events of the Page (Init, Load, PreRender, UnLoad) with any Event Handler (Page_Init, Page_Loa etc), the event handlers are called automatically.

But in case of ‘AutoEventWireup = false’, to enable such event handlers to be fired, you’ll be required to bind the events with the event handler in the form tag as below.

<form id="form1" runat="server" onload="Page_Load" oninit=" Page_Init" onunload="Page_UnLoad">

Thanks & Regards,

Arun Manglick || Tech Lead |

Addition to the ViewState Myth

This is in addition to the post on Viewstate Myth in Apr 2007

In my last post, I have described the Viewstate Myth on ‘Change Of Values’ in controls.

Today I’m posting the conclusion of viewstate myth on the Visibility and Enabling Disabling of controls.

After making research on above two forms below is the conclusion:

Visibility –

· All controls are dependent on Viewstate.

· So if the Viewstate is disabled, the controls will become visible again on 'SimplePostBack' operation.

Enable/Disable-

· All controls are dependent on Viewstate.

· So if the Viewstate is disabled, the controls will become enable again on 'SimplePostBack' operation.

Recap:

Changing Value –

· Textbox, HiddenField, Dropdown does not depend on ViewState.

· Label requires view state.

Thanks & Regards,

Arun Manglick || Tech Lead

Page Life Cycle and Control Loading

Page Life Cycle and Control Loading

Here in this article emphasis is on

§ How Page Loading along with the Control Hierarchy loading occurs hand in hand.

§ In which phase the controls are completely created & initialized with their Default values & Post back values.

§ How View state comes in picture.

· For this read the article ‘Myth regarding View State’

http://msdn2.microsoft.com/en-us/library/ms972976.aspx

For Digramatic View - http://arun-ts.blogspot.com/search/label/Diagrams

For View State Myth - http://arun-ts.blogspot.com/2007/04/myth-regarding-view-state_13.html

We’ll go thru below phases.

Stage 0 – Instantiation –

Creates The Page's Control Hierarchy & Assigns the decalrative properties to the Web Controls.

§ When the life cycle of the ASP.NET page begins, ASP.NET engine Instantiates an Auto-Generates Class that represents the requested ASP.NET Web page.

§ The purpose of this autogenerated class is to programmatically create the Page's Control Hierarchy. i.e Programmatically creating the Web controls specified in the page's HTML portion.

§ This is done by translating the HTML portion into a series of Programmatically-Created Web controls. i.e Translating—<asp:WebControlName Prop1="Value1" ... />—into the class's programming language.

§ In addition to the Web control syntax being converted into the appropriate code, the HTML markup present in the ASP.NET Web page's HTML portion is translated to Literal controls.

§ If you created your ASP.NET Web page using the code-behind technique, this autogenerated class is derived from the page's associated code-behind class [System.Web.Ui.Page].

§ In either case, this autogenerated class, along with a compiled instance of the class, is stored in the WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder, in part so that it Doesn't Need To Be Recreated for each page request.

§ When the control hierarchy is constructed, the properties that are explicitly set in the declarative syntax of the Web control are assigned in the code.

Stage 1 – Initialization

§ After the control hierarchy has been built, in this the Page and its controls fire their Init events.

§ With regards to view state it is important for two reasons.

· First, server controls don't begin tracking view state changes until right at the end of the initialization stage.

· Second, when adding dynamic controls that need to utilize view state, these controls will need to be added during the Page's Init event as opposed to the Load event.

Stage 2 - Load View State

§ The load view state stage only happens when the page has been posted back.

§ During this stage, the view state data that had been saved from the previous page visit is loaded and recursively populated into the control hierarchy of the Page.

Stage 3 - Load Postback Data

§ The load postback data stage also only happens when the page has been posted back.

§ A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface

Stage 4 - Load

§ This is the stage with which all ASP.NET developers are familiar

Stage 5 - Raise Postback Event

§ There are two flavors of postback events.

· Changed event - DropDownLists SelectedIndexChanged event, or the TextBox's TextChanged event

· Raised event - Button Web control Click, Calendar control VisibleMonthChanged event

Stage 6 - Save View State

§ In the save view state stage, the Page class constructs the page's view state, which represents the state that must persist across postbacks.

Stage 7 - Render

§ In the render stage the HTML that is emitted to the client requesting the page is generated.

§ The Page class accomplishes this by recursively invoking the RenderControl() method of each of the controls in its hierarchy.

Thanks & Regards,

Arun Manglick || Tech Lead

Asynchronous Events

We know about Asynchronous Delegates.

 

e.g

 

delegate string DownloadString (string uri);

DownloadString download1 = new DownloadString(Print);

IAsyncResult cookie1 = download1.BeginInvoke (uri1, null, null);

string s1 = download1.EndInvoke (cookie1);

 

 

public string Print(string url)

{

          Return “”;

}

 

 

Similar to Asynchronous Delegates, there are Asynchronous Events.

This is called the "event-based asynchronous pattern" and is distinguished by a method whose name ends with "Async", and a corresponding event whose name ends in "Completed".

 

So for above example – There would be DownloadStringAsync method. To use it, you first handle the "Completed" event (e.g. DownloadStringCompleted) and then call the "Async" method (e.g. DownloadStringAsync).

 

When the method finishes, it calls your event handler.

 

The event-based pattern also offers events for progress reporting and cancellation, designed to be friendly with Windows applications that update forms and controls. If you need these features in a type that doesn't support the event-based asynchronous model (or doesn't support it correctly!) you don't have to take on the burden of implementing the pattern yourself, however (and you wouldn't want to!) All of this can be achieved more simply with the BackgroundWorker helper class.

 

Info Card:

Windows CardSpace, formerly codenamed “InfoCard”,  is a piece of client software, that enables users to provide their digital identity to online services in a simple, secure and trusted way.

It is what is known as an identity selector:  when a user - or subject - needs to authenticate to a website or a web service, CardSpace pops up a special security-hardened UI with a set of “cards”  for the user to choose from. Each card has some identity data associated with it - though this is not actually stored in the card - and has been given to the user by an identity provider such as their bank, employer or government. In fact, the user can also act as an identity provider - this is essentially what we do every time we register at a website. The CardSpace UI enables users to create Personal cards and associate a limited set of identity data. When the user chooses a card, a request in the form of a web service call goes to the relevant provider, and a signed and encrypted security token is returned containing the required information (e.g. credit limit, employer’s name and address, or perhaps a social security number). The user, in control of the flow of information at all times, then decides whether to release this information to the requesting online service. If the user approves then the token is sent on to this relying party where the token is processed and the user is authenticated.

 

CardSpace is an implementation of an identity selector on Microsoft Windows. Other operating systems will see their own identity selector implementations.

 

The architecture upon which CardSpace has been built - consisting of subjects, identity providers and relying parties - is called “The Identity Metasystem”.

 

 This isn’t just a Microsoft initiative, but rather it is the shared vision of many across the industry as to how we can solve some of the fundamental identity challenges on the Internet today. The initial vision for the Identity Metasystem was developed by Microsoft’s Identity Architect, Kim Cameron, and has been broadly adopted and championed by thought-leaders such as Doc Searls and Lawrence Lessig. To learn more about the metasystem and the guiding principles behind it (“The Laws of Identity”), refer to the whitepapers on MSDN and Kim’s blog, www.identityblog.com.

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

Globalization and Localization

Globalization and Localization

-------------------------------------------

Globalization is the process of designing your application so that it is possible later to have it translated and support multiple cultures. So, here you might not even actually make any translations but are making the application ready for it. Once you have globalized your application and now want to translate it into a specific culture, the translation process is called localization.

 

To globalize your application, the most important change to be done is that instead of hard-coding things such as display strings, move them to resource files. You then can set the control properties by reading the resource files. When you want to localize your application, have the resources translated to the languages you want to support. This will be covered in detail in this article.

 

The Difference Between Culture and Language

----------------------------------------------------------

Culture consists of language plus the country/region. Culture is usually denoted by a combination of a two-letter lowercase code (called culture code) denoting the language and a two-letter uppercase code (called sub-culture code) denoting the country or region. For example, "de-DE" for German in Germany and "de-AT" for German in Austria (even though the language is the same, they are different cultures!).

 

    Note: A neutral culture is a culture that is associated with a language but not with a country/region, for example, "de" for German.

 

Culture affects not only things like which language a particular string is shown but also things like the date format used, the decimal separator, currency symbol, and so on.

 

Culture and UICulture

-------------------------------

In ASP.NET, you can set to two culture values: the Culture and UICulture properties.

The Culture value determines things such as date, number, currency formatting, and so on. For example, it is the Culture setting that decides whether the date is in the dmy format or mdy format and what names to use for the month and for numeric values what the decimal separator is.

The UICulture value determines which resources are loaded for the page. So, it controls things like which translated text to show. In most cases, you will set Culture and UICulture to the same culture.

 

Culture is set at the thread level by setting the CurrentCulture and CurrentUICulture properties of the thread. You either can set it directly or ASP.NET will set it for you.

 

Setting in Three Ways:

------------------------------

 

1. Set it declaratively: In the web.config file or in the @Page directive in the page, you can specify the culture as shown:

 

web.config: <globalization uiCulture="es-MX" culture="en-US" />

@Page Directive: <%@ Page  UICulture="es-MX" Culture="es-MX" %>

 

2. From the client browser's language setting:

 

3. Set it programmatically: In most cases, you will need to give an explicit way on your Web site for the user to select their language of choice. In such cases, you need to set the culture programmatically. Set these in the InitializeCulture method for the page.

 

Thread.CurrentThread.CurrentCulture =

   CultureInfo.CreateSpecificCulture(selectedLanguage);

Thread.CurrentThread.CurrentUICulture =

   new CultureInfo(selectedLanguage);

 

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

How Serialization & De-Serialization works in General :

-------------------------------------------------------------------

I tell you how the customization of the serialization and deserialization works in general. At first, you need to implement the ISerializable interface. This interface contains a single method, named GetObjectData, which is responsible for storing object fields during the serialization process. To do this, you just need to populate a passed SerializationInfo object.

 

The deserialization process works exactly the other way round. When an object is being deserialized, the previously filled SerializationInfo object is passed to the constructor of your class in which you are responsible for restoring the original object fields.

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

Session State - Which Mode in which Scenario.

Session State – Which Mode in which Scenario… - Factors to choose between speed, reliability, security and scalability.

 

M.M.Imp:-

 

a)     

 

Remember never to use a Response.Redirect or Server.Transfer method call after you set the Session in the login page of your application.  

Both these methods call the Response.End method internally.  The Session ID would be lost as the Response.End method stops execution of the page.  

Use the FormsAuthentication.RedirectFromLoginPage method instead. Alternatively, you can use the following overloaded version of the Response.Redirect method.

 

Response.Redirect("~/menu.aspx", false)

 

This would not abort the current thread and would prevent the Session ID from being lost.

 

b).

Note that the Session state is available only after the HttpApplication.AcquireRequestState event is called.  The Session_End event is supported only in the InProc mode and is fired internally by the Web Server, based on an internal timer. Thus, there is no HttpRequest that is associated when that happens.  

This is why the methods Response.Redirect or Server.Transfer do not work in the Session_End event.  

The Session_OnEnd event is called when we make a call to the Session.Abandon method or when the Session times out.

------------------------------------------------------------------------------------

 

 ‘In Proc’:

 

[Definition]

·         Provides the fastest access to session state.

·         No serialization or marshaling costs involved because state is maintained within  the managed memory of the ASP.NET process.

·         When the process recycles, the state data is lost, although you can disable process recycling in IIS 6 if process recycling affects your application.

·         The in-process store limits application scalability because you cannot use it in conjunction with multiple worker processes; for example, it prevents Web farm or Web garden deployment.

·         In case of web-garden do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

·         It is the fastest of all the three modes.

·         The Session_End event is supported only in the InProc mode and is fired internally by the Web Server, based on an internal timer.

 

[When to use]

·         When you have a single Web server,

·         When you want optimum Session State Performance, and

·         When you have a reasonable and limited number of concurrent sessions.

·         In a production environment, the InProc mode of Session State storage is not feasible.  When we have to go for WebFarms, the OutProc mode is the best; especially when the traffic is heavy on the site.

------------------------------------------------------------------------------------

 

‘State Server’:

 

[Definition]

 

·         Can be installed on your local Web server or on a remote server that is accessible by all Web servers in a Web farm.

·         StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

·         This approach scales well, but performance is reduced in comparison to the in-process provider because of the additional serialization and marshaling that is required to transfer the state to and from the state store.

·         Session state is serialized and stored in memory in a separate process that is managed by the aspnet_state.exe file.

·         If your remote state service and your Web server are separated by a firewall, then you need to open a port. The default port is port 42424. You can change the port in the following registry key:

o    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters.

·         The new out-of-process model allows all servers in the farm to share a session state process. You can implement this by changing the ASP.NET configuration to point to a common server. 

 

 

[When to use]

 

·         When you have a single Web server and your sessions are expensive to rebuild and when you require durability in the event of an ASP.NET restart.

·         When you have a Web Farm.

·         Use a remote state service, if you do not have a SQL Server database.

 

------------------------------------------------------------------------------------

 

‘SQL Server’:

 

[Definition]

 

·         Provides a highly scalable and easily available solution.

·         Well-suited to large amounts of session state.

·         The serialization and marshalling costs are the same as the costs for the session state service, although overall performance is slightly lower.

·         SQL Server is more secure than the InProc or the State server modes of Session State storages as the data can be secured easily by configuring the SQL Server security.

·         SQL Server mode of storage is suited when we need to secure the Session data or when we require scalability and reliability, but it takes more time to store and retrieve data to and from the database table.

·         SQL Server provides Clustering For Failover, although this is not supported in the default configuration for session state. To enable clustering for failover, you have to apply configuration changes, and the session data must be stored in a non temporary table.

 

[When to use]

 

·         When you have a single Web server when reliability is your primary concern.

·         When you have a Web Farm.

·         Use SQL Server for enterprise applications or high volume Web applications.

·         Well-suited to large amounts of session state.

 

 

[Configuring SQL Server]

 

 

 

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

How Strong Names secures Shared assemblies.

Target Readers : Who are new to the ‘Shared Assemblies’. [Otherwise Skip]

Strong names:-

• A strong name is a name that guarantees an Assembly Identity.
• Consists of information about the assembly, such as its
• name,
• version number,
• any culture information, and
• the public key of a public/private key pair:- This information is encrypted with the private key of the key pair and can be decrypted with the public key of the key pair. Because no one but the developer has access to the private key, the strong name cannot be replicated by anyone but the developer, thereby ensuring the assembly identity.

 

About Key Pair:

 

·         Information is encrypted with the private key and decrypted with the public key of the key pair.

• The compiler writes the public key to the manifest, and signs the hash of all the files that belong to   Assembly with the private key.
• The private key is not stored within the assembly.

 

 

Referencing Shared Assemby

 

·         Now during Development when the Client Assembly references the shared assembly, the compiler writes the public key of the referenced assembly to the manifest of the client assembly. 

·         To reduce storage, it is not the public key that is written to the manifest of the client assembly, but a public key token (last eight bytes of public key).

·         At Runtime, during loading of the shared assembly the hash of the shared component assembly can be verified by using the public key stored inside the client assembly.

 

Ensured Security: 

 

·         In the Client Assembly, because no one has access to the private key, the strong name cannot be replicated by anyone but the developer, thereby ensuring the Assembly Identity.

 

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.