Classic ASP Intranet and New ASP.NET Applications

Question

We have an existing classic ASP intranet consisting of hundreds of pages. Its directory structure looks like this...

/root
    app_1
    app_2
    ...
    img
    js
    style

Obviously app_1 and so on have better names in the actual directory structure.

Even though the many applications have different behaviour, they are all part of the same intranet and therefore share a common look and feel by including stylesheets via /style, images via /img and client script via /js.

The trouble (for me at least) comes when I want to add an intranet application in ASP.NET.

Ultimately, I'd like this structure:

/root
    app_1
    app_2
    dotnetapp_1
    dotnetapp_2
    ...
    img
    js
    style

It seems to me that ASP.NET "applications" like to think of themselves as separate from everything around them (this may just be my comprehension of how they are). You create a new "project" in Visual Studio and it's like you have a new "root" a level below the actual root I want to use. It's like this new application is a thing, standing alone, with its own images and style and whatnot. However, I want it to be a sub-part of the existing intranet.

Ultimately I want to be able to make my whole classic ASP intranet the "root" and have ASP.NET "sub-applications" that can still access /style and /img and, I guess for ASP.NET I'll have /masterpages.

I've tried this before, but I think VS choked on the couple of hundred classic ASP pages that it added to the "project" when I made my existing intranet root directory the ASP.NET project root (via File->Open->Web Site). I'd be nice to edit my existing classic ASP intranet using VS 2008 SP1 (I currently use the excellent Notepad++) because I'd like to get more hands on with VS but I guess this isn't absolutely necessary.

I also tried treating each new ASP.NET application as an application in its own right, effectively making the /dotnetapp_1 directory the "root" of the application (again, via File->Open->Web Site in VS2008). However, VS then complained when I tried to reference /masterpages because it "belonged to another application." I think I kludged it by adding a virtual directory inside each ASP.NET directory that "pointed" to the root /masterpages but I'm not sure VS was able to happily provide WYSIWYG editing when I did this, as opposed to making a copy of the masterpage in every ASP.NET application I add to the intranet.

I'm also quite likely to visit the .NET MVC framework so please offer any answers with that framework in mind. I'm hoping "projects" aren't quite to important with MVC and that rather it's just a bunch of files that creates an application that contributes to the whole (that being the intranet).

So, the question is: How I can best add-on ASP.NET applications to an existing classic ASP intranet (I'm not concerned about the technicalities of session sharing between classic ASP and ASP.NET, only the structural layout of directories and projects) and be able to edit these separate applications in Visual Studio 2008 SP1 and yet have these application "related" to each other by a common, intranet look and feel*?

• Please don't just post the answer "use MasterPages." I appreciate MasterPages are .NET's method of sharing styles (and more probably) between related pages in the same application. I get that. What I'm looking for is the best method of adding ASP.NET applications into the existing intranet as smoothly as I can that makes editing each application simple and where each application can share (if possible) an intranet-common style.

Answer 1

One solution would be to use IIS Manager to configure the website (created for your ASP.NET app by Visual Studio) and add a virtual directory for each of the common folders so that (by the 'virtual' nature of the virtual directory) they will 'appear' to be in the same root folder as your ASP.NET app.

/root
  app_1
  app_2
  dotnetapp_1
    <virtual>img
    <virtual>js
  ...
  img
  js
  style

You can probably script IIS or edit an XML file if you need to do this in bulk, and I'm sure there must be an even more elegant way to do something similar that doesn't require to much mouse work!