Check your web.config / episerver.config siteSettings element. In development you should probably set the httpCacheExpiration to "0:0:0". You shouldn't have to disable cache in any other way.

Changes to static files like css might require a ctrl-f5 for your browser to get the new files.

I always use [ctrl] [F5]. I just experienced a strange behavior debugging when I attached Visual Studio to the w3wp process.
Before attaching the process I did a rebuild on my solution. Before that I had done a change on PageHeader.ascx. When Visual Studio was about to start debugging this page, VS said that the file was different from the compiled version of the file. I tried to both "build" and "rebuild" my solution, but the compiler still said that the file was different.
Very frustrating...

I just found that httpCacheExpiration already is 0:0:0. It seems to be the default value for this attribute.

I just did a change in the lang file. Entered a space in web.config so I could save it for invoking a restart on the application,
but nothing changed. I used ctrl + f5.

What happens when you run the site through Cassini in Visual Studio? (press F5 in VS)

And what URL are you using through IIS? (Make sure your urls are bound to 127.0.0.1)  Does your company have a proxy server or something that could be caching your request?

I guess I might have found the answer in another thread.

The answer might be this:

http://world.episerver.com/Templates/Forum/Pages/Thread.aspx?id=46814&epslanguage=en

Jon Haakon

I'm experiencing the same problem right now on two projects.  All cache expirations are set to 00:00:00, there are no proxy servers involved, my workstation is not setup as a "webgarden".

I have to build in visual studio to have any changes in an aspx or ascx show up regardless of if I'm debugging or not.

Did you see Steve's answer in the link above? http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=46814&epslanguage=en

Running your computer as a "web garden" is not recommended.

Yes, I noticed. The problem is kind of history now, but I will be aware of web garden and check that the next time I experience the problem.

Today I installed/released a website with a new feature on the frontpage. After installing the website, I tested it and saw that everything worked okey on the server. I sent confirmation email to the customer to tell that the new feature was installed. My contact verified that it worked and informed eveyone that the website was updated.

Then the problem occured. All employees got http 500 error "The page cannot be displayed". This was a IE friendly error message. After turning of friendly error message and refreshing the page, the result was a blank page. I checked the log4net logfile and found that one of the webparts returned a object failure errormessage. To eliminate the problem, I turned of all webparts - then the end users could open the website. We added webparts step by step to see what webpart that was failing, but ended up with everyone working.
A half hour later, he called back to say that the page was down again.
Since I had published the hole project paralell with the production site, I merged my changes with the old page and that's where I'm standing now.
Tomorrow I have to talk with my customer to see if the page is working or not.

From the early days there was something called dll - hell - perhaps it's not the best name for it, but cache-trash comes to my mind. :)

Thank you for helping out, Lars!

Hey guys I've just blogged about this so wonder if it will help:

http://world.episerver.com/Blogs/David-Knipe/Dates/2011/3/Preventing-EPiServer-serving-cached-mark-up-in-development-environments/