Session state with web services

 The extra trick needed is on the caller side.  You have to save and store the cookies used by the web service. 

If an XML Web service method uses session state, then a cookie is passed back in the response headers to the XML Web service client that uniquely identifies the session for that XML Web service client. In order for an XML Web service to maintain session state for a client, the client must persist the cookie. Clients can receive the HTTP cookie by creating a new instance of CookieContainer and assigning that to the CookieContainer property of the proxy class before calling the XML Web service method. If you need to maintain session state beyond when the proxy class instance goes out of scope, the client must persist the HTTP cookie between calls to the XML Web service. For instance, a Web Forms client can persist the HTTP cookie by saving the CookieContainer in its own session state. Because not all XML Web services use session state and thus clients are not always required to use theCookieContainer property of a client proxy, the documentation for the XML Web service should state whether session state is used.

See the MSDN documentation on HttpWebClientProtocol.CookieContainer property. 

However, please note if you’re using proxy object to call a web service from your page, the web service and your page cannot share the same session state due to architecture limitation. 

This can be done if you call your web service through redirect. 

Example:

    public class UseWebServiceWithSessionState
    {
        public static void Example()
        {
            // Create a new instance of a proxy class for your XML Web service.
            WebServiceInstance ws = new WebServiceInstance();
            CookieContainer cookieJar;
 
            // Check to see if the cookies have already been saved for this session.
            if (Session["CookieJar"] == null)
                cookieJar = new CookieContainer();
            else
                cookieJar = (CookieContainer)Session["CookieJar"];
 
            // Assign the CookieContainer to the proxy class.
            ws.CookieContainer = cookieJar;
 
            // Invoke an XML Web service method that uses session state and thus cookies.
            int count = ws.PerSessionServiceUsage();
 
            // Store the cookies received in the session state for future retrieval by this session.
            Session["CookieJar"] = cookieJar;
 
            // Populate the text box with the rewslts from the call to the XML Web service method.
            Logger.Log(count.ToString());
        }
 
    }
more info about HttpWebClientProtocol:
http://msdn.microsoft.com/en-us/library/system.web.services.protocols.httpwebclientprotocol(VS.71).aspx

Session_End is not fired

Remarkable Question :
1. Remember Session_End event is supported only in InProc mode.  
2. Session_End won’t be fired if you close your browser. HTTP is a stateless protocol, and the server has no way to know if your browser has closed or not. 
3. Session_End will be fired only (i) after n minutes of inactivity (n = timeout value), or (ii) if someone calls Session.Abandon(). 
4. For case (i) (pt. 3), Session_End will be run by a background thread, which implies:

    a. Your code in Session_End is running using the worker process account. You may have permission problem if you’re accessing resource such as database.
    b. If an error happens in Session_End, it will fail silently.
5. For case (ii), please note that in order for Session_End to be fired, your session state has to exist first.  That means you have to store some data in the session state and has completed at least one request.  
6. Again for case (ii), Session_End will be called only if the abandoned session is actually found. As a result, if you create and abandon a session inside the same request, because the session hasn’t been saved and thus can’t be found, Session_End won’t be called.  This is a bug in v1 and upcoming v1.1.

Disable stop deny web.config inheritance

I find a good article about Configuration Inheritance below:

Each ASP.NET Web Application has its own configuration file called web.config file. 
In fact every directory in ASP.NET application can have one. Settings in each web.config file apply to the pages in the directory where its placed, and all the subdirectories of that directory.This is called 

Configuration Inheritance. 

So if you create an ASP.NET application and set its web.config file, add custom HttpHandlers, UrlRewriting module etc and try to create another ASP.NET Web Application in the subfolder, you can end up having problems because application in the subfolder will inherit all the settings from its parent  web.config.

So if you for example setup UrlRewriter module in your root web applications like this:

      <httpModules>

        <add name=”UrlRewriteModule” type=”UrlRewritingNet.Web.UrlRewriteModule, UrlRewritingNet.UrlRewriter”/>

        <add name=”ScriptModule” type=”System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″/>

      </httpModules>

And in your child web application (in subfolder) you are not using UrlRewriteModule, then if you try to run the child Web Application in your browser, you will get error like this:

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. 
Line 88: <httpModules>
Line 89:   <add name="UrlRewriteModule" type="UrlRewritingNet.Web.UrlRewriteModule, UrlRewritingNet.UrlRewriter"/>
Line 90:   <add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
Line 91: </httpModules>

Luckily, there is a easy solution to this problem.

Source Error: 
What happens here is that because UrlRewriteModule is configured in the parent’s folder web.config file, this setting is inherited by the child application’s web.config file, and because of this ASP.NET is looking for the UrlRewriteModule DLL file in the BIN directory, and off course its not there.

First thing you can do is to remove the problematic HttpModule in your child application web.config file using the removecommand like this:

      <httpModules>

        <remove name=”UrlRewriteModule” />

      </httpModules>

This would remove the handler and your application would run fine.
Or you could use <clear/> command like this:

      <httpModules>

        <clear/>

      </httpModules>

This would clear all the HttpModules in your child application.

But what to do when there are many settings in your root web.config file that you don’t want to be propagated to your child applications?

Here is the solution:
With the <location> attribute with inheritInChildApplications set to false in your root web.config file you can restrict configuration inheritance. 
So, by wrapping a section of your web.config file in <location> attribute you can instruct ASP.NET not to inherit those settings to child applications/folders and their web.config files.

In fact  you can wrap the whole <system.web> section in one <location> attribute and disable configuration inheritance so none of the parent settings from <system.web> will be inherited to the child applications you create in subfolders.

Here is how to use this in practice:

  <location path=”.” inheritInChildApplications=”false”>

    <system.web>
    …

    </system.web>   
  </location>

NOTE: Do remember that if you do this, you need to manually insert all the settings you need in the <system.web> for your child applications because none of the settings from the root web.config will be propagated…

Source:
http://www.aspdotnetfaq.com/Faq/how-to-disable-web-config-inheritance-for-child-applications-in-subfolders-in-asp-net.aspx

Two kind of Garbage Collector

when working on client machine you can use server type garbage collector.But it uses more memory.By default in server OS uses Server type garbage collector. You can configure  in your web config like

<configuration>
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

The CLR has two different GCs: Workstation (mscorwks.dll) and Server (mscorsvr.dll). When running in Workstation mode, latency is more of a concern than space or efficiency. A server with multiple processors and clients connected over a network can afford some latency, but throughput is now a top priority. Rather than shoehorn both of these scenarios into a single GC scheme, Microsoft has included two garbage collectors that are tailored to each situation.

Server GC:

  • Multiprocessor (MP) Scalable, Parallel
  • One GC thread per CPU
  • Program paused during marking

Workstation GC:

  • Minimizes pauses by running concurrently during full collections

The server GC is designed for maximum throughput, and scales with very high performance. Memory fragmentation on servers is a much more severe problem than on workstations, making garbage collection an attractive proposition. In a uniprocessor scenario, both collectors work the same way: workstation mode, without concurrent collection. On an MP machine, the Workstation GC uses the second processor to run the collection concurrently, minimizing delays while diminishing throughput. The Server GC uses multiple heaps and collection threads to maximize throughput and scale better.

Source: MSDN

VML & SVG

Vector Markup Language (VML) is an open and standards-based XML language used to producevector graphics.

VML was submitted as a proposed standard to the W3C in 1998 by AutodeskHewlett-Packard,MacromediaMicrosoft, and Visio.[1]

Around the same time other competing W3C submissions were received in the area of web vector graphics, such as PGML from Adobe SystemsSun Microsystems, and others.[2] As a result of these submissions, a new W3C working group was created, which produced SVG.

While Microsoft continues to document VML,[3] development of the format ceased in 1998.[4] VML is implemented in Internet Explorer 5.0 and higher and in Microsoft Office 2000 and higher. Google Mapscurrently uses VML to make vector paths work when running on Internet Explorer 5.5+, and SVG on all other browsers.[5]

The Vector Markup Language is now specified in Part 4 of the Office Open XML standards ISO/IEC29500:2008 and ECMA-376.[6][7]

Scalable Vector Graphics (SVG) is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic (i.e. interactive or animated).

The SVG specification is an open standard that has been under development by the World Wide Web Consortium (W3C) since 1999.

SVG images and their behaviours are defined in XML text files. This means that they can be searched, indexed, scripted and, if required, compressed. Since they are XML files, SVG images can be created and edited with any text editor, but specialized SVG-based drawing programs are also available.

All major modern web browsers except Microsoft Internet Explorer support and render SVG markup directly.[3] To view SVG files in Internet Explorer, either users have to download and install a browser plugin, or the webmaster can include SVG Web, a JavaScript library currently under development atGoogle Code[4].

SVG is also well-suited to small and mobile devices. The SVG Basic and SVG Tiny specifications were developed with just such uses in mind and many current mobile devices support them.

Source : wikipedia