For ASP.NET web applications, typically each would live in its own virtual directory which serves as the application starting point.
Technically you could "piggy-back" two applications on the same application starting point in one of two ways:
- Put all the files for each application in the same directory (and appropriate sub directories)
If you don't have ANY files that overlap, you can get away with this. Of course, it's likely that you won't with such files as the default or index pages, etc. And this would be pretty messy anyway.
- Put all the non-binary files for each app in an appropriate subdirectory and the binaries in the main virtual's \bin directory.
You'll be able to do this only if each application's binary files don't overlap by name AND there are no namespace ambiguity conflicts between assemblies (two different assemblies by file name, but with the same namespace). The latter is much less likely to happen if you are trying to piggy-back two different applications.
The big problem I see with the latter solution is that any parts of the application that make use of application root references will break. When some code tries to resolve a reference to some resource (like an image) based on an application root reference such as
~/images/logo.gif
the ~ will get resolved to the virtual directory, but will not include the additional (non-virtual and non-app starting point) subdirectory in which the application lives. So instead of this:
/vd1/app1/images/logo.gif
you'll end up with this:
/vd1/images/logo.gif
Obviously, that won't work.
So... you won't break either app if you can put them both in the same virtual directory, however, you'll have to check for file conflicts and such. Possible namespace conflicts will be unavoidable without separate application starting points.