Is it possible to debug an asp .net core 5 beta web app running on azure? I've been getting this error since I tried to do this.
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'blahblahblah.azurewebsites.net'. The connection with the remote endpoint was terminated.
at Microsoft.WebTools.Azure.VS.Operations.IDebuggerInternal120.ConnectToServer(String szServerName, VsDebugRemoteConnectOptions[] pConnectOptions, CONNECT_REASON ConnectReason, Int32 fIncrementUsageCount, IDebugCoreServer3& ppServer)
at Microsoft.WebTools.Azure.VS.Operations.RemoteDiagnosticsSessionBase`1.ConnectToServer(String site, String user, String password)
I've had similar challenges on .netcore5 with exact same error message. I've checked all the criteria like DEBUG build, having the right App Service Plan Level, ensuring remote debug is enabled in Azure, using both Cloud Explorer as well as the classic Attach Process, toggling Deployment mode (framework vs. self contained) even ensuring ensuring matches of 32 vs 64 bit server/client and running VS2019 in admin mode.
Been chasing this all weekend but am planning to just set it aside and try again when .net5 has moved out of (early access) status
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 have deployed a few ASP.Net Core app (only microservices) each on a different Local ISS Site with differente TCP ports (eg. http://localhost:650X).
Now I want to debug such services with VS17 but currently I cannot hit any breakpoint.
If a test a service (eg. Postman) it gives me a 200OK response but VS is still giving me "No symbols have been loaded...". I built the solution with 'Debug' configuration, anyCPU and published method 'Debug', 'FileSystem', .Net 47. How can I solve this issue ?
I had a look at the publishing directory and I can see .pdb files.
Let me now if more information are needed.
Thanks a lot
I am using Azure App Services For Linux Containers. I have followed their instructions to enable SSH (https://learn.microsoft.com/en-us/azure/app-service/containers/configure-custom-container#enable-ssh).
This works but it doesn't expose SSH on a public port. You have to go through their interface so I have no clue how I am meant to setup up VSDBG.
The remote debugging instructions are here: https://github.com/Microsoft/MIEngine/wiki/Offroad-Debugging-of-.NET-Core-on-Linux---OSX-from-Visual-Studio
It works by connecting visual studio to a process on server via SSH.
Seeing as Azure is a Microsoft product I must assume there is a way with their ecosystem to connect to a debugging session but I can't find the doc that says how to do it.
How do I debug linux containers in App Services?
edit:
I discovered cloud explorer in VS2017 and it has an attach option but it gives error:
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'gardner.azurewebsites.net'. The input data was not in the expected format or did not have the expected value.
at Microsoft.VisualStudio.Debugger.Interop.Internal.IDebuggerInternal120.ConnectToServer(String szServerName, VsDebugRemoteConnectOptions[] pConnectOptions, CONNECT_REASON ConnectReason, Int32 fIncrementUsageCount, IDebugCoreServer3& ppServer)
at Microsoft.VisualStudio.Web.Azure.MicrosoftWeb.Operations.RemoteDiagnosticsSessionBase.ConnectToServer(String site, String user, String password)
I think I need to modify container
edit:
I found example for making it work on windows image: https://blogs.msdn.microsoft.com/azuredev/2019/01/30/debugging-docker-containers-attaching/
I need to figure out how to do same thing in linux
The problem
IIS ASP.NET Core module is unable to start an ASP.NET Core 2.0 app.
Browser: HTTP Error 502.5 - Process Failure
Windows Event Log: Application ‘MACHINE/WEBROOT/APPHOST/AppSite’ with physical root ‘C:\inetpub\apps\AppFolder\’ failed to start process with commandline ‘C:\inetpub\apps\AppFolder\App.exe’, ErrorCode = ‘0x80004005: 1’.
ASP.NET Core Module Log: Log file is created but is empty.
The setup
App: ASP.NET Core 2.0 targeting .NET Framework 4.6.1.
Server: Windows Server 2012 R2 Standard 6.2.9200 with IIS 8.5.9600.
The story
We've created a blank MVC Web application using the default project templates provided in Visual Studio 2017.
The app is deployed following the official specification: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/.
The confusion arises mainly from these two points:
Running the app through command-line on Kestrel works.
Running a different app but targeting .NET Core 2.0 and publishing as framework-dependant works flawlessly on IIS.
But between these two apps: the codebase is the same, the IIS website and application pool is the same and we even emptied out the app directory and used the same one.
Due to these points the only difference seems to be the net461 app's executable file.
We do not have full control over the Windows Server where we're trying to deploy but we do have administrator accounts. The current assumption is that the issue lies within permissions - maybe AD group policies, antivirus blocking the file but we're still awaiting response from the client's sysadmins. Meanwhile we haven't been able to replicate the error code ‘0x80004005: 1’ while trying to setup these restrictions on our development machines.
Here's an incomplete list of ideas and points about the issue we've tried while problem solving:
The initial app (targeting net461) works flawlessly on IIS when
deployed to other servers (Windows 10 Enterprise, Windows Server 2012
R2 Datacenter).
Reinstalling different versions of ASP.NET Core/.NET Core: Runtime & Hosting Bundle.
Setting NTFS permissions to the dotnet folder.
Changing IIS application pool identity to an administrator account.
Restarting the server.
Going over local group and security policies.
Going over the antivirus settings and logs.
Trying to deploy on a brand new server (same OS, same bloat).
All ideas/comments are greatly appreciated. The more obscure the better.
EDIT:
Since this got flagged as a possible duplicate of ASP.NET Core 0x80004005 I need to specify why that is not a duplicate.
That referenced project is an older version of ASP.NET Core (last use
of project.json was in 2016)
That referenced project targets .NET Core and not .NET 4.6.1. It is mentioned here as well that targeting .NET Core works on IIS in regard to this issue.
Selected answer points out that they fixed it by:
Turns out that this was result of needing to install some windows
updates and this problem:
api-ms-win-crt-runtime-l1-1-0.dll is missing when opening Microsoft
Office file
Rather than install the version discussed in the above issue I whet
into Programs and Features and ran a repair on Microsoft Visual C++
2015 Redistributable.
but the installation of Microsoft Visual C++ 2015 Redistributable is one of the steps in the official setup guide and it is mentioned here as well that the official guide has been followed during the setup process.
We have gone over that post and tried to repair and reinstall the Microsoft Visual C++ 2015 Redistributable runtime components and this did not fix the issue.
If anyone stumbles upon this post in the future:
The problem was indeed in the server's antivirus. It wasn't directly blocking the app's executable but its call to a class library in the system folder. This termination did not raise any of the usual alarms.
The application "C:\inetpub\apps\AppFolder\App.exe" attempted to load the library "bcrypt.dll" by calling the function "LoadLibraryExW". The operation was blocked and the application terminated.
After switching the MVC blank app to a completely blank Hello-World app it ran successfully.
I'm trying to debug an ASPNET Core/EF Core website hosted on Azure. When I try to attach the debugger in VS 2015, via Cloud Explorer, I get this error message:
Yet when I check the site in the Azure portal, it sure seems like it's 32 bit and set to enable remote debugging:
So what am I missing or doing wrong?
Portal setting controls the bitness of the IIS w3wp process. But ASP.NET Core runs in its own process, so that setting has no effect on it. Instead, what determines whether your .NET Core process runs as 32 or 64 bit is how you publish it.
Given that apparently your Core project is published as 64 bit, you might want to try switching the Portal setting to 64 bit. This will affect the debugger MSVCMON.exe process, which should then allow you to attach.