I created an aspx page and viewed it in Firefox and Chrome and it worked correctly, running the C# code. But when I make changes to the page (including deleting everything and serving up a blank page), both browsers continue to show the original compiled aspx page!
It appears that ASP.Net (the web server) is not recompiling despite changes to the aspx file. The only way to get it to recompile is to change web.config and then restart the web server!
I even added the following code, but it still loads the original page:
<script runat="server">
Sub Page_Load
Random rd = new Random();
Response.AddHeader("ETag", rd.Next(1111111, 9999999).ToString());
Response.AddHeader("Pragma", "no-cache");
Response.CacheControl = "no-cache";
Response.Cache.SetNoStore();
Response.Expires = -1;
End Sub
</script>
TEST I DID TO RULE OUT BROWSER CACHING:
Created an aspx page and loaded it in firefox only (not in chrome)
Changed the aspx file
Loaded aspx again in firefox but got no changes
Loaded it (for the first time ever) in Chrome and it still showed the old version!
Using Apache and Mono, not IIS
This appears to be a Mono+Apache on Linux issue. It doesn't see changes to pages that have been compiled. The only workarounds are:
Restart Apache webserver (this causes it to see them as changed) - only takes about 2 seconds
Delete the temporary files in "/tmp/www-data-temp-aspnet-0/" (This can be a bit buggy so #1's a better choice)
Check whether your web application is a Web Application project or a Web Site project. If it was a Web Application, you will need to compile each time you change something, whereas web site projects allow changes to get reflected without compilation. Also, you can use Ctrl+F5 in browsers to get a non-cached copy of pages. Hope his helps.
Read details here
Short Answer: It is browser's fault, and it is expected behavior by design. Force cache refresh in browsers (Ctrl-F5 in IE).
Correction: When it is Mono/Apache stack, not an IIS. Then manual restarts can be the only workaround. In IIS the stale effects are naturally cleared in between periods of inactivity, when server kills idle processes. In Mono, there may or may not be same cleaning schedule, so, the process lifecycle and configs are the first place to look at for fix.
The behavior of not recompiling is caused by complex identity of requested pages. Identity includes URL, timestamp and session. If you trying to refresh page without closing the browser, then ASP server will need to serve a stale copy of older compiled page, because server tries to maintain consistency of served page with existing session, viewstate, perhaps even client side scripts wich exist on client in between partial updates, etc. Also browsers are designed to comply to slowly changed internet pages with storing copies in cache and maintaining the age of copies to skip unnecessary network trips. Or else internet would be 10 times slower.
Other note: The most slow files to push through ASP server are css files.
Related
I'm fixing a bug with ASP.NET OutputCache and it's driving me insane.
We want caching on the server, but it does not appear to work (it did a while ago, in an older version of our app, but we discovered the bug by accident recently).
Locally, I just cannot get the caching to work on the server-side. Using this attribute:
[OutputCache(CacheProfile = "MyProfile", Location = OutputCacheLocation.Server)] // doesn't work
Now, based on a few things I've read by googling around, here is possibly relevant information:
Output caching is enabled in IIS (localhost)
I DO use an AuthorizeAttribute (a custom one with inheritance). I've debugged towards this specifically, and I'm 95% confident this is not the cause.
I've fiddled around with various VaryByParams values, nothing works.
Caching does work client-side.
I've opened a perfmon session and added some counters from the Web Service Cache group, All I see is that there are cached URL's but the cache is missed:
The bigger problem/bug we're facing now is that OutputCache is not working at all right now. We were able to fix that by specifying VaryByParams="" (an empty string). That did it for the client. But it doesn't work server-side yet.
I'm actually checking whether it works or not by placing a debug breakpoint in the action that should be cached. It gets hit everytime, which should mean the cache is not hit.
From http://www.asp.net/mvc/overview/older-versions-1/controllers-and-routing/improving-performance-with-output-caching-cs:
There is no guarantee that content will be cached for the amount of time that you specify. When memory resources become low, the cache starts evicting content automatically.
If the available memory resources on your server are low enough during your testing, the cache will evict content immediately. I'm sure it could even refuse to put your content in the cache.
I'm working on a .Net/ASP project and my responsibility is to work on the design part of the application only (mostly changing css, js, images, and cshtml files)
I'm working directly on the server, so my app is not running in visual studio or locally or any environment where I can rebuild the app.
That being said, any changes I make to the website takes about 45 minutes before it shows up (I do clear browser cache every time as well).
Is there any way I can manually clear the application cache or rebuild it on the server so my changes start showing immediately?
This is something I added to the we.config but still not helping:
<caching>
<outputCacheSettings enableOutputCache="false"/>
</caching>
Well, if I'm not mistaken the cache you're targetting is not about this kind of resources as they're simply not processed by .NET. This outputcache is rather about the final HTML rendered. So I don't think that's where you should be looking. But there may be some kind of proxy somewhere caching those resources aswell.
To avoid client/server caching problems with CSS and javascript, I usually add a time ticker to every request avoiding them to be cached client-side. It should also override any "server caching" of those resources, and I would advise testing it manually before putting an automatic solution in place. so, if you're including js file that way :
<script src="/mypath/myscript.js"></script>
you could just do that :
<script src="/mypath/myscript.js?123></script>
and see if you get the changes in the file immediately now. If yes, just automate the addition of that number (ideally a timestamp so it's always different on each request) to every javascript/css inclusion you make...
I made some changes to the existing asp page. When I access it I don't see the changes yet and I still see the old content. Do I need to recompile .asp files?
The pages are likely cached in your browser. There are a number of ways to get around this. You can:
force a page refresh on the browser ([Ctrl]+[F5])
Recycle the application pool (if this is an application)
(or the dirty way) make a tiny change (like adding a space) to the global.asa which will in turn recycle the app pool
Edit (2017)
If you're debugging using IE then you can also set your cache to refresh every time you visit the page:
Bring up the internet options. Click the Settings button on the Browsing history section of the dialog and change the Check for newer versions of the stored pages: setting to Every time I visit the webpage...
ASP pages are scripting , you do not need to compile , just check if you have page cached on the browser .
After deploying a new version of a website the browser loads everything from its cache from the old webpage until a force refresh is done. Images are old, cookies are old, and some AJAX parts are not working.
How should I proceed to serve the users with the latest version of the page after deploy?
The webpage is an ASP.Net webpage using IIS7+.
You can append a variable to the end of each of your resources that changes with each deploy. For example you can name your stylesheets:
styles.css?id=1
with the id changing each time.
This will force the browser to download the new version as it cannot find it in its cache.
For ASP.NET you can use the cache control and expires headers. You can also set up similar headers in IIS 7 for your images. If you have any other cookies you can expire them manually.
I have not tried it, but it looks like you can do an ever better job of bulk setting cache control in IIS 7. See this thread and this link. At that point you are only left with unsetting any custom cookies you have (which you won't be able to control with HTTP cache control settings).
I don't know of any method to "unset everything all at once" easily.
You could use http headers to control the cache of your clients.
I'll just leave this here for you. http://support.microsoft.com/kb/234067
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).