New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to load Libuv #216

Closed
rynowak opened this Issue Sep 21, 2015 · 48 comments

Comments

Projects
None yet
@rynowak
Member

rynowak commented Sep 21, 2015

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 comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Sep 21, 2015

Member

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

Member

davidfowl commented Sep 21, 2015

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

@markentingh

This comment has been minimized.

Show comment
Hide comment
@markentingh

markentingh Sep 22, 2015

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.

markentingh commented Sep 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mvas

mvas Sep 28, 2015

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

mvas commented Sep 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@blackdwarf

blackdwarf Oct 3, 2015

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?

blackdwarf commented Oct 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Nov 3, 2015

Member

Is this still an issue for anybody?

Member

DamianEdwards commented Nov 3, 2015

Is this still an issue for anybody?

@mvas

This comment has been minimized.

Show comment
Hide comment
@mvas

mvas Nov 4, 2015

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

mvas commented Nov 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Nov 4, 2015

Member
  1. change current runtime to desired

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

Member

davidfowl commented Nov 4, 2015

  1. change current runtime to desired

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

@mvas

This comment has been minimized.

Show comment
Hide comment
@mvas

mvas Nov 6, 2015

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

├── generator-aspnet@0.0.81
└── yo@1.5.0
>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

mvas commented Nov 6, 2015

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

├── generator-aspnet@0.0.81
└── yo@1.5.0
>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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 8, 2015

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
├── generator-aspnet@0.0.81
└── yo@1.5.0

$ dnvm version
1.0.0-rc2-15539
$ dnvm list

Active Version Runtime Architecture OperatingSystem Alias


  • 1.0.0-beta8 coreclr x64 linux default

ghost commented Nov 8, 2015

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
├── generator-aspnet@0.0.81
└── yo@1.5.0

$ dnvm version
1.0.0-rc2-15539
$ dnvm list

Active Version Runtime Architecture OperatingSystem Alias


  • 1.0.0-beta8 coreclr x64 linux default
@meriturva

This comment has been minimized.

Show comment
Hide comment
@meriturva

meriturva Nov 21, 2015

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 ?

meriturva commented Nov 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@damienpontifex

damienpontifex Nov 24, 2015

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.

damienpontifex commented Nov 24, 2015

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 comment has been minimized.

Show comment
Hide comment
@moozzyk

moozzyk Nov 24, 2015

Contributor

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 aspnet/Home#1111
@damienpontifex - can you open a new issue an provide more details (a minimal repro project would be ideal) and repro steps?

Contributor

moozzyk commented Nov 24, 2015

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 aspnet/Home#1111
@damienpontifex - can you open a new issue an provide more details (a minimal repro project would be ideal) and repro steps?

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Dec 3, 2015

Member

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.

Member

muratg commented Dec 3, 2015

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.

@muratg muratg closed this Dec 3, 2015

@emfluenceindia

This comment has been minimized.

Show comment
Hide comment
@emfluenceindia

emfluenceindia Dec 29, 2015

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)

emfluenceindia commented Dec 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@moozzyk

moozzyk Jan 4, 2016

Contributor

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

Contributor

moozzyk commented Jan 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jaredthirsk

jaredthirsk Jan 5, 2016

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.

jaredthirsk commented Jan 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@emfluenceindia

emfluenceindia Jan 6, 2016

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!

emfluenceindia commented Jan 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@yoshiwatanabe

yoshiwatanabe Jan 28, 2016

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

yoshiwatanabe commented Jan 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kjbetz

kjbetz Apr 6, 2016

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!

kjbetz commented Apr 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@andreshg112

andreshg112 Apr 10, 2016

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

andreshg112 commented Apr 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Nov 22, 2016

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

MelbourneDeveloper commented Nov 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@moozzyk

moozzyk Nov 22, 2016

Contributor

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

Contributor

moozzyk commented Nov 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Nov 22, 2016

@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?

MelbourneDeveloper commented Nov 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@moozzyk

moozzyk Nov 22, 2016

Contributor

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.

Contributor

moozzyk commented Nov 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Nov 22, 2016

@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?

MelbourneDeveloper commented Nov 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Nov 22, 2016

Member

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

Member

muratg commented Nov 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Nov 22, 2016

@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" />

MelbourneDeveloper commented Nov 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Nov 22, 2016

Member

@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?

Member

DamianEdwards commented Nov 22, 2016

@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 comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Nov 22, 2016

Member

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.

Member

davidfowl commented Nov 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Nov 23, 2016

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

MelbourneDeveloper commented Nov 23, 2016

@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 comment has been minimized.

Show comment
Hide comment
@neonboxx

neonboxx Mar 9, 2017

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.

neonboxx commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Mar 9, 2017

Member

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

Member

davidfowl commented Mar 9, 2017

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

@danielcrabtree

This comment has been minimized.

Show comment
Hide comment
@danielcrabtree

danielcrabtree Mar 9, 2017

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

danielcrabtree commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 9, 2017

Member

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

Member

DamianEdwards commented Mar 9, 2017

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

@danielcrabtree

This comment has been minimized.

Show comment
Hide comment
@danielcrabtree

danielcrabtree Mar 9, 2017

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>

danielcrabtree commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@neonboxx

neonboxx Mar 9, 2017

@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?

neonboxx commented Mar 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 9, 2017

Member

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

Member

DamianEdwards commented Mar 9, 2017

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

@danielcrabtree

This comment has been minimized.

Show comment
Hide comment
@danielcrabtree

danielcrabtree Mar 9, 2017

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

danielcrabtree commented Mar 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@neonboxx

neonboxx Mar 9, 2017

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

neonboxx commented Mar 9, 2017

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

@Jon12345

This comment has been minimized.

Show comment
Hide comment
@Jon12345

Jon12345 Mar 22, 2017

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

Jon12345 commented Mar 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 22, 2017

Member

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

Member

DamianEdwards commented Mar 22, 2017

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

@Jon12345

This comment has been minimized.

Show comment
Hide comment
@Jon12345

Jon12345 Mar 22, 2017

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

Jon12345 commented Mar 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Mar 22, 2017

Member

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

Member

DamianEdwards commented Mar 22, 2017

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

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Mar 22, 2017

Member

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.

Member

nguerrera commented Mar 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Mar 22, 2017

Member

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.

Member

nguerrera commented Mar 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Jon12345

Jon12345 Mar 22, 2017

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

Jon12345 commented Mar 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Mar 22, 2017

Member

It should have auto-restored, cc @natidea

Member

nguerrera commented Mar 22, 2017

It should have auto-restored, cc @natidea

@natidea

This comment has been minimized.

Show comment
Hide comment
@natidea

natidea Mar 23, 2017

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.

natidea commented Mar 23, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment