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.
Related
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'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.
I have a web application asp.net to deploy to Windows Azure. I try to run it on local first. But when debugging, I catch this error from VS2010:
"There was an error attaching the debugger to the IIS worker process
for URL 'http://127.255.0.0:82/' for role instance
'deployment16(6).WindowsAzureProject2.WebApplication3_IN_0'.
Unable to start debugging on the web server ......."
I've search so hard to find the solution for this problem but there's nothing seems work for me. I'm a newbie in Windows Azure, it's really a big trouble with me.
I had similar problem with Windows 8, debuging a cloud application with Visual Studio 2012 RTM and Azure SDK 1.71, when trying to launch the application into the compute emulator. It was a very simple app, but I used Azure diagnostics. At the end these are two things I have changed that have work for me, both turning on Windows 8 features (so go to Win8 and open 'Turn Windows Features On/Off'.
Activate the checkboxes for:
Internet Information Services Hostable Web Core
Internet Information Services > World Wide Web Services > Application Development Features > ASP.NET 4.5
Internet Information Services > World Wide Web Services > Health and Diagnostics > Tracing
Internet Information Services > Web Management Tools > IIS Management Scripts and Tools
That worked for me, it makes sense, as I'm using Visual Studio 2012 and trying to get some trace information using diagnostics in Azure.
I hope this will work for you or give some tip about the problem. In the case of being useful information, remember to vote as response or as value tip.
Thanks,
Mike
This usually happens when there's a problem with the project to be deployed to the emulator (WindowsAzureProject2 in your case).
Try the following:
Check %UserProfile%\AppData\Local\dftmp\IISConfiguratorLogs\IISConfigurator.log file for the error messages. See more details in this answer.
Make sure your project can be started without the emulator. It's a web project, so just try to start it as a regular web project. Or publish it to the separate folder and try to create a website in IIS of it.
Check your *.csdef and *.cscfg files to make sure all the configuration is correct.
Make sure that the build output of your project is not empty. You can do this by going to IIS, find the site with the name similar to deployment16(6).WindowsAzureProject2.WebApplication3_IN_0, right click --> Explore.... Make sure that this folder is not empty and contains all the files required to start a web project successfully.
BTW, there's a similar question: Debugger can't connect when starting local azure project
Follow step 11 from http://www.microsoft.com/en-us/download/details.aspx?id=35448. Worked for me on Windows 8 with Oct 2012 SDk
I just have today the same problem trying to Debug locally with Azure Storage Emulator in Windows 7. So in the Azure project properties, in Web tab, I checked the radio button 'Use IIS Express' and it debugged without problem. I hope this helps someone.
I encountered this exact same problem when I upgraded an existing Azure solution to the Azure SDK 2.1. After some hunting around I uncovered that the upgrade had automatically set the "Local Development Server" setting to "Use IIS Web Server".
Changing the "Local Development Server" setting to "Use IIS Express" fixed the problem immediately.
To access this setting right-click the Azure cloud project file in your solution, select the "Properties" option, tab down to "Web" and you'll see the following setup.
Also, make sure you run Visual Studio as administrator
Please check the version of emulator you have installed. If your code is created in older sdk and you have a new emulator installed it will give you this error.
Check the version of Azure APIs in your project, go to Project > references and right click on Azure dlls to check the version, same sdk version must be installed on the system, higher are optional as azure 2.x are not backward compatible.
We are trying to evaluate and eventually migrate to the windows azure cloud platform.
I am stumbling on the installation process...
I'm currently following this tutorial.
I can't get the Windows development Fabric interface working like on this picture.
When I install the app fabric sdk (downloaded here) I get no .exe program to simulate the cloud...
I installed Windows AppFabric which is not what I need (I think).
I keep on being directed on AppPlatformInstaller which do not install what I need but I'm sure is part of my solution.
You are downloading wrong SDK. For Windows Azure Cloud platform you must download and install Windows Azure SDK And Tools for Visual Studio.
Then you will have a folder %Program Files%\Windows Azure SDK\v1.5\bin. There will be devfabric and devstore folders, under which the local development Frabric and Development Storage executables will reside.
Then if you are targeting .NET based solutions, you will have new project templates in Visual Studio, and everything shall be running smoothly. On the other hand, if you are targeting open source solutions you might want to follow the like provided by Ben.
As for Windows AppFabric - yes, it is wrong in terms that it is not related to Windows Azure at all.
Let us know if you have any issues when downloading and installing latest Windows Azure SDK And Tools for Visual Studio
You may want to check out the docs available from the Microsoft Interoperability Team. They maintain an entire site dedicated to running PHP on Windows Azure
http://azurephp.interoperabilitybridges.com/articles/build-and-deploy-a-windows-azure-php-application
Basically to get it working just install the Windows Azure SDK and with Windows Azure SDK for PHP. Build your PHP application and then run the package command. Your PHP application will be rolled into a Windows Azure project and launched in the local dev fabric
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.