Home » none » Why ASP.NET Changes Don’t Change Anything

Why ASP.NET Changes Don’t Change Anything

B02B0053

Has this happened to you?

You make a change to a codebehind file or a web.config file and you rerun the application to see the effect and there is no change from the previous time  you looked at the file?

I see this over and over again.  But not on my own code.  Typically it is because someone has asked me how to fix something. I tell them.  They make the change.  They refresh the browser.  And they report, “that didn’t fix it.”

My response is always, “did you close all the browser windows first?”

I just had this happen again this evening.  Told a guy to remove precompile.config from the root of the application on the server because we are no longer using a precompiled site.  He refreshed and said, “that didn’t work.”

Of course not!

If you want to be sure that all your changes will be visible when you are developing, you need  to run the web site using F5 or the “play” button in the IDE.  That will cause a fresh start.

If you aren’t using the IDE, or refuse to use the run button, you need to make sure a new session has been started by closing all your browser windows.

Why?

Because ASP.NET sites are built so that we can upgrade them on the fly.

What would happen if you upgraded the site in the middle of the day and completely changed the structure of a class while someone was using that information?  All kinds of nasty errors would show up for the user.

So what .NET does is it keeps the old code around for the people who are currently using the site and uses the new code for new visitors.  That is, visitors who have started a new session.

Without this feature, you’d have to wait until a time when no one was using your site before you could update it.  This may be fine for a corporate intranet.  But for a public-facing Internet site, late at night for me is still the middle of the day for someone else.  There is no good time to upgrade.

Next time a “fix” isn’t working, make sure you’ve started a new session prior to declaring that the fix doesn’t work.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Unrecognized Tag Prefix or Device Filter ‘asp’Unrecognized Tag Prefix or Device Filter ‘asp’ One of the companies I work for recently took over a project from another vendor.  As we started to maintain the site, we noticed that we could not drag and drop controls onto the page […]
  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • How to take an ASP.NET application off line . . .How to take an ASP.NET application off line . . . . . . without turning off IISWhy would you want to do this?Well, you might have more than one application running under a specific IIS server instance.  Or, maybe you don't have […]
  • ASP.NET Session Variables Not StickingASP.NET Session Variables Not Sticking I’ve stumbled across this problem twice in the last couple of months so I figure it is about time I blogged about it. The situation is that you have  a page on your web site that […]
  • The case of the disappearing session variablesThe case of the disappearing session variables Way back in ASP.NET version 1.1, I wrote one of my first asp.net web sites for a client that depended pretty heavily on session variables.  Without getting into the arguments about the […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.