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
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 a .NET Core web API that works fine when hosted in IIS on my local Windows 10 desktop OS. However, when I deploy the same code to a Windows Server 2016 machine, the app pool in IIS fails 5 times and then stops the app pool. The error in the event viewer indicates the following:
A process serving application pool 'My API' reported a failure during application preloading or service loading. The process id was '416'. Please ensure that all application preload or service settings in the application pool are configured properly. The data field contains the error number.
I've tried configuring the API to write out to the stdout, but it doesn't ever generate a log file.
This API was originally written in .NET Core 2.2, so I tried upgrading it to .NET Core 6 and have the same issue - it works in Windows 10 with IIS, but not on Windows Server 2016. The hosting bundle for the appropriate version is installed on the server. I found that if I change the app pool that is hosting my API to have a .NET CLR Version of .NET 4 instead of 'No Managed Code', it then works. All documentation indicates 'No Managed Code' is recommended.
I did actually get it to work at one point with the app pool set to 'No Managed Code'. I ran procmon to see if there were any failures accessing registry keys, system files or folders, etc. and did find that if I copied a few files like webengine.dll, webengine4.dll, and aspnet_rc.dll from the folders they were actually in to folders where procmon indicated it was looking for them in, it then worked. Obviously though I don't want to be copying system files to various locations.
My guess is that something isn't installed on the server or I've misconfigured something as I got the same result when creating a test Web API project in Visual Studio and used the sample endpoints included in the default project. Unfortunately I can't figure out what is missing or misconfigured.
I ran the JexusManager ASP.NET Core Diagnostics tool and this is the report:
System Time: 7/20/2022 8:01:35 AM
Processor Architecture: AMD64
OS: Microsoft Windows NT 10.0.14393.0
Server Type: IIS
Scan 35 installed module(s).
ASP.NET Core module version 2 is installed for .NET Core 3.1 and above: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll (16.0.22173.7).
Scan 91 registered handler(s).
* Found a valid ASP.NET Core handler as { Name: aspNetCore, Path: *, State: Enabled, Module: AspNetCoreModuleV2, Entry Type: Local }.
Visual C++ runtime is detected (expected: 14.0, detected: 14.12.25810.0 built by: VCTOOLSREL): C:\Windows\system32\msvcp140.dll.
The application pool 'Test API' is used.
Pool identity is NetworkService
Please ensure pool identity has read access to the content folder D:\Program Files (x86)\My Company\Test API.
Pool bitness is 64 bit
Scan aspNetCore section.
"processPath": dotnet.
"arguments": .\TestApi.dll.
"hostingModel": inprocess.
In-process hosting model is detected. To avoid 500.xx errors, make sure that the bitness of published artifacts matches the application pool bitness
Framework dependent deployment is detected. Skip bitness check.
Found runtime config file D:\Program Files (x86)\My Company\Test API\TestApi.runtimeconfig.json.
Runtime is 6.0.0.
I did verify the bitness and the folder permissions. Both were set properly.
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.
so after .net core 1.0 got published I started a new console project and imported the code from a small prototype that is supposed to run without IIS. Besides having to use net46 in my project.json due the not-yet updated MongoDB.Driver, that worked fine. When I build the app in Visual Studio a small App.exe with a lot of dll is build and can be run fine locally without IIS.
I then noticed the option to build for IIS Express and thought that I can use the IIS on our server (IIS 6.2, Windows Server 2012 R2) too. It publishes fine with WebDeploy, but nothing happens after that. I was following this official guide. I installed the .NET core Windows Server Hosting bundle and everything appears to be in order, but when I browse to the url, I get a ERR_NAME_NOT_RESOLVED. Theapp.exedoes not appear in the Task Manager and I can't find any log file, although it is enabled in theweb.config. I can execute the app manually, but then it only listens on the defaultlocalhost:5000` address.
If I understood it correctly, the IIS is supposed to act as a reverse-proxy to the dotnet tool which starts a dll, but in my case it's already a compiled exe that works standalone. But I can't figure out how to build a dll from this app..
What am I doing wrong?
If you target full .NET Framework the application will be .exe and not .dll and it is fine. ERR_NAME_NOT_RESOLVED indicates that the url you provided in your browser could not be resolved and the request to the application was not made. AspNet Core Module starts the application on the first request and because the host could not be resolved the request was not made and the application was not started. Once you figure out why the name could not be resolved and you still have issues with making your application work with IIS take a look at my post which explains how things work and how to troubleshoot issues. This, however, only applies after the request can reach your application.
I want to run my ASP.NET 5 (beta7) application in Visual Studio 2015 on a specific domain, mydomain.com for example. How could it be achieved?
Hosting the published version would lose the Visual Studio debuging. Built in IISExpress launch profile do net let domain address change, just port number of localhost address.
EDIT: I've solved the problem with self-host, Microsoft.AspNet.Server.WebListener, but is there a way to do that with Windows IIS 8.5?
Publish your app to the file system and set up an IIS site as described in the documentation. You can use a custom domain if you override routing in the etc/hosts file.
In Visual Studio, go to Debug -> Attach to process
Check Show processes from all users
Find process called w3wp.exe and attach the debugger to it
Now your breakpoints will be hit as if hosted in IIS Express...
For me, I had to attach to the correct dnx.exe process not the w3wp.exe.
I found the correct dnx process by looking at the username it was running under. It was the app pool identity that I assigned the site to in IIS.
Update (2016-09-14):
With the release of .NET Core 1.0, I now must attach to a process that is named the same as my project. Eg. if my project is name TestWebApp then the process I attach to is named TestWebApp.exe.