EF Core fails to load hostpolicy.dll when RuntimeIdentifier is win-x86
I ran into another interesting one when working with a .NET Core 3.0 project and Entity Framework Core - this time, RuntimeIdentifier configuration causing trouble. In short, running Update-Database (to apply code-first migrations to your local database) locally would return this, annoying error:
Failed to load the dll from [runtimepath]\win-x86\hostpolicy.dll], HRESULT: 0x800700C1
An error occurred while loading required library hostpolicy.dll from [runtimepath]\win-x86\]
I suspect this can happen with any x86 runtimeIdentifier, but the one I had specified in my .csproj-file was this:
win-x86
This value (or similar) is required for a self-contained ASP.NET Core deployment. And I'm sure there are a few other reasons why you might need it in the file.
RuntimeIdentifier in a .csproj file. With a few other hacks, unfortunately. :)
And obviously, you could be running into this when you're running Update-Database for Entity Framework Core in PowerShell or something.
Description
Table of Contents
Table of Contents
My investigation led me to this issue on GitHub, which proposes a solution - but alas, the solution they had (changing the RuntimeIdentifier as follows) didn't work for me.
<RuntimeIdentifiers>win10-x64;win7-x86</RuntimeIdentifiers>
While it sounds like it worked for some users, it really didn't for me. Instead I got a new error:
The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(PublishDir)" evaluates to "bin\Debug\netcoreapp3.0\win10-x64;win7-32x\publish\" which is not a scalar value. C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
This, as seen below in a screenshot, was especially funny because I was definitely not using Visual Studio 2017 - but instead, Visual Studio 2019, which is required to get Blazor development going at all!
The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(PublishDir)" evaluates to "bin\Debug\netcoreapp3.0\win10-x64;win7-32x\publish\" which is not a scalar value. C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
The error above blocked me from building anything in Visual Studio.
Also, since I'm packaging the solution as a self-contained application, I would probably run into this as well: https://github.com/dotnet/cli/issues/10474
So overall, I had to find a runtime identifier that would let me use the Entity Framework Core code-first migrations.
Solutions
Time needed: 5 minutes.
How to fix "Failed to load the dll from [runtimepath]\hostpolicy.dll, HRESULT: 0x800700C1
An error occurred while loading required library hostpolicy.dll.."
Edit the .csproj -file in Visual Studio
This is how you get to it on Visual Studio's Solution Explorer:
And if you're in VS Code, just open the .csproj -file :)
Change your RuntimeIdentifier
Okay - this one might be a bit weird. But long story short, it might be this easy. Change the RuntimeIdentifier to this (or similar, I'd suppose):
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
While this could easily have side effects, you actually don't need to check this change in at all. Just revert it before committing your changes - or even just after adding the new migration :)
Didn't help? Change to RuntimeIdentifier_s_ (plural) instead!
Alternatively - as Martin points out in the comments -section below, you could also try simply changing
to (plural), and see if that helps! So, essentially something like this:
<RuntimeIdentifiers>win-x86</RuntimeIdentifiers>
And there we go! Did it work for you or not? Let me know in the comments section below!
References
There are a bunch of related issues on GitHub. If you want to read about the background, check these out:
Comments
dotnet ef migrations add
. Your proposed solution, to change fromwin-x86
towin10-x64
was not possible in my case since my app depends on x86 libraries. But today I found the issue and workaround by looking very carefully into different people's csproj code. So I want to share it here: If using<RuntimeIdentifier>
, hostpolicy-issue occurs, if using<RuntimeIdentifiers>
(plural), everything works fine. That also explains the "HasTrailingSlash"-problem.