Kestrelhttpserver: Kestrel for .csproj doesn't copy libuv to output

[fubar-coder]

In VS 2017 RC, libuv still isn't copied to the output folder (see #696). Any timeframe when msbuild supports copying native DLLs to the output folder?

My test case was:

• Create a .NET 4.5.2 project
• Copy the source files from an ASP.NET Core project to the .NET 4.5.2 project
• Install all required ASP.NET Core packages
• Create a Debug/x64 build configuration
• Try to run the project

I really hope that this problem wasn't forgotten, because the original issue was closed (without a solution).

[davidfowl]

You need to use a new style csproj to make that work.

[fubar-coder]

Will there be a way to convert old style csproj files to the new style?

[davidfowl]

Manually in vs2017, there won't be a tool or ui in the short term.

[sandersaares]

Do I understand the comments above right that this still won't work out of the box in VS 2017 RTM? It is not clear to me what the relationship is between VS version and csproj type.

[davidfowl]

Do I understand the comments above right that this still won't work out of the box in VS 2017 RTM? It is not clear to me what the relationship is between VS version and csproj type.

If you use an ASP.NET Core project or a .NET Core project then it'll work out of the box.

See the templates below under the .NET Core tab in VS 2017 (RC)

If you want to go old school and use ASP.NET Core in a .NET Framework Console app or a WPF application then you need to do some extra work:

1. First go to NuGet settings and turn on PackageReference mode, this replaces packages.config:
   (if you're unaware of the implications there's a doc on nuget about this).
2. Then change the mode.
   
3. Then install Kestrel from the package manager dialog.
4. Edit the csproj and add these properties (adjust the RID to suit, x86 or x64):
   xml <PropertyGroup> <RuntimeIdentifier>win7-x86</RuntimeIdentifier> <BaseNuGetRuntimeIdentifier>win7-x86</BaseNuGetRuntimeIdentifier> </PropertyGroup>
5. Profit.

[sandersaares]

Thank you for the step-by-step instructions! I hope this how-to will be in the documentation so that it is nicely discoverable to everyone who wants to use Kestrel in a .NET Framework app!

[davidfowl]

@sandersaares using kestrel in a .NET Framework application that isn't using the new project system isn't a mainline scenario.

[sandersaares]

Perhaps I misunderstood something. I am happy to use "the new project system" whatever that is, if it helps me use Kestrel in my .NET Framework Console Application project.

I did not realize there were multiple paths to reach this goal - can you point me to the right steps to follow in order to use the new project system in this scenario? I assumed using VS 2017 would be enough to use any new project system but clearly I was mistaken.

[davidfowl]

The new project system isn't enabled for older project types by default. You can use it for a console application if that's what you're building. There is also no template for a .NET Console Application for .NET Framework. I'd just recommend using the ASP.NET Core template for .NET Framework:

[xyntiacat]

Just wanted to leave a comment for anyone coming to this in the future - this error happens on a project using the new template for .net core with an angular client if the build platform target is Any CPU. Select either x86 or x64 and it works, but select Any CPU and it shows up again.

[drauch]

@davidfowl : Thank you for your instructions. Could you elaborate a bit more on point 4? What are those two settings doing to my project? Why do I have to set them to get libuv copied to the output? What are the consequences of changing those settings? Is this going to get "fixed" in a future version of VS2017 so that I do not have to manually edit my csproj anymore? Thank you for the workaround, still, I'm one of those guys who want to know about WHY something is working. Would be very glad to hear something from you.

[davidfowl]

Could you elaborate a bit more on point 4? What are those two settings doing to my project?

Libuv is a native component and you need to specify a runtime identifier so that the right implementation gets copied to your output folder. .NET Core doesn't have this problem. In .NET Core, the runtime natively understands runtime identifiers (RID https://docs.microsoft.com/en-us/dotnet/core/rid-catalog), so you can copy all implementations to the output folder and the runtime will pick the "right one".

What are the consequences of changing those settings? Is this going to get "fixed" in a future version of VS2017 so that I do not have to manually edit my csproj anymore?

There are no plans to fix this for .NET Framework. It's sorta the nature of things when you bring native components into the picture on .NET Framework. The runtime isn't aware of them, so the burden is pushed into doing the right thing at build time. Unfortunately, that means knowing the runtime identifier up front.

With SDK projects (the new style slim csproj), we try to infer the RID so you don't need to specify anything by default.

When we Kestrel moves to use sockets by default, these problems should go away (for kestrel). Other native components (for e.g. SQLite) would still have the issue.

[drauch]

Thank you for your reply and the background information on the topic. One last question though, as it does not come up in the linked docs for RIDs: what is the BaseNuGetRuntimeIdentifier doing? Why do I have to set this property too, why isn't setting the RuntimeIdentifier property enough?

Thanks in advance & all the best from Vienna!

[davidfowl]

One last question though, as it does not come up in the linked docs for RIDs: what is the BaseNuGetRuntimeIdentifier doing? Why do I have to set this property too, why isn't setting the RuntimeIdentifier property enough?

https://github.com/NuGet/Home/issues/4558

[drauch]

Thanks!

[adailsonfilho]

@davidfowl,

You said:

With SDK projects (the new style slim csproj), we try to infer the RID so you don't need to specify anything by default.

So... if I have:

• csproj (new slim type)
• ASP.NET Core 1.1
• .NET framework 4.6.1

I should be able to target AnyCPU? Or the simple fact there I'm using .NET Framework prevents it?

Thanks!

[natemcmaster]

AnyCPU continues to be problematic. Setting PlatformTarget=AnyCPU defer the question of CPU arch until the application is launched. For native components like libuv, .NET Framework apps must manually detect the process architecture at launch and load the right native library. .NET Core does this automatically.

FYI - https://github.com/aspnet/libuv-package/issues/21 - there is ongoing discussion about supporting AnyCPU propertly from libuv. This isn't exactly a kestrel issue, though it commonly surfaces through using kestrel.

[ColinM9991-zz]

What exactly is the fix for this? I am trying to unit test NET Standard package and keep running into System.DllNotFoundException: Unable to load DLL 'libuv': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

This is how my default test library csproj PropertyGroup looks,

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{CC4E1E25-620B-42FE-8A50-0C31E1066DBC}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>IdentityServerHost.Tests</RootNamespace>
    <AssemblyName>IdentityServerHost.Tests</AssemblyName>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
    <BaseNuGetRuntimeIdentifier>win7-x86</BaseNuGetRuntimeIdentifier>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
  </PropertyGroup>

This is what my NET Standard csproj default PropertyGroup looks like

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net462</TargetFrameworks>
    <Platforms>x64;x86</Platforms>
  </PropertyGroup>

I have also changed my runtime from AnyCPU to x86, with no luck.

[TechnikEmpire]

@ColinM9991 If you absolutely need to target both, clone the csproject and make two x86/x64 project files exclusively. This happens IIRC at the nuget restore stage. So once you add the package, it's going to pull down the libuv native payload for the current project architecture only as a referenced package.

Alternatively, manually download libuv here, include the native libraries as output to something like xcopy /Y /d [source.dll] "$(TargetDir)\x86\libuv.dll" and xcopy /Y /d [source_64.dll] $(TargetDir)\x64\libuv.dll and then make a static constructor somewhere early on in the execution pipeline of your application that appends AppDomain.CurrentDomain.BaseDirectory + @"\x86\" (and same for x64) to the PATH environmental variable. This will enable .NET to dynamically resolve the correct library for the correct architecture.

Alternatively you can point and laugh at life over the fact that people who create disasters like this in programming work as elite engineers at the elite companies of the world and then cry over the fact that the guy who didn't get the job because his parents didn't send him to an expensive paper mill wouldn't have made such blunders. Also, watch out for the self driving cars they're also programming.

[davidfowl]

2.1 defaults to sockets which wont have these problems.

[ColinM9991-zz]

@davidfowl 2.1 of what? also is defaulting really a fix, or a workaround?

@TechnikEmpire thank you for your info, I have partially settled with copying libuv manually to the output directly but will look at your alternative during the weekend.

[davidfowl]

2.1 of ASP.NET Core