1

I am working through a massive site I inherited that has a mixture of classic ASP, inline ASP.NET and compiled ASP.NET and all of those utilize #INCLUDE tags in some form. I've been playing with IIS and rewrites/rewrite maps and seem to have found a working solution to get requests to pages to redirect to new versions as I slowly convert this site into a usable solution, however any page that is requested as an #INCLUDE (as opposed to directly requested by a user) doesn't seem to honor rewrites or rewrite maps. If I visit the included page directly it rewrites as expected, but visiting a page that embeds the URL on an #INCLUDE does not.

I'm fairly certain I understand why this would happen (it's not being requested directly so rewrites/redirects don't come into play, just processing like a user control), so any recommendations for making this happen? Normally I'd say just fix the files that are utilizing the include to point to the new location, but the site has 4,221 web files scattered in hundreds of folders with over 1MM images mixed in. Searching for strings such as a filename in that mess takes forever so I'm trying to find something at a higher level that would handle this for me.

Thoughts?

Scott Salyer
  • 2,165
  • 7
  • 45
  • 82

1 Answers1

1

As you say: #INCLUDE is not a HTTP request, and therefore never touches URL Rewrite or its rewrite maps. The include process is carried out by the ASP interpreter internally.

You could perhaps solve this with virtual directories (depending on your exact requirements) as the ASP interpreter can include files contained within virtual directories. It's difficult to suggest exact solutions with the limited details you have shared.

Polynomial
  • 3,656
  • 23
  • 36
  • I wish that was an option, but since this is a 10+ year old site the include files are all over - some in the root, some in an includes folder, some in an "imagesv" folder - it's a mess. What other details would you be looking for? I'm new to includes so this is a little out of my realm. – Scott Salyer Feb 04 '14 at 15:55
  • @digitall To start with: what are the 'new versions of scripts' you are producing? Presumably you aren't planning on converting these 4,221 pages one at a time just to end up with an identical system with 4,221 files written in a different technology? Surely you aren't replacing the individual include files with new ASP classic includes? You haven't included much information about what your plan is or how you intend it to work as you slowly convert it so I'm finding it difficult to suggest anything specific. – Polynomial Feb 04 '14 at 16:31
  • @digitall But basically the answer is no. The only ways I know of for a #INCLUDE to find its file is via the file system or virtual directories. If the file cannot be found directly or indirectly in those ways you are going to have to find/replace the path names in all of the files. – Polynomial Feb 04 '14 at 16:35
  • The 4000+ pages in here include some with "_old" in the filename, "_backup", etc. We honestly have no idea what is and what isn't in use (though, if some of those are in use I wouldn't be surprised), plus the code is atrocious (keeping it nice here), plus all the mixtures of other things - it's a nightmare. So unfortunately I am upgrading one at a time to get this into a true, object oriented system. I was hoping to do some type of redirect for old includes that are upgraded, but I think that's out of the realm of possibilities currently. Thanks for the help though! – Scott Salyer Feb 04 '14 at 20:32
  • 1
    @digitall So you're upgrading it to a cleaner/leaner ASP classic version? I'm afraid if that's the case I think you're going to have to do it the hard way and rationalise things manually. Getting all the files on a fast SSD on a local machine and using a text editor with a powerful find/replace function that you're comfortable with sounds like your best bet to take the pain out of the process. Good luck! – Polynomial Feb 04 '14 at 22:04
  • Luckily I do have the SSD thing covered - my dev box has a RAID10 array of 6G SSDs that does really well :-) I think the manual option is safer though because there is just too much happening here that I don't know about. The upgrade is from classic ASP and old ASP.NET (1.0/1.1) to 4.5 - the existing site has a mixture of everything and no concept of using VS, TFS, etc. It's awful. Thanks for the help! – Scott Salyer Feb 04 '14 at 23:50