Want to confirm: is it OK to put more than 1 assemblies into oneIIS application

[Edward Yang]

In my test, I have two web applications app1 and app2, and I configure
them as follows in IIS:

$/comboapps
|--web.config
|--bin
| app1.dll
| app2.dll
|--app1
| form1.aspx
| web.config
|--app2
| form1.aspx
| web.config

(Of course, I have to remove authentication, authorization, sessionstate
tags from web.config in app1 and app2.)

In this way both apps share the same session because they are in one IIS
application.

Things work well for me so far. But I have some uncertainties:

1. What should I do with each global.asax file in app1 and app2?

2. Is this method supported by Microsoft (I can't draw a conclusion by
reading documentation)?

3. What is the logic of Configuration.AppSettings("somename") in the
above scenario? Does the Framework check the web.config in app root first?

Great thanks if someone can sort my head out for a bit.

 

[Scott Allen]

Hi Edward:

Yes, this scenario is supported. All calls to Configuration.AppSettings will
pull from the web.config in the root directory. Code inside of global.asax
should be migrated to the root directory as well, but not seeing the code
makes it a little difficult to say with 100% certainty.

 

[Juan T. Llibre]

Hi, Edward.

Scott addressed some of your concerns.
Here's a couple of precisions.

re
1. What should I do with each global.asax file in app1 and app2?

The global.asax files in /app1 and /app2 won't execute.

Only the global.asax in /comboapps will execute,
provided /comboapps has been declared as an Application.

For the global.asax files in /app1 and /app2 to execute,
you'd have to declare those directories as Applications,
which runs contrary to your current strategy.

Also, nesting Applications may bring quirky results,
with different global.asax's having execution precedence,
depending on which Application was *first visited* by the client.

rre:

3. What is the logic of Configuration.AppSettings("somename") in the above
scenario? Does the Framework check the web.config in app root first?

ASP.NET will check all web.configs (in the subdirectory where
a file is executing and in any web.config located up the Application's
directory hierarchy ).

If the appSetting key value is found in the web.config located in the
subdirectory ( /app1 and app2 in this case ), it will retrieve that value.

If the value is found in the web.config in the Application's root,
then *that* value will be retrieved.

It doesn't matter in which web.config you place your appSetting keys.

Depending on the way you organize your code, it might be worthwhile
for all appSettings to be in the root's web.config, or it may be worthwhile
for specific directory-only appSettings to be located in the subdirectory.

It's up to you.
Retrieving appSettings will work in any web.config within your Application.

Good luck!


Juan T. Llibre
ASP.NET MVP
===========

 

[Juan T. Llibre]

I should have added, allthough it may be clear enough,
that the search for appSetting configuration only works
*up* the directory hierarchy, and not the other way around.

i.e., if you're executing a file in /app1 which tries to retrieve
a value for an appSettings key, ASP.NET will look first
in the web.config in /app1, and if it's not found, it will look
for the value in any web.configs up the directory hierarchy,
until it gets to the Application root.

OTOH, if you execute a file in the Application's root, which tries
to retrieve a value for an appSettings key, if the appSettings key
is not in the web.config in the root, the web.config in /app1
will *not* be searched.

I don't think that executing a file in /app1 will allow you to retrieve
appSetting keys from the web.config in /app2, either, as /app2 is
not higher in your directory hierarchy.

The reverse would also be true, I think.
( You can't retrieve /app1 web.config values from /app2 ).

I have tested all scenarios, except these last two
( from parallel subdirectories in the hierarchy).



Juan T. Llibre
ASP.NET MVP
===========

 

[Guest]

Thanks for everyone repying.

Have new thoughts here.

1. Comboapps actually does not have associated assembly; it's just an IIS
application. How can I have global.asax facilities?

2. If I have to create a very small assembly for the Comboapps, is there any
easy to debug the code in global.asax?

Thanks.

 

[Juan T. Llibre]

re:

1. Comboapps actually does not have associated
assembly; it's just an IIS application. How can I have
global.asax facilities?

You don't need to have an assembly in order to have an IIS Application.

If /comboapps is an IIS Application, it can use a global.asax.

re:

2. If I have to create a very small
assembly for the Comboapps

You don't have to.

Just make sure /comboapps is an IIS Application,
write a global.asax file in the app's roots dir, and
declare whatever you want to declare in it.

ASP.NET will recognize/execute it.




Juan T. Llibre
ASP.NET MVP
===========

 

[Guest]

re:

You don't need to have an assembly in order to have an IIS Application.

If /comboapps is an IIS Application, it can use a global.asax.

re:

You don't have to.

Just make sure /comboapps is an IIS Application,
write a global.asax file in the app's roots dir, and
declare whatever you want to declare in it.

ASP.NET will recognize/execute it.

Can I write code directly in global.asax, as what I can do in ASPX pages?

 

[Guest]

Don't bother. I find out how myself. I can write code directly in global.asax.