views:

23

answers:

1

Hi,

We have a legacy system which is build in classic ASP. As we move to asp.net, we find ourselves creating web applications as we migrate old stuff to .net and add new functionalities to the system. I would say maybe 30% of them would share the same library, loading the same dlls. (all applications share the same app pool)

My question would be, what's the pros and cons of this approach? Would it be better to have one application root?

I am not really looking for a specific answer, just curious what you people do usually and why?

thanks a lot

A: 

I would place things that can be logically grouped together into its own app pool. Example: Components needed for a website or webapp under IIS could be considered a single logical group, therefore it needs its own app pool.

Anything else that is separate should have its own domain with own app pool. But, IMHO, i think it's a judgment call based on the nature of the app and if it has any dependencies... etc. You know the system better than anybody, so from a 20k foot view of it all, how should things be logically separted?

Example scenario: If you have an app that needs to be reset via IIS, will it affect others (will others go down due to the one app that requires an IIS reset)? If it's not a big deal, then why not (lump it together with the other). If it is a big deal, then keep it separate so it's not dependent on any externals.

AlvinfromDiaspar