I have an ASP.NET master page which references a #include file as follows:
<!--#include virtual="/includes/scripts.inc"-->
I have modified the file /includes/scripts.inc but the changes do not show up in pages.
What needs to be done so modifications will be reflected?
I need to avoid the following:
restarting the server
restarting IIS
modifying web.config (doesn't appear to have any effect)
pretty much anything that causes the app domain to restart
Any other options? Is there a setting which affects how long IIS caches #include files?
First, as you probably know, you shouldn't use the #include directive with ASP.NET. The right solution is to use a user control or server control. However, if what you want is to inject a bunch of HTML and Javascript into a page (i.e. no server-side code), then you could use Response.WriteFile:
<%# Page Language="vb"%>
<html>
<body>
<% Response.WriteFile( "scripts.inc" ) %>
</body>
</html>
So as long as it's really static include, just load the file in C# code and inject it yourself. then put it in the cache with file dependency and the object will turn null after you change the file which will provide you the flag to read it again.
If it's not really static include (static == no ASP.NET controls - it can be very changeable otherwise - like a spew from a DB or different CSS for very user ) then you want to mess with page compilation and that's not going to happen unless you go and write your own template processor or something :-)
Doens't have anything to do with caching, either server-side or client-side. It's a compilation issue. #include isn't caught as a modification in ASP.NET when changed, so the page isn't rebuilt.
This KB should help: http://support.microsoft.com/kb/306575
If you're caching files that might need to change, you should include a version number in the file name.
eg: <!--#include virtual="/includes/scripts-1.0.inc"-->
then when you need to make changes to it, update your include to:
<!--#include virtual="/includes/scripts-2.0.inc"-->
Related
We're in the middle of a migration from IIS6/2003 to IIS8/2012. We have to maintain some Classic ASP and ASP and .NET apps. The full applications seem to work fine (as in, the ones I went in to IIS, right clicked on the folders and did "Convert to Application"), but our site relies heavily on menus that are included html files. The weird thing is, I'm 99% sure this was working before, but when we went to flip the switch for the new server, the menus didn't appear.
The file structure looks like this
wwwroot/dir/blah.html
wwwroot/dir/incb.html
wwwroot/ssi/inca.html
Now, within blah.html, I have two includes:
<!-- #include file="incb.html" -->
<!-- #include virtual="ssi/inca.html" -->
The first one works, the second doesn't. I tried this:
<!-- #include file="../ssi/inca.html" -->
But it still wasn't included, and just appears as a comment on the final page. I tried playing with/checking the permissions, but it looks correct. I also have "Enable Parent Paths" set as true under IIS->ASP for the server and the site itself. Was wondering if anyone had any thoughts?
Enable the Server Side Include module as a feature in Server Management, then add a handler mapping for .html to the SSI module.
This guy goes over it all: https://www.youtube.com/watch?v=foLClXY3wTE
Under the ASP section in IIS did you enable parent paths? This is disabled by default.
I solved that issue by setting up the application as a virtual directory instead of a site.
And the name of the application must be the same as the folder, in this case 'ssi'
I have a hybrid ASP.NET/ASP Native application that in one asp page uses a include to a .htm page that has hidden fields. I went to edit that page and now when I run the application it throws an execption: Include File Not Found.
I reverted to the last saved version in TFS and the error still remains. Online I have seen some things about absolute path but this is in the same directory as the page thats missing the error and it was working fine.
I tried to check the attributes in Dos and its not READ ONLY.
Has anyone experienced this before and any ideas on how to solve it?
Resolved issue:
I did not realize that ASP will parse comments as real code for certain things. In this case the <!--include --> was inside of a comment in a file that would not have had access to that path.
For example:
ASP Page that really calls the include:
c:\myproject\pages\mypage.asp
Include location:
c:\myproject\pages\includes\includeme.htm
ASP Page that had the notes:
c:\myproject\pages\includes\otherfile.asp
The location "includes\includeme.htm" was not accessible from otherfile.asp but it was commented out so I assumed it would never try to go their.
/*
Some notes.... <!-- #include file="includes\includeme.htm" -->
*/
So I removed the comment and it worked perfectly again.
This comment was worth adding to the answer based on how well it explains why what I did worked. Thank You #anonjr
#include is a server directive that is processed before anything else is parsed
- so the server will attempt to retrieve any files you have #include'd and...
include them.
Maybe this is a bonehead question, but I cannot figure out why this is happening.
I have to make an update to an old, classic ASP web site. One of the requests was to modify the footer so that the comments and suggestions could have the emails associated with a link changed in the administration panel.
That's not the problem, the original footer used on all pages was added as...
</div>
<!--#include file="../include/footer.htm"-->
</body>
If I add enter code here
enter code here<%#LANGUAGE="VBSCRIPT" %>
to the top of the page and change the extension to either .inc or .asp, modify the original page to:
</div>
<!--#include file="../include/footer.inc"--> (or .asp)
</body>
...I get an Error 500. I've tried using the web console in the browser, but no additional info there and there is no code on the page, only the declaration that VBScript will be used. Any help would be greatly appreciated. I'm sure this is something stupid that I knew 15 years ago, but just can't remember since I haven't touched ASP since 2002.
Parent paths are disabled by default in iis 7. This means that you'll get an error if you use "../" in an include file path
http://www.iis.net/learn/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/classic-asp-parent-paths-are-disabled-by-default
You could enable them in iis manager or you could use include virtual
<!--#include virtual="/root/include/footer.htm"-->
You could also use iis manager to edit how the server handles error pages, so that you can get helpful debug text rather than just a 500 internal server error page
first check IIS configuration
ERROR 500 causes by web server, google can found about this
If you set it as an .asp or .inc page then I recommend you set the content of the page up like this:
<%
'code here
%>
When you include B.asp into A.asp: also check that: B.asp not contains global variables / functions that are already declared in A.asp
Around 90% of the pages for our websites have no .Net code embedded in them yet are published as .aspx files. I want these to render as fast as possible so I'm removing as much as I can.
Does the .Net page directive have an impact on performance? I am thinking about two factors; the page speed for each GET and what happens when the file changes. The CMS system re-creates each page daily and I'm wondering if this triggers the ASP.Net compilation process.
If your pages have no .NET code and rendering speed is your goal, you may wish to consider changing the extension to .html. Any .aspx page will be passed to the .NET ISAPI filter by IIS and go through the entire chain of HttpModules, then will be handled by the Page HttpHandler. Using a .html extension would trigger IIS to process the request using the Static Resource ISAPI filter, which has a much shorter pipeline and is tuned for resources that run no code.
The <%# Page %> directive is not required. Without it, the default values for Language and other stuff will be assumed.
By changing a .aspx file, it'll be recompiled (it doesn't recompile the whole app though):
Any changes to a dynamically compiled file will automatically invalidate the file's cached compiled assembly and trigger recompilation of all affected resources. The next time a request to the code is made, ASP.NET recognizes that the code has changed and recompiles the affected resources of the Web application. This system enables you to quickly develop applications with a minimum of compilation processing overhead. (Note that depending on the change to the resources, the result can range from recompiling a single page to recompiling the whole Web site.)
Ok, put them in - just to be sure.
.NET pages are ALL compiled, page directive or not. nothing changes. Post compilation, they are as fast as it goes, as they turn into a class (type loaded once) that just executes.
Note that the post by Mehrdad Afshari is factually wrong (sadly I can not tag it). Any page change triggers a complete recompile AND restart of the appdomain. Acutally any FILE change does so, as long as it is outside App_Data and ASP.NET can see it (i.e. non-hidden flag on the directory / file).
I'm not sure how to test this question. I have an ASP.NET page for which performance is a big issue. At the same time, most of the content is static. In fact, all of the content is static at the moment. The content resides within a file extension of .aspx.
I am considering adding some functionality that would require dynamic code on the server side.
My question is, if a .aspx page does not contain any server-side code or runat="server" attributes, does anything .NET related get started? Alternatively, if a single line of server code were added to a Page_Load event handler, would this introduce a bunch of overhead like starting up the .NET runtime and such? How big of a performance penalty is it to add server code?
Thank you,
If you have a .Net application pool (and if you're serving .aspx pages, you do), the ASP.Net processor has to start up and compile the app before the first request to your page by any user. So any startup code you're worried about is already running.
If you already has .aspx pages, then you are already executing ASP .NET, and the pages are getting compiled in the background.
In that case, there will be no performance penalty in adding code, other than executing the code in question, of course.
Why don't you try it and benchmark it? An aspx page with "static" content will still get compiled. If performance is an issue, you can consider caching if appropriate.