Bug 320288 (MONO77510) - [2.0] XSP2 somtimes fails to detect changes in code behind files
Summary: [2.0] XSP2 somtimes fails to detect changes in code behind files
Status: RESOLVED FIXED
Alias: MONO77510
Product: Mono: Tools
Classification: Mono
Component: XSP (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Minor
Target Milestone: ---
Assignee: Gonzalo Paniagua Javier
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-09 19:31 UTC by Dan
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Test case for bug 77510 (462 bytes, application/octet-stream)
2006-02-09 20:22 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:47:46 UTC


---- Reported by dan.morphis@gmail.com 2006-02-09 12:31:14 MST ----

Description of Problem:  The XSP server will sometimes fail to detect and
recompile the code behind files for a web app.  xsp2.exe version 1.1.9.2


Steps to reproduce the problem:
1. Create a web application
2. View the web application in a browser
3. Make a change to the code in the code behind file.
4. Sometimes the change will be visible in the browser (I've cleared the
browser cache so I know thats not the issue)
5. If change was successfully viewed in the browser, make another change.
6. Refresh browser
7. Change made will not be visible.

I don't know if it makes a difference, but I am using Master pages.

Actual Results:
Change is not visible in browser due to XSP caching of some sort.

Expected Results:
Change would be visible

How often does this happen? 
Majority of the time

Additional Information:



---- Additional Comments From gonzalo@ximian.com 2006-02-09 13:06:44 MST ----

By code behind file you mean something that is referenced in the
'CodeBehind' attribute or 'Src'? Could you attach a simple test case
that someone could use to reproduce the problem? This works fine for
me with the tests that I have (1.1.13/HEAD mono here)



---- Additional Comments From dan.morphis@gmail.com 2006-02-09 13:22:17 MST ----

Created an attachment
Test case for https://bugzilla.novell.com/show_bug.cgi?id=MONO77510




---- Additional Comments From dan.morphis@gmail.com 2006-02-09 13:23:34 MST ----

The attached test case is not using master pages, but does exhibit the
problem I'm having.



---- Additional Comments From gonzalo@ximian.com 2006-02-09 18:54:02 MST ----

The example you attached uses 2.0 stuff that is not yet ready. I can't
even run that sample. Do you have a test that uses 1.1 only?




---- Additional Comments From dan.morphis@gmail.com 2006-02-10 12:22:53 MST ----

I updated to v1.1.13 last night and I'm not seeing this behaviour with
ASP.NET v1.1.  However this behaviour is still happening with ASP.NET
v2.0  Which you said is still in beta.  I'll let you decide how to
close this bug.



---- Additional Comments From gonzalo@ximian.com 2006-02-10 15:53:44 MST ----

I'll keep it open and close it when it works for 2.0.
Thanks.



---- Additional Comments From gonzalo@ximian.com 2006-06-15 17:45:44 MST ----

This works fine now.

Imported an attachment (id=169245)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Debian Sarge with some SID componets - Kernel 2.6.8-2-386</cf_op_sys_details>
Unknown operating system other. Setting to default OS "Other".