So, before you ask "what the heck do you mean, one is nested within the other?" I'll explain it as simply as I can.
A .NET web application (A) existed. A supplementary application (B) was built that works off several of the same core assemblies. A previous consulting company had somehow "installed" application B within application A so that B could piggyback off of A's session. So, something like this:
- Application A (C:\Inetpub\wwwroot\ApplicationA)
+ Application B (C:\Inetpub\wwwroot\ApplicationA\sup\ApplicationB
The previous company left zero documentation on how or why they did this, but it worked for them. My dilemma is now this: Application A was upgraded, rendering B useless. I updated B to run off the new core provided by A, but by the time I was finished, another team had decimated the previous production and test servers and I can't get a backup to see how it was configured.
After a bunch of futsing around, I was able to replicate the hierarchy above within a single IIS application and pool by chopping apart the web.config file for B and removing the duplicate sections -- the ones that already existed in A's web.config. I also dumped all of the files from B's bin folder into A's bin folder.
Both sites compile and are served by IIS, but I cannot read anything out of A's session using this structure. I'm not surprised by that result, but I need to find a workaround. In short, A has a sessionID stored in its session that I need to use to obtain a datasource in B, due to some crazy licensing rules imposed by the creators of A (that sessionID needs to be passed to each function in their core API for user authorization).
Any ideas on why the functionality no longer works (assuming I've replicated the old environment correctly), or how I could work around it? Moving to a SQL server for session state is not an option -- I cannot change anything about application A.
I've looked a little bit at A's code (as much as I dare with Reflector), and the variable that I'm trying to retrieve from the session is still there and being used.
Any thoughts would be great!
Since they are two separate applications, they (obviously) have two different session scopes. You could have a session in one but not the other, and the session in A could expire before the session in B, forcing A to create a new session while B is still using the old one. There's nothing linking A to B or vice-versa, so logically there's no straighforward way they even could share objects, as there's no meaningful correlation between them.
The short of it is - you can't (easily) directly share session to session data between two different applications. A frequent solution for this problem is to pass a common ID between the two applications via querystring or cookie (if they are on the same domain), and both use that ID to refer back to a common record in a database they can both access. From that point information can be shared via the database.