Unable to load Libuv

[rynowak]

This is happening consistently to me on dnx 1.0.0-beta8-15625 x86 CLR and Kestrel 1.0.0-beta8-15636

System.InvalidOperationException: Unable to load libuv.
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.Load(String dllToLoad)
   at Microsoft.AspNet.Server.Kestrel.KestrelEngine..ctor(ILibraryManager libraryManager, IApplicationShutdown appShutdownService, ILogger logger)
   at Microsoft.AspNet.Server.Kestrel.ServerFactory.Start(IFeatureCollection serverFeatures, Func`2 application)
   at Microsoft.AspNet.Hosting.Internal.HostingEngine.Start()
   at Microsoft.AspNet.Hosting.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
   at Microsoft.Dnx.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Dnx.ApplicationHost.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider service

[davidfowl]

This should be fixed with 891b991 but the ci hasn't passed in a few days.

[markentingh]

this is happening to me as well, but I'm using 1.0.0-beta7 Windows 7 x64 coreCLR. It works perfectly fine on my other machine though, using Windows 8.1, same project, same setup.

Update: This is so strange... on my Windows 7 machine, I finally got my project to run, but ONLY using beta7 x86 coreCLR instead of x64!!!!!! Before, yesterday, when my project was using beta5, and before that, using beta4, I ALWAYS dnu restore using x64 architecture, but now I can't dnu restore or dnx kestrel unless I'm using beta7 x86 on my Windows 7 machine... so strange. At least now I can continue my work, even if I have to use x86 architecture.

[mvas]

I have the same issue, kestrel doesn't start when using dnx x86. But it works OK when using dnx x64.
Both are 1.0.0-beta7
Trying on Windows 8 x64

[blackdwarf]

I have the same behavior on Win7 x64 using 1.0.0-rc1-15798 both in x64 and x86 architectures. This machine didn't have any DNXs on it prior to me installing them this morning. Ona another machine, Win10 x64, Kestrel works. However, the Win10 machine had previous runtimes (since beta4) installed on it.

I thought that dnu restore should install all of the dependencies, including the native ones?

[DamianEdwards]

Is this still an issue for anybody?

[mvas]

yes. Now using 1.0.0-beta8 for both x86 and x64
My scenario:

1. change current runtime to desired
2. run yeoman with aspnet generator
3. dnu restore
4. dnx kestrel

Runs ok for x64 and fails to load libuv on x86

[davidfowl]

1. change current runtime to desired

Can you give specific repro steps. Can you also include the OS you're running on? (windows)

[mvas]

I've updated everything from dnvm to npm packages and now I cannot reproduce that.
I'm running on Windows 8 Enterprise x64
now I have

>node --version
v4.2.2
>npm --version
3.4.0
> npm list -g yo generator-aspnet

├── [email protected]
└── [email protected]
>dnvm version
1.0.0-rc2-15539
>dnvm list
Active Version           Runtime Architecture OperatingSystem Alias
------ -------           ------- ------------ --------------- -----
       1.0.0-beta5       clr     x64          win
       1.0.0-beta5       clr     x86          win
       1.0.0-beta5       coreclr x64          win
       1.0.0-beta5       coreclr x86          win
       1.0.0-beta7       clr     x64          win             def64
       1.0.0-beta7       clr     x86          win
  *    1.0.0-beta8       clr     x64          win             default
       1.0.0-beta8       clr     x86          win
       1.0.0-beta8-15724 clr     x64          win
       1.0.0-beta8-15724 clr     x86          win

[ghost]

Edit: nevermind! needed to install Libuv
https://github.com/aspnet/Home/wiki/Getting-Started-Prerequisites-for-Debian,-Ubuntu-and-derivitives

having the same issue on ubuntu 14.04 (in a vm if that matters)
$ node -v
v5.0.0
$ npm -v
3.3.6
$ npm list -g yo generator-aspnet
/home/kev/.nvm/versions/node/v5.0.0/lib
├── [email protected]
└── [email protected]

$ dnvm version
1.0.0-rc2-15539
$ dnvm list

Active Version Runtime Architecture OperatingSystem Alias

---

• 1.0.0-beta8 coreclr x64 linux default

[meriturva]

The same problem here....

• Windows IoT on ARM (Raspberry pi 2)
• 1.0.0-rc2-16177 coreclr arm

.\web.cmd : System.DllNotFoundException: Unable to load DLL 'libuv': The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
    + CategoryInfo          : NotSpecified: (System.DllNotFo...LT: 0x8007007E):String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.NativeMethods.uv_loop_size()
   at Microsoft.AspNet.Server.Kestr
el.Networking.Libuv.loop_size()
   at Microsoft.AspNet.Server.Kestrel.Networking.UvLoopHandle.Init(Libuv uv)
   at Microsoft.AspNet.Server.Kestrel.KestrelThread.ThreadStart(Object parameter)

is it related to: #106 ?

[damienpontifex]

I had this same issue occurring on:

• Windows 10
• 1.0.0-rc1-final

Found the issue may have been caused by the project.lock.json pulling from source control after the dependencies were restored on mac.

so running dnu restore again changed the project.lock.json file and everything worked again on windows.

I have now seen in the aspnet/Home repo that project.lock.json is in the gitignore so will be adding it now after this issue.

[moozzyk]

This issue should be closed - it's hard to tell what it's tracking. It originally was created before we added native dll loading but then we entirely changed the code. Then an error with ARM appeared which I believe is a totally different issue (#340) and there also seems to be a comment about using sources. I believe we should track each of these issue separately.
@rynowak - was your issue resolved? If so, please close this.
@meriturva - watch dotnet/aspnetcore#1111
@damienpontifex - can you open a new issue an provide more details (a minimal repro project would be ideal) and repro steps?

[muratg]

Closing per @moozzyk's comment as there's no update on the bug. Please reopen or file a new one if this is still an issue.

[emfluenceindia]

For me it was never an issue for me before I installed Newtonsoft.Json package using dnu (dnu install Newtonsoft.Json), which added the package to my project and wrote an entry in my project.json as "Newtonsoft.Json": "8.0.1" under dependencies node. After installing the package I ran dnu build which said successful compilation. When I ran dnx web I got the error which was never there!

Here is the full output:

{lamb} dnx web
System.DllNotFoundException: Unable to load DLL 'libuv': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.NativeMethods.uv_loop_size()
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.loop_size()
   at Microsoft.AspNet.Server.Kestrel.Networking.UvLoopHandle.Init(Libuv uv)
   at Microsoft.AspNet.Server.Kestrel.KestrelThread.ThreadStart(Object parameter)

[moozzyk]

@emfluenceindia - I guess that after you installed Newtonsoft.Json and restored packages the project.lock.json file was rewritten and now, for whatever reason, it no longer contains the information needed to find libuv.dll. Hard to pinpoint what the issue is since there isn't enough details in your report.

[jaredthirsk]

I just had the same issue on Windows 7. dnu restore fixed it. (I had just done a dnu install of the user-secrets and options stuff.) I suggest fixing this before RTM as it is not obvious what the problem is.

[emfluenceindia]

dnu restore fixed it for me as well but not before I took out the assembly reference from project.json. And even without the reference in project.json I still could use Newtonsoft.Json in my controller. However, I have version seems to be wrong. I finally used 7.0.0-rc1-final and it gets resolved, no compilation or runtime error. Thanks for your idea!

[yoshiwatanabe]

Copying libuv.dll to the same folder where Microsoft.AspNet.Server.Kestrel.dll exists fixed for me as well.

On my machine COPY

FROM:
C:\Users\<me>\.dnx\packages\Microsoft.AspNet.Server.Kestrel\1.0.0-rc1-final\runtimes\win7-x86\native\libuv.dll

TO:
C:\Users\<me>\.dnx\packages\Microsoft.AspNet.Server.Kestrel\1.0.0-rc1-final\lib\dnx451\

BTW, here is the output of "dnvm list"

• 1.0.0-rc1-update1 clr x86 C:\Users.dnx\runtimes default

[kjbetz]

I just experienced this issue. Brought a project over to a new to me Mac OS X machine. This project previously has been running on another Mac OS X machine, and 4 Windows 7 machines. I believe I set up everything correctly, following the newest instructions in the docs.

Ran dnu restore multiple times. Making sure I deleted the project.lock.json file a few times.

I finally copied the ~/.dnx/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-rc1-final/runtimes/osx/native/libuv.dylib to ~/.dnx/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-rc1-final/lib/dnxcore50/libuv.dylib Then dnx web ran without a hitch.

Running dnx 1.0.0-rc1-update1 coreclr x64 on a Mac OS X Version 10.9.5

Disregard, as noted in #627, this is fixed post RC1. Copying files as I did is the current workaround/fix. Thanks!

[andreshg112]

The previous solution, of @kjbetz, worked perfectly for me on many Macs.
I just did:
cp ~/.dnx/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-rc1-final/runtimes/osx/native/libuv.dylib ~/.dnx/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-rc1-final/lib/dnxcore50/libuv.dylib

Then:
dnx web

[MelbourneDeveloper]

I'm getting this issue even though I have the latest NuGet packages as of right now. I thought this would have been fixed by now. It's been over a year...

[moozzyk]

@MelbourneDeveloper - post the details. This issue relates to dnx so either you are using dnx which is no longer supported or you are hitting an issue that looks the same on the surface but in fact has a different root cause. Just in case clear your caches with nuget.exe locals -Clear all and try again. If this does not help create a new issue and provide details - including project.json, how you publish and run your application and what the exception is.

[MelbourneDeveloper]

@moozzyk , OK. I will do my best. To give you a quick snapshot of what I am doing...

I was working on an xproj ASP .NET Core (.NET Framework) project. But, I was getting too many issues. So, I created a blank csproj ASP .NET Core (.NET Framework) project in VS 2017 and dragged my files in. I then manually bumped the VS version of the csproj back to 14 so I could open the project in VS 2015. I then opened the project and upgraded all the NuGet packages. It compiles but it complains about not having the libuv library. I am trying to run the exe directly from Visual Studio. I'm happy to run it through IIS but I've had no luck getting that to work after following several tutorials.

How can I ensure I have the right version of Kestrel installed, and that IIS is routing the traffic to Kestrel?

[moozzyk]

I think VS2017 is MSBuild only based while VS2015 is still using project.json. I think you might be missing some package references. As I said before - open a new issue and provide a repro - ideally create a github issue containing your project. The details you provided don't allow to tell exactly what's going on.

[MelbourneDeveloper]

@moozzyk , I've been stabbing in the dark with this stuff. xproj+project.json is buggy as hell and Microsoft are going to ditch it anyway so I've switched over to csproj.

I have discovered that the problem is that the Libuv DLL is not being copied to the output bin folder. When I manually copy the file in to the output bin folder, the web server starts up correctly. The Libuv reference is included in my packages.config file (not project.json), but it doesn't automatically copy. It also does not show up as a referenced DLL under references in the project.

I can log this as an issue, but where? Which repo would I be logging this? I know that this is an MSBuild related issue. Is that where I should be logging this?

[muratg]

@MelbourneDeveloper, just curious, do you have Shared Runtime installed on the machine that you're trying to run your app on? libuv.dll should be in the shared runtime so I don't think you'll need it in your bin folder. As long as you have a reference to Kestrel (project.json or *.csproj, based on the SDK you're using) libuv dependency should come transitively, and since it's already on disk as part of the shared runtime, it should just work...

[MelbourneDeveloper]

@muratg , Sorry, I don't know what you mean by "Shared Runtime". I've installed and uninstalled so many versions of ASP .NET Core and its related tools that I no longer know what remnants are installed on my machine. I've tried to remove older versions in vein. The uninstall process just fails. This is what my installed components looks like:

https://dl.dropboxusercontent.com/u/79781769/Images/Forums/.NET%20Core.png

it should just work...

Yes. That would be lovely.

PS: This is the line from my packages.config:

<package id="Microsoft.AspNetCore.Server.Kestrel" version="1.1.0" targetFramework="net46" />

[DamianEdwards]

@MelbourneDeveloper Why do you have a packages.config file? I don't think the copying of native dependencies (like libuv) works without using project.json or the new CSPROJ in VS2017 which uses <PackageRef />.

Opening a CSPROJ you created in VS2017 in VS2015 after changing the tools version is not supported in this case. The CSPROJ system in VS2017 contains all-new features that are required for the .NET Core experience to work correctly. Those projects are not round-trippable between VS2017 and VS2015.

Also, you mentioned you're trying to run the exe directly from Visual Studio? Which exe, your app?

[davidfowl]

This looks like trying to use ASP.NET Core in a non xproj project type. While it's possible it's not really supported. If you want to make it work with packages.config then you need to manually copy libuv into the output folder. If you use xproj + project.json this works automagically. If you use the vs2017 csproj tooling it will work as well.

[MelbourneDeveloper]

@DamianEdwards

Why do you have a packages.config file? [...]I don't think the copying of native dependencies (like libuv) works without using project.json

Is that a rhetorical question? Sorry to be facetious but we've nothing but issues with xproj, and as soon as I mention the issues anywhere, on any of these repos, the response is always the same: xproj is being ditched in favour of csproj. I've been repeatedly told not to bother reporting problems with xproj because it's dead in the water.

The CSPROJ system in VS2017 contains all-new features that are required for the .NET Core experience to work correctly.

Not necessarily. Running a .NET Core App is just a matter of running "dotnet.exe" and pointing it at your compiled code. It works fine in VS 2015 as a csproj file.

If you want to make it work with packages.config then you need to manually copy libuv into the output folder.

Correct. I'll just wait until Visual Studio 2017 is more stable and then my whole team will upgrade.

If you use xproj + project.json this works automagically.

As I've mentioned above, we have numerous issues with xproj that make it literally impossible to perform development. @davidfowl , I think you were the person who told me that xproj is going to be scrapped. I think Microsoft should clear this up. If xproj is being ditched, Microsoft should provide documentation on how to run ASP .NET Core with csproj, finish off VS 2017, or fix the issues in xproj. Until this happens, people will be deterred from using ASP .NET Core because of all the tooling issues they face.

[neonboxx]

This appears to be an happening again, with the reintroduction of CSPROJ, After converted a solution and building, i got a few warnings about targeting x86 on a 64bit OS, so i looked in the build configuration and saw that it was set to 32 explicitly, so i changed it to Any CPU. After which i got the libuv dll issue.

Edit: the warnings only showed as I still had dotnet-test-nunit installed.

[davidfowl]

If you're still seeing issues with the new sdk based csproj. Make a repository on GitHub that shows the problem.

[danielcrabtree]

I've encountered the same issue with ASP.NET Core projects after upgrading to VS2017 and csproj.

When the project targets 'Any CPU', I get System.DllNotFoundException: Unable to load DLL 'libuv' when running against Kestrel and HTTP Error 502.5 - Process Failure when running against IIS Express.

When the project targets 'x86' or 'x64', everything works fine.

Looks like this might be related to dotnet/sdk#316

[DamianEdwards]

I'm not seeing this issue. Can you paste your csproj files here please?

[danielcrabtree]

This csproj was created by File / New Project / Web / ASP.NET Core Web Application (.NET Framework) and then going to Project Properties / Builder tab / changing Platform target to 'Any CPU'.

Changing AnyCPU to x64 or x86 fixes the problem. By default it is set to x86 on a new project.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net452</TargetFramework>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>AnyCPU</PlatformTarget>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
  </ItemGroup>
</Project>

[neonboxx]

@DamianEdwards My files are at work, sorry, one thing I've noticed looking at @danielcrabtree csproj is that we are both targetting aspnet45x (mine is on 451) could be a factor causing this?

[DamianEdwards]

OK this repros for me now, thanks. This is indeed an issue only when targeting .NET Framework rather than .NET Core.

[danielcrabtree]

@neonboxx net45x is not the problem. I get the problem on net462 as well.

The csproj above is just a simple repo I made starting from a new project. The original project where I encountered this is targeting net462.

[neonboxx]

net4xx then, as @DamianEdwards said full .NET Framework 👍

[Jon12345]

@DamianEdwards can issue this be reopened? In addition to @danielcrabtree's comment, I'm seeing the issue with x64 as well. Only x86 works correctly.

I'm targeting .NET Framework because I only need to run on Windows but I wonder if targeting .NET Core is a better tested/supported scenario.

[DamianEdwards]

@Jon12345 why do you need to explicitly set the "Platform Target" to "AnyCPU" out of interest?

[Jon12345]

@DamianEdwards no I don't - I only became aware of this after adding a new "Unit Test Project (.NET Framework)" which defaults to "Any CPU" and doesn't like the mismatch.

But my understanding is x64 is better than x86 for a number of reasons, so would prefer to target that.

[DamianEdwards]

Ping @nguerrera as this could very possibly be an SDK/project system bug.

[nguerrera]

We need better diagnostics here for platform target and runtime identifier mismatch. We have bugs tracking that. I'll link when I get to the office this afternoon.

You can simply remove the RuntimeIdentifier from the project and then choosing platform target from the dropdown will work.

We should update the template to not hard code the RID. I thought that had been done already but apparently not.

[nguerrera]

Aside: x64 is not necessarily better than x86. If you need the extra memory, then use it if course, but if you don't you may see worse performance from the larger pointer size reducing locality.

[Jon12345]

Removing RuntimeIdentifier from the csproj and then changing target to x64 does indeed work, although I had to do a "dotnet restore" first.

Does Visual Studio's "Rebuild Solution" not restore? Got the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5): error : Assets file ...\obj\project.assets.json' doesn't have a target for '.NETFramework,Version=v4.6.2/win7-x64'. Ensure you have restored this project for TargetFramework='net462' and RuntimeIdentifier='win7-x64'.

[nguerrera]

It should have auto-restored, cc @natidea

[natidea]

Some changes that affect the set of "configured projects" (e.g. changes to target frameworks) are not restoring properly because of mismatches in our configured project versions. We are tracking this investigation in: dotnet/project-system#1503
However, this case looks like it should have restored properly if my understanding is correct. When addressing dotnet/project-system#1503 I'll check to see if the root cause is the same.