Self-contained .net core 3.1 app giving hostxfr.dll not found (even though it is in the current directory)

[srothkin]

Description

I have a win-x64 app which is C++ calling a C++/CLI .Net Core DLL which is in turn calling a C# .Net core 3.1 DLL (which in turn uses Microsoft.Data.SqlClient). It works fine on my development computer (in Visual Studio 2019). I copy the .exe and all of the DLLs (including runtime from dotnet publish selfcontained) to another machine (which doesn't have Visual Studio OR the .net core runtime installed). The exe crashes with hostxfr.dll not found even though it is in the current directory (alongside the exe).

Configuration

• .Net Core 3.1
• Build machine: Windows 10
• Test machine: Windows Server 2012 R2 Datacenter
• x64

Regression?

• Unknown - first time trying this. Previous build of product was with Visual Studio 2015 and .Net Framework 4.5 and with all runtimes installed on machine rather than distributed with code.

Other information

I've setup the C++ exe and C++/CLI projects to copy all of the dependencies to the target directory and the C# project post build step has

dotnet restore -r win-x64
dotnet publish "$(ProjectFileName)" -r win-x64 --no-build -c $(ConfigurationName) -o $(OutDir) --no-restore -p:PublishReadyToRun=true --self-contained true

When I run it with set COREHOST_TRACE=1 I get

Can't open the SDK installed location registry key, result: 0x2
Using global installation location [C:\Program Files\dotnet] as runtime location
.
A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [].
If this is a framework-dependent application, install the runtime in the global
location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable t
o specify the runtime location or register the runtime location in [HKLM\SOFTWAR
E\dotnet\Setup\InstalledVersions\x64\InstallLocation].

The .NET Core runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win81
-x64
Failed to start the .NET Core runtime. Error code -2147450749

I tried setting DOTNET_ROOT=the target dir name -- that didn't help. I tried removing the ready-to-run flag and rebuilding - that didn't help either.

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

[srothkin]

Tried set DOTNET_MULTILEVEL_LOOKUP=0
that also didn't help.

[vitek-karas]

C++/CLI loads the managed code using native hosting APIs as a component. Currently we don't support self-contained components. I'm not surprised this doesn't work. I think that on the machine which has VS (And thus has globally installed .NET Core) it probably runs as at least partially framework dependent (or it's some weird mix of things, because this is something the hosting layer is not prepared to handle).

I assume you construct the folder with everything manually (merge the output of .NET Core SDK with some other files, right?).

@jkoritzinsky can confirm if self-contained C++/CLI is supported.

[srothkin]

Yes - automatically through project settings/scripts. Here are the relevant project/script files:
DotNetClasses - Copy.csproj.txt
DotNETWrapper - Copy.vcxproj.txt
Redir32 - Copy.vcxproj.txt
PostBuild - Copy.cmd.txt
Redir32 - Copy.sln.txt

If I install the runtimes from https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-desktop-3.1.8-windows-x64-installer and https://aka.ms/vs/16/release/vc_redist.x64.exe is that expected to fix the problem? Or do I have to roll back to .net framework 4.8 instead of .net core 3.1?

I was hoping to completely avoid runtime installations (by going self-contained) because that would have to be done across over 20 different servers. We use Octopus for automated deployment of our services, but runtime installations have to be done through separate deployments because they can trigger reboots and Octopus isn't good with waiting for reboots to complete.

[jkoritzinsky]

Self contained C++/CLI is not currently supported.

[agocke]

Closing as unsupported

[vitek-karas]

Using framework dependent model should work (runtime is preinstalled on the machine).

The only scenario which is self-contained and includes C++/CLI which is supported is where the application starts as a managed .NET Core self-contained application, and eventually it loads the C++/CLI component. The C++/CLI component is still framework dependent in this case, but it gets the runtime/framework from the running app.

You could achieve the same result by using native hosting APIs to start the self-contained runtime in the process and then use C++/CLI. In .NET 5 there's a way to do this: see the design doc specifically the parts about get_function_pointer.
This let's you have the application as native (C++).

In 3.1 there's no way to do this through native hosting APIs, only the approach of starting the app as managed app will work.