This post was most recently updated on July 26th, 2024.

3 min read.

Yikes – ever ran into this error after deploying your ASP.NET Core web application to an Azure App Service? Yeah, me too. And when it’s a production deployment, and the error didn’t happen in test/QA environment, that’s even more fun. This article describes a couple of ways to fix it, though.

You wouldn’t believe these 3 solutions to fix the error “500.32”, and what they look like now!

Table of Contents

Oh heavens, what have I done with that subheading? All of that time watching Growth Hacking YouTube videos is finally paying dividends in the form of horrifyingly clickbaity headings. At least I didn’t use it as a main heading of this article. Maybe in the next one…

Anyway, back to the topic.

The error message is something like below:

HTTP Error 500.32 - ANCM Failed to Load dll

And the different options I’ve found so far to fix it, are as follows.

4 possible fixes to try. Starting from the obvious, ending with the obtuse. Let’s see how it goes…

Time needed: 15 minutes

How to fix error “500.32 ANCM Failed to Load dll”

Check that your app has the right bitness
The error complains about bitness – and that’s a fair first thing to check. If you’re deploying a 64b application to an app service running in 32b, it’s not going to run.

So, in short, Navigate to App Service settings in your Azure Portal. Then access Configuration > General settings, and check out your “Platform” setting.

This “Platform” setting should match your application’s bitness.
Make sure your hosting model is the correct one
Okay, so enabling InProcess hosting model without proper configuration is going to throw the same error.

This step was brought up by Gunnar Peipman in the comments section, and he’s absolutely correct – I completely forgot about running into this multiple times.

Long story short, if you want to use the new hosting model, make sure you have this in your web.config file:

And make sure you have this property set in your project file:

(WordPress is messing with my code again, so just find the XML copy-pasted below this stupid block)

I’m actually not 100% sure this is required. I fixed a build by adding it, though, so maybe it’ll help someone else as well :)
Try changing your ASP.NET Core handler
This tip is actually also related to the InProcess hosting model – in .NET Core 2.2, when the team introduced it, they also added a new handler that’s required to work with it.

To tell the module versions apart, they added V2 to the name of the old module.

That way, to reference ANCM V2 instead of the old ANCM (Asp Net Core Module), you need to do this:

Open your web.config file, and find the handlers-section. If you have AspNetCoreModuleV2 configured, change it to AspNetCoreModule – or vice versa.

Won’t always help – but easy enough to try!
Remove your Site Extensions
Ah – this one really sucks. Depending on your deployment model, your site extensions might be wrecking havoc on the app service.

Navigate to to your Azure App Service’s settings on Azure Portal > Extensions. Remove the extensions one by one, refreshing the site in between to see if it had any effect.

If you don’t want to remove stuff blindly, you can also browse the event logs of your Azure App Service by navigating to “Diagnose and solve problems” > “Diagnostic tools” > “Application Event Logs”, and maybe find more information about the underlying issue. Maybe even hints about the particular extension causing the issues!

Be mindful, though – you might not be able to install the extensions back easily. Not all extensions are available through the UI, so you might need to install them back using Cloud Shell or Azure DevOps.

The XML for Step 2

Quite often, I feel like using WordPress is roughly as pleasant as shooting yourself in the leg with an air rifle. It’s got so little power it’s not going to kill you, but it’s still a stupid thing to do, and hurts.

Then again, I don’t really want to shoot myself in the leg with anything powerful either. I guess WordPress will do.

<propertygroup>
 <targetframework>netcoreapp3.1</targetframework>
 <runtimeframeworkname>Microsoft.AspNetCore.App</runtimeframeworkname>
 <!-- This is required for self-contained deployment -->
</propertygroup>

That’s all, folks! With any luck, it’ll work now :)

Found another fix to the issue? Let me know in the comments section below!

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)