#SharePointProblems | Koskila.net

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog
>

EF Core fails to load hostpolicy.dll when RuntimeIdentifier is win-x86

koskila
Reading Time 3 min
Word Count 537 words
Comments 2 comments
Rating 5 (1 votes)
View

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.

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

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 "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.."

  1. Edit the .csproj -file in Visual Studio

    This is how you get to it on Visual Studio's Solution Explorer:
    "Edit Project File" in Visual Studio Solution Explorer

    And if you're in VS Code, just open the .csproj -file :)

  2. 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 :)

  3. 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

Interactive comments not implemented yet. Showing legacy comments migrated from WordPress.
Martin Schneider
2021-11-05 12:47:12)
Hey, I came here multiple times when fighting the "hostpolicy.dll" issue for a long time when trying to perform dotnet ef migrations add. Your proposed solution, to change from win-x86 to win10-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.
Antti K. Koskela
2021-12-17 23:28:21
Hi Martin, Thanks for your comment! That's a fair point, even though I was able to resolve this one easily, it doesn't work for everyone. Your solution sounds way prettier - I'll add it to the article. Thanks for your contribution!