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.
Related
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
I have an Azure WebJob that I am publishing to an App Service. The problem I am having is that I want to target the x86 platform but when I publish the WebJob and attach to the App Service, it's always listed as x64.
I set the platform target to x86 for all of my solution configurations. There is only one solution platform. I even have RuntimeIdentifier in the publish scipt set to "win7-x86". I have no idea what I could possibly be missing.
The App Service is set to run on a 32-bit platform in the Application Settings.
AFAIK, the default worker process for your web app is 32-bit. In order to check the current environment of your web app, you could leverage KUDU.
For platform 32-bit:
For platform 64-bit:
Details you could access https://{your-app-name}.scm.azurewebsites.net/Env.cshtml.
For your webjob, you could use the Process explorer as follows:
For platform 32-bit:
For platform 64-bit:
In general, I would recommend you delete your existing webjob and redeploy it, then use the kudu to check the environment to narrow this issue.
There is no direct approach to find out the Webjob process bitness from the Azure Portal or KUDU console. To determine it, you would need to collect the memory dump manually from the KUDU and this blogs covers it http://jsandersblog.azurewebsites.net/2017/02/02/how-to-get-a-full-memory-dump-in-azure-app-services/
Once the memory dump is collected for the Webjob process, you would need to open it in Windbg and run the following command:
Here is the command to check the process bitness:
0:000> !peb
NUMBER_OF_PROCESSORS=4
PROCESSOR_ARCHITECTURE=x86
WEBSITE_COMPUTE_MODE=Dedicated
WEBSITE_SKU=PremiumV2
0:000> .effmach
Effective machine: x86 compatible (x86)
Alternatively, you can open (just drag and drop) the dump in the Visual studio to see this information:
So, Webjob was concluded to be running as x86 bit.
In my case I wanted to run it x64 bit ness and this WebJob was deployed via VSTS built pipeline and missing the Platform argument. After setting that up to x64 the Webjob now runs x64 bit successfully.
Im using IIS 8.5 on Windows Server 2012 R2 so I add my Web Api but when I try to view the site it stays in a loading state like this:
Do not show any message or error just stays loading, I think that i miss some configuration or feature in my IIS but I don't know which one.
Edit: I use .Net framework, it is a REST .net web api like this reference, the IIS have installed .Net versions 3.5 and 4.5, it's IIS not the express and the default IIS website runs fine.
I would really appreciate any help.
Try to reduce the timeout settings to a minimum level, say 10 seconds.
See if it throws a Timeout error.
Without much information from your side its hard to judge.
Perhaps it could be an external service you are trying to access(Web service) or a DB connection?
Please check if the application pool you assigned to your solutions runs under the correct version of .net framework and in integrated mode. I had similar issues when trying to run an mvc app in classic mode. Check this out.
EDIT 1 - Reconfiguring IIS
If problems persists then try the ASP.NET IIS Registration tool. Execute the followig command as administrator:
aspnet_regiis -i
At the end of this post the different locations for aspnet_regiis are described. You should select a .NET Framework version corresponding to that of your project, run aspnet_regiis and assign the proper application pool to your app.
I have been having trouble making a request to my 64-bit ASP.NET Core API running on an Azure App Service. The error I get back is:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '***.dll'. An attempt was made to load a program with an incorrect format.
I understand that this means there is a mismatch between the platform of the app (64-bit) and that of the environment it runs on. I just can't figure out how to change the App Service so it runs using 64-bit.
In the Application Settings in the Azure portal I have set Platform to 64-bit:
However when I check in Kudu, the runtime environment indicates that it's operating under win8-x86:
project.json
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true,
"platform": "x64"
},
"runtimes": {
"win10-x64": {}
}
Some questions
How do I change the App Service to ensure it's running on a 64-bit platform?
Does it matter that the RID is win8... when my runtimes configuration in project.json specifies win10.... Presumably x86 vs x64 matters, but does it need to be the same version of windows too ie. win8 vs win10.
This is now available in Azure App Service.
Steps to deploy:
Set platform to 64-bit in portal
Ensure the project targets 64-bit by including the following in the csproj:
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
When publishing application ensure target framework is set to win-x64. (If running dotnet publish just add -r win-x64)
The documentation is here but (at present) it is acknowledged to be a little sparse.
This github issue response suggests we should be able to do a framework dependent deployment and have it "just work". YMMV but that wasn't my own experience hence the runtime flag suggestion above
TLDR; 64 bit .NET core processes using the .NET core runtime (as opposed to the .NET Framework runtime) are not yet supported on Azure but is planned to be coming in the future.
The following is from discussions I had with Microsoft Azure support.
The 64bit/32bit configuration on Azure portal (shown above in my screenshot), controls the IIS w3wp.exe process. The w3wp.exe process forwards requests to your NET core process. The configuration doesn't control the bitness of the .NET core process. It's a bit confusing, but explains why changing the Platform option in the screneshot above had no affect.
Based on the PATH environment variable setting of app service, dotnet.exe is mapped to the 32bit one, which is "D: \Program Files (x86)\dotnet\dotnet.exe". The 64bit runtime of .NET core is not pre-installed in app services, as a result, it is currently not available.
Microsoft is planning to add 64-bit support to .NET core applications running on the .NET core runtime in Azure but it depends on a future update of the .NET core tools chain. They gave me an estimated internal date but I promised I wouldn't share that publicly.
A workaround they gave me was to use the ASP.NET core (using .net framework) visual studio template, not the ASP.NET core (using .net core) one. That one loads the 64bit .Net framework runtime for your ASP.Net core web application. This will require a bit of migration work and I assume may not be possible for some projects.
Fortunately I was able to swap to 32 bit versions of some of my dependencies which meant the app worked in the Azure environment. Sadly this won't mean much to those that don't have this option, and I'm sure there are many.
If you need a 64 bit runtime, there are 4 ways to do this:
Deploy a self-contained application
Deploy your own runtime
Use Linux Azure App Service
Use Web Apps for Containers
See more details on how to do it in the link below:
https://blogs.msdn.microsoft.com/webdev/2018/01/09/64-bit-asp-net-core-on-azure-app-service/
Credits to: Glenn Condron
dotnet publish command generates a web.config file which is used by IIS to start dotnet process. In Kudu, in PATH environment variable dotnet.exe is from D:\Program Files (x86)\dotnet
Solution is to replace in this file after build
<aspNetCore processPath="dotnet" arguments=...
with:
<aspNetCore processPath="%ProgramFiles%\dotnet\dotnet" arguments=...
I think profiling an application deployed to Azure is not a big deal http://msdn.microsoft.com/en-us/library/hh369930.aspx
I'd like to do the same locally, in the Compute Emulator. It looks like this is currently difficult http://www.pettijohn.com/2011/05/performance-testing-azure-dev-fabric.html at best, at least with the native VisualStudio 2010 profiler.
Am I missing a simple way to do this? Are there any third-party tools that make this fairly easy to do?
I'm using the Azure SDK 1.4 and Azure Tools for Visual Studio 2010 1.3
For later versions of the SDK you can refer to this article in the Windows Azure documentation, where it is explained how to do CPU sampling for both worker roles and web roles: for the latter case, you should attach to the WaIISHost.exe process.
As also indicated in the answer from Marcus Jansson, you may need to attach to the w3wp.exe process. For example, when I'm debugging one of the web sites contained in a web role I need to explicitly attach to the w3wp.exe process that is hosting that site, since Visual Studio does not attach automatically to all relevant IIS instances.
UPDATE 2013-01-10 19:03 UTC I was unable to profile web roles using the linked instructions. I discovered that:
it is useless to attach to WaIISHost.exe, since it seems that it doesn't contain the role code;
I cannot attach to w3wp.exe instances from Visual Studio 2010 (I receive an error message with code VSP1449).
Since I'm using Windows Azure SDK 1.8, I then tried to run my web role under IIS Express (see this post for further details) and then I attached to the iisexpress.exe process. This way I was able to profile my web site.
If you run the web role in IIS, you can just attach to the process w3wp.exe.
I think it depends on what you're trying to profile.
The link you included in your question is for profiling memory for a web role, and yes it looks a little involved.
If you're looking to profile a worker role, it's much easier. You can simply start the worker role through Visual Studio (or using the method mentioned in the post you linked to if you're worried about the effect of the debugger on the profiling) and select Analyze -> Profiler Attach/Detach -> WaWorkerHost. From there it should look just like profiling any other application.