I am learning a new ASP.NET MVC app that uses some approaches I am not used to / familiar with. Without having to deal with the client side scripts (because there appear to be over a thousand), I want Visual Studio to go into break mode / stop at the first line of code executed on the server.
Is there a way to do that?
For example, I click a button in the web site that run a script that shows a dialog box (I don't believe any server code has executed at this point in this series of events). Then I fill in some fields and click a button in the dialog box that I know sends data back to the server. I want the sever to stop at the first line of code it attempts to execute as a result of the button being clicked.
I thought you used to be able to put the app in Break mode, then you could use the Step Into button to take you to the next line of code but this no longer seems to work.
Any ideas?
You can use my Runtime Flow tool to find out what code is executed on the server when you click a button in the web site. Though you need to manually configure Runtime Flow to monitor your web application as described here https://vlasovstudio.com/runtime-flow/documentation/quick_start.html
Why do I have all this junk in my console, only when using VS 2022?
I set Options -> Projects and Solutions -> ASP.NET Core -> Auto build and refresh options -> NONE
And also disabled 'browser link' here:
None of that stuff appears when running the same project in VS 2019, and I'm pretty sure its messing with my SignalR connections
For anyone using dotnet cli tool and want to disable the hot reload and console output whatever, and have no luck with dotnet watch --no-hot-reload, try put this at the very start of your js script:
function removeDotnetHotReload() {
const scriptInjectedSentinel = '_dotnet_watch_ws_injected'
// #ts-ignore
window[scriptInjectedSentinel] = true
}
removeDotnetHotReload()
For aspnet-core-browser-refresh, can you please file an issue at https://github.com/dotnet/sdk, as that's where that code lives?
For Browser Link, I can tell you that right now there's no way to disable those messages in a .NET 6 app without turning off CSS Hot Reload as well (you can turn verbose messages off in the console so they won't show, but they'll still be emitted). If you are ok turning off CSS Hot Reload, you can do that in Tools->Options->Projects and Solutions->ASP.NET Core. Please file feedback at Developer Community about this as well so we can potentially make this more discoverable.
That said, I'm curious why you think this might be interfering with your SignalR connections. If there is interference there, we definitely want to address that as well, but I'm not sure off the top of my head why that would be.
Per https://developercommunity.visualstudio.com/t/Browser-Link-cannot-be-disabled/1582653#T-N1608441, adding "hotReloadEnabled": false to your launchSettings.json profile(s) should suppress the injection of these scripts by Visual Studio. This does not actually turn off C# hot reloading - just turns off the scripts that MSFT injects.
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
I use Visual Studio 2010 to debug a asp.net MVC project in my local machine. The steps are:
Click Debug and try to attch process "w3wp.exe". However it is not in the list.
I am sure "Show processes in all sessions" is clicked.
w3wp.exe won't show in the running process' unless there is actually an instance of the web application running.
Try to access your web page first, when it is displayed for the first time, try to attach your debugger. The process should now show up.
You need to click Show Processes from All Users at the bottom of the Task Manager list. This is what i needed to do.
Restart IIS
Right click your site >> Manage Website >> Browse
Back into Visual Studio refresh the processes list
Try to check on :"Show Processes for All Users"
When on the 'Attach to Process' window in the bottom left there is a checkbox 'Show Processes for All Users'
An easy way that works ,when w3wp dont appear in the list,open a browser and write localhost ,then enter.After that w3wp appears to list.
Just because an IIS application pool is started, there may not be an
IIS worker process w3wp running. IIS will not start the worker
process until the first web request is received.
In my case, I first launched the application, still could not find w3wp.exe. Then I took the worker process ID from (IIS->Worker Process -> Process Id) and then search by id in the details tab and found it.
Clear the Solution
Rebuild the solution
Reset the IIS by writing the command iisreset in command prompt
Go to IIS and browse your website
Run VS as administrator
Tools -> Attach to process -> Ensure the 'Show Processes for All Users' checkbox is checked -> w3wp.exe
Attach to w3wp.exec
If you are using something like Advanced Rest Client to test routes, call your route again then refresh the list of processes and it will show up
GoTo Web Project properties -> Select (Web) on the left sidebar -> GoTo under (Servers) header -> Click to dropdown and select "Local IIS"
and apply. Then, when you start debugging you will see w3wp.exe on the proccess list.
I just ran into this issue - you may want to also double check your host settings and verify that you are actually pointed to localhost and not a production server.
I forgot I was pointed at a remote server, and thus, though I was accessing the site, it wasn't anything local so w3wp wasn't running, despite my superficially being able to see the site running.
In my case, I have not opened the Visual Studio in Admin mode that is why the w3wp.exe was not showing on the list.
When I opened the Visual Studio in Admin mode, it worked.
Right click on Visual Studio -> Open in Admin mode.
In my case, once I rebuild the web project and raise the limit of Connection Time out (in seconds), it automatically shows in Debug/Attach to Process list and keeps working.
I would just like to share my experience as well for future readers.
Be aware that, in the event that you have a web server cluster configuration (for load balancing etc) the w3wp process might not start on the same machine that you expect it to.
Unless your website is configured to only run on a single IIS instance, the w3wp process might be spinning up on one of the other machines inside of your web cluster.
This might be faulty configuration from the networking team/department or intended behaviour. I don't have the neccessary experience to pin point exactly how it should be configured.
Found a related page on MSDN as well:
https://msdn.microsoft.com/en-us/library/bb742600.aspx
In my case, I needed to connect from one Visual Studio to the process which running from another VS studio window.
The problem was next: one VS was launched with Administrator permissions. For resolving that issue you should launch both VS with Admin perm.
In my case, the problem was that I wasn't running Visual Studio as Administrator. My machine had restarted after an update and relaunched all the previously running processes, but had only relaunched VS in non-admin mode. When I restarted VS in admin mode, the w3wp.exe processes were available again for debugging.
Run the remote debugger as an administrator.
I followed every suggestion to resolve the issue, but it was not until I ran the remote debugger as an administrator that I was able to see the w3wp process
Try the following steps:
Create a virtual path from Solution Explorer.
Go to inetmgr to confirm that your own pool is created.
Go to Attach Process (Ctrl+Alt+P) and show processes for all users.
Then you will see w3wp.exe will be there.
Be aware that even after jumping through all these hoops (kicking off an instance using a web browser, starting your remote debugging session as an admin, ensuring that "show all users" is checked, etc., ensuring you aren't on a server farm, etc), you may still at times be out of luck.
There are times when the remote process, usually a WCF service in my case, simply will not show up in the list of processes to attach to, and there's nothing that can be done about it. I'm always careful to make my target process readily identifiable by keeping it and only it in a certain App Pool. Sometimes you just can't get there from here. This is undoubtedly the most frustrating thing about remote debugging Microsoft has ever done.
my answer is late for sure, but maybe my answer will help someone.
Go To IIS.
Application Pools.
Advance Setting.
enable 32.bit Application.
Make your Application Running Under enable 32.bit Application.
There is this one action that is requested using javascript during the loading of a page, it takes over 25 seconds to resolve. Looking at the code makes me think there is a scaling issue, but I am wondering if there is any way I can step through the code during the request so I can see what is happening. I try clicking 'debug/start debugging' but it won't launch the proper URL (access to the site is subdomain based), and it will also not find certain dependencies. I am able to browse the site directly via URL locally after mapping a URL via my hosts file to localhost (127...) but the default url that pops up (localhost...) from debug does not work because it is not formatted properly.
Any ideas?
You can attach the debugger to your browser by selecting "Attach to process" under "Debug" menu.
In the past, at least with ASP.NET we have used tracing to debug issues. You will just need to enable it in the webconfig. If you use warn, the messages will show in red and be easier to spot.