Native assets are not copied to bin on build and application fails to run

[BillHiebert]

Create an empty ASP.NET Core application targeting DotNet 4.52. Run the application. Project fails to run because of the following. Looking in the output folder I see that libuv.dll was not copied there
nhandled 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.Libuv.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 WebApplication1.Program.Main(String[] args)

[dsplaisted]

It looks like the problem may be that CopyLocalLockFileAssemblies is set to false in Microsoft.NET.Sdk.BeforeCommon.targets, which disables the ResolveLockFileCopyLocalProjectDeps target.

EDIT: Nevermind, that was when running on .NET Core. Continuing to investigate...

[dsplaisted]

In the project.assets.json file, libuv.dll is listed under the runtimeTargets section of the Libuv package. This creates a FileDependencies item with the FileGroup metadata set to RuntimeTarget:

      Libuv/1.9.0/runtimes/win7-arm/native/libuv.dll
              assetType=native
              FileGroup=RuntimeTarget
              ParentPackage=Libuv/1.9.0
              ParentTarget=.NETFramework,Version=v4.5.2
              rid=win7-arm

Meanwhile, the PackageDependencyResolution targets file is looking for items with the FileGroup metadata set to NativeLibrary, RuntimeAssembly, or ResourceAssembly (which correspond to native, runtime, and resource in the project.assets.json file.

@rrelyea @yishaigalatzer What does the runtimeTargets section in the lock/assets file indicate? Is there any documentation for what all the different sections (mirrored in the properties of LockFileTargetlibrary) mean?

[davidfowl]

Packages can include rid specific assets (fat package). This is what libuv does. Runtime targets express that intent in the assets file. With portable applications on .NET Core, all of these assets for all rids are copied to the output folder and the runtime understands how to pick the most appropriate ones. In the case of .NET .Framework, the loader only understands the the flat directory layout. To accommodate for that, the runtime targets need to be filtered to the appropriate Rid when using .NET Framework, so the appropriate rid specific assets are copied to the output.

I'm not sure why it says win7-arm but I'm guessing that's wrong 😁

[dsplaisted]

Currently the targets are set up to copy items from the native, runtime, and resource sections under the path targets\<TFM>\<PackageID> in project.assets.json. So it sounds like it should also copy from runtimeTargets. But since I don't see any documentation for what these means, I'm trying to figure out whether it should continue to copy from all the sections it is currently copying from, and whether there are any other sections besides runtimeTargets that it's missing.

win7-arm was just the first item, there are also items for win7-x64 and win7-x86.

[eerhardt]

When we redesigned build and publish for .NET Core on MSBuild, we assumed build would always build and run "portable" apps. Then when you publish, you can choose whether to publish for portable or self-contained, and if you publish for self-contained, then you can pick a RID.

This allowed us to remove the "runtimes" section from project.json when migrating to .csproj.

However, we overlooked desktop projects when coming up with this design. Do desktop apps always need a RID? What happens if I want to build my app for "Any CPU"? Which native assets should get chosen? (I don't think project.json supported desktop "Any CPU" projects - if you didn't have a runtime the CLI would infer one for you: https://github.com/dotnet/cli/blob/1278e9d6bf35500e9672fe3f53125df1d08717d8/src/Microsoft.DotNet.ProjectModel/ProjectContextBuilder.cs#L298-L312).

@piotrpMSFT @livarcocc @nguerrera - We will need to rethink how we handle desktop projects w.r.t. Runtime Identifiers.

[eerhardt]

In my local web project, if I add the following line to my .csproj:

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

and then dotnet restore3 and dotnet build3, I get libuv.dll copied to my build output directory.

@BillHiebert - can you try that workaround? If it works, maybe there is some defaulting of RIDs we can do for desktop apps. Or maybe desktop apps always need to specify the RID...?

[BillHiebert]

Adding win7-x64 fixes the libuv failure, but now I see the following - likely related to #315

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Could not load file or assembly 'Microsoft.AspNetCore.Routing, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.ConfigureDefaultServices(IServiceCollection services)
at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.AddMvcCore(IServiceCollection services)
at Microsoft.Extensions.DependencyInjection.MvcServiceCollectionExtensions.AddMvc(IServiceCollection services)
at WebApplication2.Startup.ConfigureServices(IServiceCollection services)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.AspNetCore.Hosting.Internal.ConfigureServicesBuilder.Invoke(Object instance, IServiceCollection exportServices)
at Microsoft.AspNetCore.Hosting.Internal.ConfigureServicesBuilder.<>c__DisplayClass4_0.b__0(IServiceCollection services)
at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.ConfigureServices(IServiceCollection services)
at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
at WebApplication2.Program.Main(String[] args)

[dsplaisted]

@BillHiebert To fix the FileLoadException, can you try adding the following property to the project?

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

[BillHiebert]

Fixes the warnings during build, and fixes the assembly load issue, but has a new problem. I verified that I am running the 64bit dotnet.exe and the runtime identifier is win7-x64. I guess the wrong libuv.dll was copied to bin

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.NativeMethods.uv_loop_size()
at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.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 WebApplication2.Program.Main(String[] args)

[BillHiebert]

Based on the timestamps and filesize it seems to have copied the win7-x64 version of libuv. Could this be related to building AnyCpu?

[eerhardt]

The bitness of dotnet.exe doesn't matter. All dotnet.exe does is ensure the project is built and then spawns a new process for your app's .exe.

What architecture does your app target?

[eerhardt]

Or the other thought is to change x64 to x86 in your .csproj. Does that make it run?

[eerhardt]

In the CLI we defaulted the Platform to x64 if we were compiling from an x64 CLI, and the project was an EXE targeting desktop:

https://github.com/dotnet/cli/blob/1278e9d6bf35500e9672fe3f53125df1d08717d8/src/dotnet/commands/dotnet-compile/ManagedCompiler.cs#L84-L90

anycpu32bitpreferred if building from an x86 CLI.

See https://github.com/dotnet/cli/issues/2428 for more details.

[dsplaisted]

This is fixed. We updated the templates to set the RuntimeIdentifier to win7-x86 and updated the targets to infer the PlatformTarget from the RuntimeIdentifier.

[JoseFMP]

Still happening over here, same problem.

[nguerrera]

@jose-cf please open a new issue with your repro steps. I cannot reproduce it with the original repro steps.