External Assembly accesing Session generates an error

[Guest]

I have a WebSite "App1" which has an external assembly "Lib1".

Inside this external assembly we have developed some classes that derive
from "System.Web.UI.Page". One of these pages is called "WebNotification".

In the WebSite "App1" we create an instance of "WebNotification", but when
this class tries to access some Session variables it generates the following
error:

Session state can only be used when enableSessionState is set to true,
either in a configuration file or in the Page directive. Please also make
sure that System.Web.SessionStateModule or a custom session state module is
included in the <configuration>\<system.web>\<httpModules> section in the
application configuration.

I have tried to write "EnableSessionState= true" in the web.config and even
in the <%page%> directive but the error is still there.

Why?
Is there any restriction about accesing Session variables from class defined
in an external library?
Is there anyway to avoid this?

 

[Cowboy \(Gregory A. Beamer\)]

Since you are most likely instantiating this class in code, you can create a
constructor or properties and pass the session magic to the page prior to
displaying it. Treat an external library like a black box and it will be
your friend.

You can also go down into the bowels and get the session state object and
pull that way, provided the class has the proper context at the point you
are attempting to get session items. You will have to pull session state
from application, which comes from context, which means you have to be far
enough into the process to have context for the application, but it should
be easy enough to do with some digging I do not have any sample code for
this and I do not consider this the better option.

I just recently dealt with some code where all sorts of magic was going on,
including pulling session variables and config items. It was a straight
library (not inherited from an ASP.NET object), so it was easier to get into
this madness (no blow ups). It was not discovered until the population of
variables was moved from config to the database. Since the config element
was now controlled by user configurable metadata (in the DB), it was removed
from the config file and boom. A few refactors later and the class no longer
reached outside of its domain (i.e., it was a black box used by a web app).
Long term benefit: You can switch to a windows GUI in the future without
having to tackle the madness.

Overall, I am not fond of compiled libraries that handle GUI bits, but I can
see where reusability might dictate this functionality. And, you might have
to pull things from config or session in these objects, as they cannot move
to other GUI types (i.e., they are tightly coupled to the web solution, no
matter what). If, however, you move to a model where there is a GUI facade
and the GUI bits only handle display (and perhaps basic validation), you
find there is less need to create pure GUI libraries as the work is all done
behind the scenes.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************

 

[Guest]

Thanks for your alternative solutuions, but I have already found what was
wrong.

We were trying to access the Session variable in the constructor of the
derived page in the library.

At this time, Session is not available, so we have move the code to the
onInit event and all works ok.

Anyway thanks again for your answer.