Question posted in
The official documentation can be found here.

Asp.net – Visual Studio IIS Express Won't Show Updated Code Changes

I’m developing a web application that has a Login page. In that page’s code behind page, I’m calling a function from another class called "MyOtherClass". That class uses the "Sub New(blah)" method/procedure to connect it all. Basic version of code shown below.

It works, however, here’s my issue:

As I’m developing, I like to launch the site, make changes to the code, and then hit the browser refresh to see the changes. However, for some reason, changes I make to "MyOtherClass" don’t show. I either have to:

  1. Go to IIS express in the Windows system tray and stop the site or exit the service.
  2. Rebuild the project from the Visual Studio "Build > Rebuild" menu.
  3. Or, if neither of those work, completely close VS and start everything up again.

Any ideas?

It has to do with my usage of the "Sub New(blah)" method on "MyOtherClass" because this never happened before I just started using this (and need to).

I’m developing in VB.NET in Visual Studio Community 2017. It launches IIS express when I browse the site.

Code for the Login.aspx.vb file.

Partial Class login
    Inherits System.Web.UI.Page

    Public vOtherClass As New MyOtherClass(Me)

    Private Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
        If vOtherClass.VerifyMe() = True Then
            Response.Write("Yes! You made it!")
        Else
            Response.Write("Dang it! Try again!")
        End If
    End Sub
End Class

Code for the MyOtherClass.vb file.

Public Class MyOtherClass
    Dim vPAGEOBJECT As Page

    Sub New(MyPage As Page)
        vPAGEOBJECT = MyPage
    End Sub

    Function VerifyMe() As Boolean
        'If I change this to return 'False' while I'm browsing my design, VS won't reflect the change.
        Return True
    End Function
End Class
Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I ended up using IIS Manger on my local computer instead of IIS Express from Visual Studio. This is a workaround of sorts, but it works and seems to have fixed my issue.

    To be more specific for others who may run to this problem:

    1. I already had IIS Manager Version 10 (IIS) enabled on my local computer. If you don't you'll need to enable it.
    2. From IIS, I added a new web site under the "DefaultAppPool" application pool to keep things simple.
    3. I pointed the path of the site to the location of the web site I'm working on, set a unique port, etc.
    4. I launched Visual Studio as an administrator (it must open as an admin).
    5. Then, I opened the website under "File > Open Website" (versus opening a project or solution). When opening the site, I selected the "Local IIS" open and then selected my web site (It should automatically be listed if you set things right).
    6. And that's it... I browsed my site, made some changes to the Classes, refreshed the page and... it all showed.

    Thanks to everyone who tried to help. Your suggestions were very informative.


  2. 0

    How this has worked for about 20 years will depend on the type of project you are using.

    If you are using a asp.net web site, then making changes to code behind for a given page and then hitting f5 in the browser WILL and SHOULD show changes. Of course, the exception (as is your case) is that code behind for the given page is NOT being changed, but an external class file is being changed. As a result, the current page will as a general rule NOT detect that you made changes to the external file (which will/can be auto re-compiled if code changes in the CURRENT page are detected. Since it is an external file, then in most cases VS will not pick up that you made changes to that code behind.

    However, most of use (after at least working on a asp.net webforms project), will and do and should choose the 2nd type of project:

    Asp.net web site "application".

    Note the MASSIVE HUGE LARGE difference in the type of project. With a web site "application", then to see code changes, you have to hit the stop button, and then hit f5 in VS to force a re-compile and then a re-load of the code.

    So, this means that if you make ANY changes to code behind, then a full re-compile of the site is required. The advantages of using an "application" type of project are many, but they are:

    No source code is deployed to the web site. This enhances security, web startup time, and also allows multiple projects to be build as part of the project. Hence, if you working with other developers, or wanting to include other projects (external projects such as shared class library code), then any update to the web site requires a full re-build and a full re-publish of the web site anyway.

    During publishing, then VS is compiling the code for you, and NOT IIS. If you let IIS compile the code, then MANY MANY issues can arise, such as Rosyln compiler support, using git-hub (don’t we all do that now?) and more.

    So, while you lose the ability to deploy updates to say just ONE page, and for an update to the site you must do a full re-deploy (a full new publish), these advantages far outweigh that of using a asp.net web site (which was a good choice say 15+ years ago).

    However, not sure if it was vs2019, or vs2022, but we do now have what is called hot-reload.

    So, if you make changes to code, then you can hit the hot code re-load button.

    That is this button:

    enter image description here

    So, quite sure you need vs2019 or later. (and it is a rather good idea to update to vs2022 anyway).

    So, in summary:

    For 20+ years, a asp.net web site "application" NEVER would re-compile the code behind for you. About the only exception is if you using App_Code folder, and I VERY but beyond VERY strong recommend that you create your own folder, say MyCode, and place the class files inside to "compile" on build, and once again you 100% eliminate that your web site is compiling the code, since you WANT VS to compile your code BEFORE you deploy, else all kinds of issue and problems can crop up, including that of a miss-matched compiler that resides on the web site. As noted, even better for many reasons ranging from security and more, your source code files are NEVER published to the web site, but only the .aspx pages and pre-compiled .dll’s. And in fact, in most cases you can have the site build to ONE simple .dll in place of 100’s and 100’s of small .dll’s strewn all over the page on that site.

    However, EVEN with a web site option (which looks to be your case), the fact that code behind is creating an instance of that class, that class object going to be loaded into memory, and unless you force a hot-code re-load as explained above, then you simply have to close the web page, or hit the stop button in vs. That action will automatic close down the site, and then in most cases just hitting f5 in VS to re-launch the site will show your code changes.

    So, as noted, from what you explained, the behaviors you are seeing been standard fair and has always worked the way you describe. Also, it is debatable why you using a class and creating an instance of that class when you could have created a simple code module and just call such code. However, I’ve not tested as such, but since that code file is external to the current web page code, then I suspect that a simple F5 will not re-load that code anyway. However, using the hot code re-load button should work.

    So, if vs2017 does not have the above hot code re-load, then a simple hit of the stop button, and then f5 in vs should work.

    go to IIS express in the Windows system tray and stop the site or exit the service.

    Well, the above is just plain silly, when a simple close of the page, or hitting the stop button in VS should suffice here. (so, doing the above is perhaps worst possible idea and approach to software development). Why would you do the above when a simple hit of the stop button in VS would suffice.

    Regardless of having to re-start IIS (which makes the worst possible sense here), you need to adopt the hot code re-load.

    You also failed to mention what kind of project you are using here, since as noted, using the recommended "application" choice, then your only practical choices are using hot-code re-load, or hitting stop button, and then hitting f5 inside of VS.

    So far, the behaviors you note here have been the same for 20+ years, and based on your explain, how VS has worked for 20+ years remains unchanged.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search