Since my last post in this thread I stopped and started the Web site in IIS
Manager. Problem disappeared (I could no longer duplicate it).
Bruce - FWIW: my css files are actually css files (not aspx pages).
As Brad noted, restarting the ASP.NET Web application is necessary
sometimes; and in my case the files were already NOT included in the
project). In my troubleshooting efforts I had been restarting the ASP.NET
App by saving a change to Web.config. But apparently that's not the same as
Stopping and Starting the IIS Web site.
The only thing unusual about my aspx pages is that I'm injecting the [path
to the css file] into the <HEAD> at runtime. I'm not injecting CSS Classes -
just the path to the css file. Doing that was fine during development and
for a long time in production, and now it's fine again - it's just that
*something* mysterious (to me anyway) happened and Stopping and Starting the
Web site in IIS aparently cleared it up - even though recycling the
Application Pool did not clear it up.
While I can no longer reproduce the issue, I still don't know what caused
the issue in the first place. I'd hate to let it go at this. Any suggestions
for followup, or would I really need to wait and see if it happens again?
-F
"Bruce Barker" <br******************@safeco.com> wrote in message
news:OY**************@TK2MSFTNGP14.phx.gbl...
usually ccs files (*.css) are not served up by asp.net but by IIS
directly. IIS will pass the modified date on a get/head request.
for link files like *.ccs, the browser usually caches them by browser
session (until you exit the browser). with a new session, the browser does
a head request to see if the file has been modified, if so it reloads.
generally all you need to is hit the refresh button in the browser to
reload the css/image files, but IE is a little buggy. somestimes you have
to exit the browser and restart.
if your css files are actually *.aspx pages, asp.net should do the correct
caching for you if you are editing the aspx file.
-- bruce (sqlwork.com)
"Frankie" <A@B.COM> wrote in message
news:uY**************@TK2MSFTNGP15.phx.gbl... Using ASP.NET 1.1 and IIS 6... what is the effect of enabling Content
Expiration -- Expire Immediately?
Does it cause the files in the virtual directory to be served on every
single browser request even if the files do not change?
The reason I ask is that I was having trouble with a css file not getting
refreshed in the browser after the css file was updated on the server. In
testing I found that I could manually update the css file on the server
(via Notepad) and the browser would not get the updated CSS file. And
yes, I purged the cache, deleted local files, rebooted the local machine,
tested in a variety of browsers, etc. New browser sessions would continue
to receive the old version of the css file. The only thing I could
reliably do to cause the newly saved css file to be served was to recycle
the App pool . The hosting provider then enabled Content Expiration --
Expire Immediately and that seems to solve the problem. My concern is
that the css file(s) will now get served up unnecessarily (i.e., even
when they haven't been updated).
Thoughts? Suggestions?
Thanks!