This post was most recently updated on December 12th, 2019.Reading Time: 2 minutes.
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:
This value (or similar) is required for a self-contained ASP.NET Core deployment. And I’m sure there’s a few other reasons why you might need it in the file.
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.
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 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.
Eh, well – long story short, it’s this easy. Change the RuntimeIdentifier to this (or similar, I’d suppose):
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 :)
Latest posts by Antti K. Koskela (see all)
- Azure Functions host quits with “The system cannot find the file specified” - January 22, 2020
- How to extract more information out of your Azure Functions host failing silently? - January 22, 2020
- WordPress media uploads failing after year/month change? Easy fix :) - January 14, 2020