I've tried using the standard Blazor template app to remote debug on an Azure app service and I get the following error:(the app run fine if a compile to release, though not debugging of course.)
I compile to debug any CPU.
UPDATE
I can debugger in my .razor pages.
PRIVIOUS
Judging from your error message, the problem may be caused by unsuccessful release of some files and other factors when the program was released.
In order to solve your problem, you can tell us the version of Visual Studio you are using and how you created the project. This problem is mostly related to your development tool environment configuration.
Here is a suggestion, test it by yourself and it runs normally.
Visual Studio 2019 Enterprise Edition (other versions should also be normal)
Configuration before project release
Start remote debugging
The final result
Related
I followed this tutorial to create a simple web job in Azure: https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-get-started. The web job itself does its job, consumes the message in the queue and I see them appear in Application Insights.
However, I want to debug the function on my local machine by using the tools available in Visual Studio 2022.
I have published with following profile settings:
Next I've attached the debugger under het Hosting menu:
First thing I noticed is a message about no symbols being loaded when putting a breakpoint in the function:
When I add a message to my queue, it gets consumed by the web job but the breakpoint is never hit. I've been reading a lot of similar questions regarding a this issue but I'm not progressing any further.
In Azure Portal, I've enabled Remote debugging under Configuration > general settings
In Visual Studio 2022, I checked if the correct process is attached
Here I'm a bit confused thou, the connection target is connecting through port 4024, which is according to this document, the port for Visual Studio 2019. However, a connection target with port 4026 is not found.
What am I missing here? Am I forgetting another setting somewhere?
If have tried changing the stack setting .NET version from APS.NET V4.8 to NET 6 (LTS) but that didn't help.
Should the platform architecture match the architecture of my machine in order to get it to work? Or is this not linked in any way with the debugger?
Is there anything else that I should check or try? Because my hair is turning grey here :)
Apologies for the delay here!
It should be 4024 for both 32 and 64 bit.
See this Azure doc: Remote Debugger Ports on Microsoft Azure App Service
Typically, the error “The breakpoint will not currently be hit. No symbols have been loaded for this document.” -- This error message indicates we can start debug process and attach, but cannot set a breakpoint on any or some lines of code in the project.
Most, likely cause: Application is built without debug symbols or debug symbols are not available
Kindly try these steps:
Verify Debug Symbols are being used and published and in sync
Workaround the issue by disabling “Enable Just My Code” from the
Tools >> Options >> Debugging >> general menu in Visual Studio
Other things to narrow-down the issue:
Debug symbols must be available locally or deployed to the Azure App Service, and must match the local code you are trying to debug.
It is recommended to use Cloud Explorer over Server Explorer to
connect and debug which requires the Azure SDK.
You could optionally Manually Attach a Debugger to Azure Web Apps to troubleshoot this further or recommend this as a workaround.
(old blog, try similar steps)
Kindly verify the port (Visual Studio remote debugger port assignments ) required is open in the corporate firewall and on your local machine.
As a test, you may use tool like Wireshark/netmon, to see if the port successfully connects to the port (4024) needed by the process.
I'm trying to remote debug an asp.net core 1.1 api app (targeting .net framework 4.5.2) that's running on Azure.
I attach the debugger via Server Explorer. The debugger attaches to the correct process. But any breakpoint I set has the message "The breakpoint will not currently be hit. No symbols have been loaded for this document."
All answers I've seen to such a problem assume that the modules window shows all modules loaded by my project, but in my case the modules window is empty!
I'm on VS2017 15.4.
If I remember correctly, I was previously able to remote debug the same project with version 15.2. The problem started occurring when I updated to 15.3 but I didn't pursue it at the time.
I submitted the problem on the MS forums: Can't remote debug Azure API app
and now I have received an official reply that it is indeed a bug in VS, and a fix will be available in the pending release (15.6).
They also suggested a workaround, which I tried and indeed worked: Manually Attach a Debugger to Azure Web Apps
Which involves:
Going to the web app Application settings in the Azure portal, and making sure that Remote debugging is enabled,
In the VS menu: Debug > Attach to Process..., entering the web app url with the debugging port, e.g.:
myapp.azurewebsites.net:4022
Then in the credentials that appears, entering the username & password that are available in the app's Publish Profile, which can be downloaded from the portal. If the username is $myapp, it should be entered like this:
$myappp\$myapp
Then choosing Managed(v4.6, v4.5, v4.0) code and then the name of the Core app.
Actually, I had found and unsuccessfully tried similar approaches before. The key for me was step 3. The others had suggested entering the username as .\$myapp, or myapp\$myapp. So make sure to enter it as written above.
BTW, seeing that the above blog post is from almost 2 years ago (Feb 2016), whereas the problem I'm experiencing was introduced only a few months ago, it seems to be a cure-all, and it is therefore worthwhile, for anyone who has to deal with remote debugging Azure apps, to save this information for future reference.
UPDATE:
After updating VS 2017 to version 15.5.2 the problem seems to have been fixed.
I have had the same issue with Visual Studio 2019. The fix for me was just to go in the VS menu: Debug > Attach to Process, and try to connect as describe by #Dan Z. The connection was not established, saying No connections found, but attaching a debugger from Cloud Explorer again, right after an attempt in "Debug > Attach to Process" is always successful. That is most probably a bug in VS
I have had webdeploy running for YEARS on a Windows Server 2012 machine with standard MSBuild arguments (like this).
Yesterday I installed the Windows (Server Hosting) version of the .NET Core Installer from the .NET Core downloads page.
Since then my build tasks are running and successfully building my website, but not actually running any web deploy publishing. It is not failing - it is just not being run.
I want to stress I am talking about a 'legacy' .NET application - not a .NET Core application. I just installed .NET Core for somebody else.
I can verify this with the following observations:
There are no errors in any event viewers (except ones that are months old)
There is no message in the msbuild logfile that says Start Web Deploy Publish, however log files from just a couple days ago do have this message.
I can connect to the local server at port 8172 and it makes a connection.
It is happening with multiple projects that nobody else has access to.
_PublishedWebsites does get created with the latest files - it just never gets deployed anywhere.
What could possibly have broken this? Did the Windows Server Hosting package break it - or was it just some other update that came in? I've run out of ideas how to fix it and don't want to revert to xcopy!
Managed to fix it :-) Not sure exactly which of these steps did it, but I suspect it was Visual studio.
I was using TFS Express 2015 and upgraded to Update 3.
I also installed Visual Studio 2015 on the server itself.
I had previously had .NET Core RC2 (or whatever they called it at the time) installed and I uninstalled that before installing .NET Core RTM. Wondering if that removed some component that was required.
Like I said everything was working fine before I installed the .NET Core RTM - but fortunately installing VS and TFS brought everything back to normal.
I am running my mvc project in visual studio 2013 no errors comes in debugging and all projects build up successfully. after it when visual studio run the project and launch IIS express process it got crashes with following error which comes in result window.
The program '[13280] iisexpress.exe' has exited with code -1073740771
(0xc000041d). The program '[13280] iisexpress.exe: Program Trace' has
exited with code 0 (0x0).
I also re install visual studio reset its all settings problem still exist.
I also check whether iis is working ok? I deployed the websites on iis and they are working fine, Only the websites which i run from visual studio did not work and gives upper mention error message.
I solved my problem myself... I make a couple of changes which solved my problem, Steps are as follows....
Uninstall IIS
1.1. Go to control panel-> Programs and features -> Turn Windows Features On or Off.
1.2 De-select Internet Information Services and Internet Information Services Hostable Web Core.
1.3 Restart the system.
1.4 Go to My Documents and delete folder "IISExpress".
Install IIS again
2.1. Go to control panel-> Programs and features -> Turn Windows Features On or Off.
2.2 select Internet Information Services and Internet Information Services Hostable Web Core.
2.3 Restart the system.
this solved the problem.
I recently converted a mingw/cygwin build to a Visual C++ cl.exe build and upon initial testing found it crashes at launch. I then installed it in my developer environment to debug it, under which it runs just fine. My initial suspicion was that I was linking to a different DLL in that context, but examining both processes in both contexts with Process Explorer showed that they were using the same versions of the same DLLs.
Since I can't reproduce the issue with Visual C++ installed I installed the remote debugger on the client machine, but I can't manage to attach to the process quickly enough before it crashes. Is there a good way to go about doing this? This would be easy if I could launch the process under the debugger locally, but that doesn't look like a viable option here.
Any help would be greatly appreciated. Thanks for your time!
You should be letting the remote debugger start the debugee process on the remote machine.