Unable to load DLL 'libuv' after migrating to Visual Studio 2017

[ghost]

My project was created in VS 2015, targeting net461.

I migrated to VS 2017, now I can't run my application when Targeting Platform is set to x64 or AnyCPU.

works when Targeting Platform is set to x86.

when Targeting Platform is set to x64 or AnyCPU I get this error at this line:
host.Run();

Error

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.DllNotFoundException: Unable to load DLL 'libuv': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_loop_size()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvLoopHandle.Init(Libuv uv)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelThread.ThreadStart(Object parameter)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.Start(Int32 count)
   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.Start()
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(IWebHost host, CancellationToken token, String shutdownMessage)
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(IWebHost host)
   at Api.Program.Main(String[] args)
)

Error is occurring in both IIS Express and IIS.

I want to be able to build and run in IIS either targeting x64 or AnyCPU.

[natemcmaster]

@capiono can you share your *.csproj file?

[BorisDli]

In host.Run();
Error
System.AggregateException: 'One or more errors occurred.'
BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

[natemcmaster]

@BorisDli can you share your *.csproj file? We suspect this is an error in .NET Core SDK, not Kestrel itself, but it's hard to know without a repro.

[BorisDli]

MVCtaghelperscheckboxes.csproj.txt

[natemcmaster]

Thanks, that helps. Your csproj has these lines:

  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>AnyCPU</PlatformTarget>
  </PropertyGroup>

There is a conflict in your project about which CPU architecture to target. The line <RuntimeIdentifier>win7-x86</RuntimeIdentifier> instructs NuGet to use the x86 version of LibUV (a native I/O library used by Kestrel's) and <PlatformTarget>AnyCPU</PlatformTarget> instructs the app to compile as AnyCPU, which means the process may run as x64. This mismatch is likely the source of the error. As @nguerrera points out dotnet/sdk#1017 (comment), this isn't something the SDK currently warns you about --- though hopefully it will in future versions.

I'd recommend removing RuntimeIdentifier unless there is some other reason you need it.

[natemcmaster]

Closing as external to Kestrel. @capiono if you've identified an error not solved by my previous comments, we can re-open for further investigation.

[JanEggers]

@natemcmaster im just hitting this because i wanna get an x86 build for azure.
why nuget has to decide which version of libuv is picked? i dont want to distribute my app as x86 just because of this. we use several native nugets in our project and they all deliver both dlls so we can compile as anycpu.

there are two options:

1. name libuv different based on traget platform
2. (preferred) x86 / x64 build folder in nuget like this https://stackoverflow.com/questions/35179461/adding-x86-and-x64-libraries-to-nuget-package

[davidfowl]

NuGet has new first class features for packaging native assets https://docs.microsoft.com/en-us/dotnet/core/rid-catalog.

[natemcmaster]

why nuget has to decide which version of libuv is picked?

@JanEggers unlike .NET Core, .NET Framework does not provide a built-in mechanism for loading native libraries based on the current process architecture. To workaround this, .NET Framework application typically compile as either x86 or x64. AnyCPU only works if the app is completely managed code. Libuv is native, not managed. As you've suggested, it may be possible for Kestrel to workaround the AnyCPU limitation, but as of 2.0.0 we haven't done this.

[mortb]

I can confirm this issue.
I have an aspnetcore application that is targeting net47.
The libuv dll load problem arises if I have <RuntimeIdentifier>win</RuntimeIdentifier>, but disappears when I change to <RuntimeIdentifier>win-x64</RuntimeIdentifier>

[DalSoft]

Just add <OutputType>Exe</OutputType> when targeting net4x rather than core, and this will work every time. But the problem is exactly as described by @natemcmaster

[Salgat]

For me at least, I had to install Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv (in nuget) to fix this. It was only giving me an issue for Linux, not Windows.

[shieldsjared]

Had to inject <RuntimeIdentifier>win-x64</RuntimeIdentifier> (didnt have it specified at all). This solved it for me. Thanks @mortb

[Tealons]

@Salgat: This one fixed it for me!

[martinmine]

In case you have integration tests (or other dependent projects), they would also need the runtime identifier.

[HebaruSan]

I'm seeing this error on Windows while trying to follow this tutorial:

https://scotch.io/@rui/how-to-build-a-cross-platform-desktop-application-with-electron-and-net-core

Can anyone explain what's wrong with the tutorial? I've read the several closed issues on this repo for this error and the only advice I can understand so far is "use core instead of framework" and "specify x64", which as far as I can tell I've already done. Is some part of the tutorial out of date?

EDIT: OK, after some more experimenting, this works:

        <RuntimeIdentifiers>win7-x64;osx-x64;linux-x64</RuntimeIdentifiers>
        <BaseNuGetRuntimeIdentifier>win7-x64;osx-x64;linux-x64</BaseNuGetRuntimeIdentifier>

And this doesn't:

        <RuntimeIdentifiers>win-x64;osx-x64;linux-x64</RuntimeIdentifiers>
        <BaseNuGetRuntimeIdentifier>win-x64;osx-x64;linux-x64</BaseNuGetRuntimeIdentifier>

I tried using the latter because I don't want my executable bound to a specific version of Windows (and those are all valid values for this field according to the MS docs for it). Is that just misguided? What is the actual effect of choosing a specific version of Windows in this field?