Reputation: 17919
We have to maintain a lot of classic ASP and VB/ASP.Net applications that link to many different parts of a static website.
The master pages are littered with various
<!-- #include virtual="/site/footer.something" -->
and similar, where there are many many combinations of what /site/ can be.
The problem is, when you're debugging etc. when you try to run one of these sites locally, you're almost guaranteed to get a parser error.
What I want to do is come up with a generic handler so that I can just insert a blank file for any #include file that doesn't exist. I tried to setup a URL Rewrite rule, which works in the browser (just redirects to an empty html file) but I'm guessing the ASP parser doesn't include as a webrequest as it still generates a parser error.
I don't want to have to copy the static content to my workstation everytime I open a new app and I don't want to edit the master pages to exclude the links as one day I'm just going to forget and deploy something broken.
So the question is, is there a way to serve a default file for these declarations, or some other method ?
Edit: To consider a different fix to this problem; is there some way to insert some kind of file-system handler that can pick up requests for missing files in specific locations and return predefined content ? Yeah, I know that's a really offbeat direction and probably a very bad idea in practise, but this is quite a frustrating problem in the office now. What's irritating is that even though IIS has SSI disabled, the ASP processer still honours #include directives. Is there a way to either disable that, or perhaps some way to override the behaviour in some kind of generated class ?
Upvotes: 0
Views: 174
Reputation: 5518
The problem you will encounter is that includes are processed before any of your code runs. The server gathers all of the resources referenced in the scripts then compiles and runs your code. By the time your code is running, the missing include has already thrown a compiler error.
Further, what you're asking could potentially run into other problems. Often times includes contain code (procedures, constants, variable declarations, etc.) that other scripts rely on. So, even if you were to replace the missing include with an empty file, you still may encounter other parser errors if the including script expects that include to contain specific code.
Probably your best bet is to make a console app or something similar that parses your files looking for the include statements, resolves the relative path based on your directory structure and does what you want - write an empty file if it doesn't exist. You could then run your projects through this parser and at least eliminate that issue.
Additionally, you mention the possibility of accidentally deploying something that you've edited to circumvent this problem. I would assume then, that if you were to write out these "dummy" includes, there is no possibility of you accidentally deploying them and overwriting good files?
Upvotes: 2