2

What settings in ASP.NET determine where (as in which directorie(s)) a website will look for its code-behind files?

I have two versions of an asp.net c# website, Live and Dev.

Live site: www.example.com with the pages and code in c:\dev\websites\examplecom_new

Dev site: d3.example.com with the pages and code in c:\dev\websites\examplecom-d2

There are historic reasons why the live site's directory ends in _new and why the dev site has d3 as its hostname and -d2 on its directory name, but they work and until now we've had no issues, developing things on d3 for subsequent release to live.

I recently refreshed the dev site to be an exact copy of the live one (I usually do this before starting a new round of work), and started on some development work. However, when I tried to run the code via the website, even though the browser was showing the Dev URL, d3.example.com, the error message referenced a code file from the live site's web directory, c:\dev\examplecom_new, not the development version c:\dev\examplecom-d2.

I've gone through the code in detail to ensure there are no hard-coded references to either the www site or the path to the live site directory, and as far as I can tell there are none. The code files in all cases are referred to in the .aspx files as local links, for example:

<%@ Page Language="C#" MasterPageFile="~/ExampleCom.master" AutoEventWireup="true"
    CodeFile="Checkout.aspx.cs" Inherits="Checkout" Title="Untitled Page" %>

Yeah, I know "Untitled Page" isn't the most useful title in the world. :)

I've gone through web.config, had a look in app_code\general.cs, and checked all the tabs on the Properties element in IIS, but I can't find anything that could be telling the site to use the .cs files from the live dir instead of the dev one.

I tried restoring the previous (pre-refresh) version of the Dev site (I always back them up before replacing, just in case), just in case there was a config change I wasn't aware of, but the old version exhibits exactly the same problem, the Checkout page calls code from live, not dev, even though its URL is showing the dev verson in the browser.

Needless to say this is something of a showstopper, the error that's happening appears to be due to a session mis-match between live and dev, but I have no idea why the dev site is calling code from the live site instead of code in its own directory. Any pointers to what might be wrong would be appreciated. I've tried both Googling for "asp.net code behind files called from wrong directory" and related searches, and searching Stack Overflow for the same types of thing, but not seen anything related. We're not using pre-compiled binaries, just standard .aspx pages and .aspx.cs C# code files.

At first I'd assumed there must have been a hardcoded redirect kicking things over from dev to live, however I can see no trace of one and the browser address bar still shows d3.example.com/Checkout.aspx when I'd have expected a redirect to live to change it to the www version.

The webserver is IIS 6 and we're running ASP 2.

Pyromancer
  • 317
  • 3
  • 11
  • Is this a web application or a website type project? If it is a website, what happens if you modify some file in the website (so it causes it to rebuild)? Do you still experience the behavior? Can you also show screenshots of the website's setups in IIS? – mellamokb Apr 10 '13 at 17:39
  • Try cleaning "Temporary ASP.NET Files" folder. http://stackoverflow.com/questions/450831/what-is-the-temporary-asp-net-files-folder-for – Kenan Kocaerkek Apr 10 '13 at 18:05
  • It's a website, comprising lots of aspx and their companion aspx.cs pages. It's an e-commerce site that sells telephone numbers. I've just tried making small edits to both the code-behind and the .aspx page - and neither show up in the page on the browser. It's almost as if it's somehow reading this page (Checkout.aspx / Checkout.aspx.cs) from the wrong directory. But if I delete the entire directory contents, then I get "directory listing denied" as expected. – Pyromancer Apr 10 '13 at 18:05
  • @KenanKocaerkek: Cleaning as in deleting everything? Looking in there, there are directories for several of our sites, but none for this one. What will be consequences of deleting this be, will the sites be unavailable for any significant amount of time, or will there just the the usual "it's changed" compilation delay when someone tries to browse one of them? – Pyromancer Apr 10 '13 at 18:11
  • Update: I just tried deleting the entire directory contents again. Weirdly I can still see the files in the browser, even after a ctrl-refresh. Clearly it is indeed reading them from somewhere other than where it claims it is. I've also tried going to the site (post delete) in a different browser, and that is also showing content that shouldn't be there - and appears to be from the live site. Will back up the Temp files location and delete it, see if that makes any difference. – Pyromancer Apr 10 '13 at 18:19
  • When you say "website", I want to make sure you mean that it was created with "File->New Web Site", and not with "File->New Project". In particular, is there a .csproj or .vbproj file in the folder? – John Saunders Apr 10 '13 at 18:28
  • This is an application / site I've inherited, no idea how it was originally created. There aren't any .csproj or .vbproj files in the web root, there is an app_code directory, which contains general.cs. – Pyromancer Apr 10 '13 at 18:53

1 Answers1

1

Run "iisreset" command from command line and then clear temporary folder. All applications will be recompiled after that.

Kenan Kocaerkek
  • 319
  • 3
  • 9
  • or try adding one empty line of the dev app's web.config file. it forces to recompile codebehind. – Kenan Kocaerkek Apr 10 '13 at 18:46
  • Did a full stop of IIS, purged the temp files folder completely, then restarted. That cured most of the "stuff that's benn deleted still showing up" problem - but not the issue with the checkout page. One thing I realised - the problem is only happening on HTTPS pages, http ones are behaving exactly as expected. – Pyromancer Apr 10 '13 at 18:49
  • PS: Ta for the info re blank line in web.config, will remember that, handy. – Pyromancer Apr 10 '13 at 18:50
  • 1
    oh god :) set 8443 (or any other) port for dev app's ssl pages and access them with 8443 port. or have a new ip for dev app, for using default ssl (443) port. – Kenan Kocaerkek Apr 10 '13 at 18:52
  • Arse biscuits! :) Yep, just realised. It switches to https, connects by port and IP instead of hostname, hence getting the live site files even though hostname as shown in the browser address bar is the dev one. Will reconfigure it in the morning. Thanks for the help, was driving me bonkers! Cheers! – Pyromancer Apr 10 '13 at 19:57