How to share session/Application State Processing SS different ASP. NET web applications

How to share session/Application State Processing SS different ASP. NET web applications

By jayram tallamraju

This article gives the details of how to share single application/session state when SS different ASP. net web application projects developed. this is required for Web applications developed separately for the sake of modularity and require integration into a single website at a later stage.

It is better to develop each module independent of other. if there is information that needs to be shared between SS modules, it can be achieved through database and/or session/Application variables, depending on the requirements. with Visual Studio, each new ASP. net web application project creates a new virtual directory. this means creating separate session/application state for each module/application. drawback of this approach is there is no way to share same session/application processing SS these different modules developed for same website.

Well, it is not a drawback if each module is truly a web application by itself and not part of single website or does not share any thing in common. but what happens when it comes to simple things like login? Mostly applications developed for single website are required to support single sign on (SSO) or share/check some session/Application variables.

Most of the cases, each module is created as web application, just to allow multiple teams to develop different functionality in parallel, and when it comes to deployment, each module is expected to be part of one single application. sharing Single login session when SS different modules without much programming effort is the goal of this article.

To allow isolated development of each module and integrate all the modules into single web site, you can do the following:

Develop modules independently:

Create each module as new ASP.. NET web application (using Visual Studio ). it is possible that each module might be developed in different location or by different team. having independent standalone projects make testing of each module easy.

At this point in development phase, each module will have its own virtual directory and it is fine. focus at this point is developing and testing the functionality of module itself. but things will change at the time of integration and deployment.

Integrating different ASP. NET web applications:

When it is time to integrate different modules into single application:

2. Using Administrative Tools->Internet Services Manager: delete all virtual directories previusly created for each module by Visual Studio. NET.
4. Create new ASP. NET web application (ex: masterweb) project.
6. Open explorer and copy each module project directory, below masterweb project directory.
8. In each module project directory, open "<moduleprojectname>. csproj. webinfo" File
10. Modify urlpath value in. Csproj. webinfoFile:

    <Web urlpath = http: // localhost/masterweb/<moduleprojectname>. csproj "/>

    Why?Since there is no virtual directory created for each module, Module project file shocould have right URL so that Visual Studio can open and compile the project.

12. OpenWeb. configFile and remove all sections<Deleetask>Section (you can move required sections to parent directoryWeb. configFile ).Web. configIn parent directory of this project will have the common settings required for all modules. Any module specific settings can be overridden inWeb. configFile in Module project directory (ex:<Appsettings>/connectionstringValue in may be different for each module ).
14. Make sure that each module. Csproj. webinfoFile has changes inStep 5.
16. Make sure thatWeb. configFile in parent directory (masterweb) has all the correct settings required for all modules.
18. Make sure that each module hasWeb. configFile with module specific settings in<Deleetask>Section. If module does not require module specific data, it can share common configuration from parent application (masterweb ).
20. Delete anyGlobal. asax* Files from each module.
22. Rebuild all modules and make sure that all module project output assembly files are stored under<Masterweb>/binDirectory (Ref:Step 2).

Integration testing:

Run the main masterweb application and fromHttp: // machinename/masterwebAnd access each moduleHttp: // machinename/masterweb/module1/Module specific directories.

Note: All above changes shoshould allow having single session/application should SS different modules. this will allow development of each module separately and integrating them at a later stage. once deployed, this approach takes less memory as same session/application state is used every SS all modules. solution described takes: "same but different" approach during development phase and "different but same" approach during integration/deployment phase.

Debugging the website:

Open masterweb application project in Visual Studio and add all the module projects from sub-directories (add-> existing projects ). save this into single solution on Visual Studio. you can compile/debug individual projects or all of them as you prefer.

Assumptions:

It assumed in this article that, most of. net/asp. NET development is done using Microsoft Visual Studio. net (IDE) and readers are familiar with Visual Studio. net/asp. net.

Placeholders in the document:

"<", ">" Brackets in the document represent that actual name shocould be replaced in place of the string enclosed with "<> ". example: "<machinename>" shocould be replaced with actual machine name like "localhost" etc.