Debugging TideSDK application: Quickly reload source - tidesdk

Is there a way to quickly reload the source files of a TideSDK application when developing instead of having to close it and restart? I tried binding a keypress event to
location.reload();
but that does not work.

Related

Easiest way to run/debug ASP.NET Core app

I just upgraded my ASP.NET (Framework) MVC app to ASP.NET Core 2.2. That process was painful enough, however even more painful is running the web app locally.
Issues with running in IIS Express:
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
Issues with running in IIS:
The only way it runs is if I manually edit my Web.config to have the proper values for processPath ("dotnet") and arguments ("./bin/Debug/Housters.Web.dll"). Visual Studio likes to inject in aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" every time I build or run my app, despite me having IsTransformWebConfigDisabled = true in my .csproj. So I constantly have to go into git and revert these changes, or else my app will fall back to the dreaded ANCM In-Process Handler Load Failure page.
Assuming the Web.config has the proper values, after running the application in the browser I can no longer build the project. Instead it gives the error: Error MSB3027 Could not copy "obj\Debug\netcoreapp2.2\Housters.Web.dll" to "bin\Debug\Housters.Web.dll". Exceeded retry count of 10. Failed. The file is locked by: "IIS Worker Process (15496)". IIS is using the ASP.NET Core web app's dll so I can't actually update my code and build it, that's just great. The workaround is to recycle my IIS app pool, but this gets old REAL quick when you need to do it before every single rebuild.
Attaching to the w3wp.exe process isn't causing any breakpoints to be hit, so I can't debug under IIS (IIS Express debugging works fine.)
The launch profiles that I configured in launchSettings.json are ignored. For example, when I choose my IIS launch profile (which has "http://localhost" as the launchUrl and applicationUrl), if I F5 or Ctrl + F5 it opens "http://localhost:62551/" in the browser window.
So this begs the question, how are others developing/running/debugging their ASP.NET Core apps on their local dev machines? Maybe most web developers have moved away from ASP.NET to purely javascript frameworks like Angular, React, and Vue so I'm just out of luck? Or am I missing something that will make ASP.NET Core development less painful?
Currently, the experience with ASP .NET Core has greatly improved compared to the past.
However, certain glitches still remain. For what regards IIS Express (in production we use Kestrel), you can try these things with Visual Studio 2017 and 2019 (they work for us):
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
Just don't use the page: let the tab/page open, spawn another tab/page and use the latter for debugging. This way your session is going to be as similar to a production environment. We have Firefox as default browser, but we usually debug with Chrome, therefore, not touching the process spawned by Visual Studio keeps IIS Express alive.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
It seems that cleaning the whole solution twice solves the issue (at least for us). The first time you clean the solution, IIS Express still serves the site. Apparently, this should be the designed way (cannot find the documentation about that).
If that does not work, it might happen that a Visual Studio service is stuck. In this case, shut down Visual Studio (I know, it's painful), wait a little bit, and kill all the dotnet.exe currently running after verifying they are part of Visual Studio.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
This is partially what I said previously. Although painful and resource expensive, having multiple windows open allows us to survive.
For reference, we use the very same configuration on debug and release (with kestrel).

how to run an asp.net app without a debugger attached

I want to build my solution, and then open a browser and test it, without pressing F5. Should be simple, I am sure I have done this before many times but in other VS versions.
I just cant figure it out :)
I have tried different settings on IIS and in the project settings for my app.
From VS, I use IISExpress and the project url is
http://localhost:1234/
I use asp.net mvc 5 with VS2013
I want to be able to close the VS instance and still run the app
For MVC applications. You typically need to do two steps.
Open the Project Properties. Select "Web". Select the "Specific Page" setting and leave it blank. Make sure no other settings have values either. This will force IIS Express to launch the app, but then the routing in MVC will take over.
Press CTRL+F5 to "Launch without Debugging". This launches the app without the debugger attached.
From there you can rebuild your application, but not have to press CTRL+F5 every time. IIS will detect the changes and refresh the ASP.Net worker process as needed.

How to refresh Mono ASP.NET page without restarting the web server?

When I make changes to a file, Mono ASP.NET doesn't see my changes, I have to do this:
sudo /etc/init.d/apache2 restart
I remember when Mono ASP.NET executes ASP.NET it caches the compilation somewhere. Before, when the updated page doesn't come up, I just delete that cached compiled code. I just forgot the exact path
How to make Mono ASP.NET detects the changes I made in program, without restarting the web server?
It sounds like the FileSystemWatcher cannot see changes coming from the windows side.
After you update on the windows side, go to the linux side and do:
touch Web.Config
or any file on the directory. This should notify ASP.Net to load your new code.
This is the command to restart your App, and recompile if its needed. (with out restart the web server).
Can you test it if do the work ?
HttpRuntime.UnloadAppDomain();
The other way is to create a file app_offline.htm on root, upload your changes, and then delete it.

Flakey debug behavior in application start, global.asax

Not using Cassini, but IIS7 to run an ASP.NET app.
The debug behavior is flakey. Sometimes it works, sometimes it doesn't. I was able to step into the application start event in global.asax but sometimes I can't.
Sometimes VS2008 opens the published global.asax so I have two instances of global.asax opened in VS, the source and the published.
I reset the AppDomain and IIS and I can't put my finger on why this is happening. Any clues?
To add, while it won't go into application start, I have an OnChangeEventHandler event - it does step into the event handler.
Visual Studio doesn't connect to w3wp.exe soon enough to handle breakpoints in Application_Start for IIS7-hosted applications. To debug, use the following line to call debugger explicitly,
System.Diagnostics.Debugger.Launch();
and choose to launch a new instance of Visual Studio.
make a change in the web.config, the application pool will recycle and the global.asax code will be loaded, the debugger should still be attached

Why can't I edit my ASP.NET Web application at run time?

Why are the code-behind pages for an ASP.NET web application locked at run time? I have older projects (probably defined as "web sites" instead of "web apps") where I can edit the code behind, refresh the browser, and see my changes. With the web app, I have to continually close and reopen the browser if I want to see my changes live. Is there a setting or something I'm missing to allow me to edit at run time, and without restarting the debugging session?
You can enable Edit and Continue in the project properties. Right click the project in the solution explorer, select the Web tab and check Enable Edit and Continue.
Now you can edit your sources, but you have to pause the debugger to do so.
When using IIS as your development server, Edit and continue is not currently available for Visual Studio for ASP.NET.
See this blog entry, however, that shows it is possible for the Visual Studio 2005 Web Application Project Project type. It requires using the Visual Studio Development Server (Cassini) during development instead of your local IIS (see the properties box on the project).
No, in web applications, the codebehinds are pre-compiled into dlls, so any change in the dlls will recycle the App pool, and stop your debugging session,
If you press ctrl-F5 instead of just F5 to start (or host you site in IIS), you start without the debugger, and don't need to restart the browser all the time...
Unless you really really need to debug a problem you can't figure out, You should start the web app without debugger, makes it snappier to start up. Every minute spent debugging is a minute not spent writing a unit test. IMHO you should write unit tests, they last longer.

Resources