Alvin,

I appreciate your replies; but, I think we are not yet understanding one
another.

You wrote, "...to rephrase, the dependency on the aspx file works but the
dependency on the codebehind file does not work, right?"

The first part of that statement sounds like a circular reference to me.  I
am talking about the Last-Modified date of the .aspx page; so, are you
saying that the Last-Modified of the .aspx file is dependent on the .aspx
file?  :]  If so, I would not state it that way, but we seem to agree.

Regarding the second part of your statement, yes, I am saying that the HTTP
header's Last-Modified Date sent to the requesting host by way of the
HttpCachePolicy.SetLastModifiedFromFileDependencies method does not take
into account the file system's "Date Modified" of the code beside file.

You seem to be saying that this makes sense to you, because "The code beside
files is of absolutely no use to the run-time" ...and it has to do with how
the engine makes temp files...etc.  I disagree, wholeheartedly, about this
making sense, and so do Visual Studio and IIS.  I'll try to illustrate
below.

In Visual Studio (I'm using 2008), add a new Web Form item, and check the
"Place code in separate file" box.  You'll get a .aspx page with page
declaration including CodeFile="Default.aspx.vb" Inherits="_Default".  Go
ahead and delete the ..aspx.vb file since you feel that there is no
dependency on it, then try to build that page in VS 2008.  You'll get a
build errors, for the Default.aspx file, to the effect of:
1. Error 1 The file '/Default.aspx.vb' does not exist.
2. Error 2 'Context' is not a member of '_Default'.
That seems like a sign of dependency to me.

Without fixing those, request the .aspx page via a browser, and IIS will
tell you:
Parser Error Message: The file '/Default.aspx.vb' does not exist.
Source File: /ec/Default.aspx

Again, that seems like another sign of dependency to me.

I understand your technical explanation of how the ASP.NET engine uses my
developer design-time files to make temp files to serve to hosts.  That does
not change the fact that it is doing something wrong with respect to the
HttpCachePolicy.SetLastModifiedFromFileDependencies method.  It is not
taking into account the file system's "Date Modified" for the .aspx.vb--but,
it should.  (Your explanation regarding compiled temp files may make sense
to you, but consider it for a first time building/compiling/running of a Web
site versus after I make changes later.)

Let's look at this from a slightly different angle.  My real-world goal: I
am trying to get the HTTP header's Last-Modified Date, of my .aspx page,
which hosts request by name, to cache (publicly and/or privately) in a way
that makes sense, so that the host's agent can smartly determine if it may
reuse a cached version of my .aspx page--if it has not changed.  Whether or
not my .aspx page has changed certainly could--and should--depend upon
whether the code beside file has changed!  Why would I put code in the code
beside if it does not change the .aspx page?  For example,
TextBox1.Text = "We are no longer accepting reservations for today."

As I understand it, the code beside is simply an alternative place to store
syntax that could have been in the .aspx page.  (for the sake of separation)
That's why Microsoft gave me the option to check the "Place code in separate
file" box.  If I check the box, the code beside consequently must/should be
considered when determining what Last-Modified Date to send to the
requesting host--but it isn't.

If I do *not* check the "Place code in separate file" box when I add a new
Web Form item, forcing me to put my "code beside" code into my .aspx page
inside <% %> delimiters, the HTTP header's Last-Modified Date, via the
HttpCachePolicy.SetLastModifiedFromFileDependencies method, will always
reflect the file save date of changes to CLR code inside the <% %>
delimiters.

If I do use code behind and make the same code change, the
HttpCachePolicy.SetLastModifiedFromFileDependencies method will not take
into account the saving of those same CLR code changes, giving an outdated
HTTP header Last-Modified Date.  That should not be!

, Lee C.