Loading hostfxr.dll fails (apparently)

[tvidvei]

I have made an add-In buildt with .NET 6.0.11 and with Excel DNA 1.6.1-beta1. The add-in is built as an FDD (Framework Dependent Deployment) application. The Add-In runs fine on my machine which has .NET 6 SDK installed. But on a users machine it fails during initialization with the following error message:

The user machine has .NET Desktop Runtime 6.0.11 installed. The results from the command "dotnet --info" reveals no problem with that installation:

What can cause the failure of load_hostfxr()? Some places it is said that the .NET6 SDK (!) must be installed on user's machine in order to have .NET6 applications to run. E.g. here: https://www.thecodebuzz.com/self-contained-vs-framework-dependent-deployment-hostfxr-fdd-vs-scd/. To me this sounds strange. Why do we have .NET6 Runtime if the SDK is needed also by end users?

My question: Any clue on what causes the error (failure of load_hostfxr())? And how to fix it?

[govert]

You should only need the .NET 6 runtime, not the SDK.

One reason for load failures has been anti-virus programs blocking Excel-DNA add-in. Maybe you could check that a bit.
There's also a possibility that another add-in or Excel has loaded a different version of the .NET core runtime (v5 or v7) into the process - that would block loading .NET 6 which Excel-DNA requires.'

If none of these seem to be the issue, please write back - I'd be keen to help figure out what is going wrong.

[tvidvei]

Thank you for your answer, Govert. I posted my question (actually by a mistake) also on Discussions under GitHub/dotnet/runtime. See: dotnet/runtime#79391. The answer I got there, solved the problem: The client machine had .NET 6 Desktop Runtime x64, but was lacking the x86 (32-bit) version. What confused me is that most machines in our organisation has 32bit MS Office installations (and hence 32 bits Excel), while all machines are themselves 64 bits. I thought (mistakenly) that 64 bits .NET 6 Runtime library was required on a 64 bits machine. But when targeting 32bits Excel, .NET Desktop Rutime x86 is required. (I hadn't even noticed that dotnet Runtime for x86 was present on my machine since I had all my attention toward the 64bit installation, which I took for granted that was the .NET Runtime that was used by my Add-In. Then it became a mystery why it wouldn't work on a client machine that had the same Runtime version installed...)

It think it might be helpfull to have some remarks on these platform issues in the Getting Started documentations for Excel DNA.

[govert]

Oh great - I didn't even think about that! We'll have a look the error message and add some documentation for this.

[tvidvei]

I also noticed the following about the .NET Runtime, that adds to the confusion: On my machine, I have, as mentioned before, both 32bit and 64bit versions of the .NET Core and its successors like .NET6. If I run the command "dotnet --info" it is barely mentioned in one line "deep down" in the output, that another architecture (x86) is installed. If I, on the other hand, run the c:\program files (x86)\dotnet\dotnet.exe --info, I get the proper info about the x86 version of the Runtime installed. If you are not used to these platform issues, you are easily lost!

[Hydraxize]

Trying to revive this issue as I’ve got exactly the same problem with my user machines. That happens even with the arch-simple ExcelDna “SayHello” example:

using ExcelDna.Integration;
namespace Dna6;

public class MyFunctions
{
    [ExcelFunction(Description = "My first .NET function")]
    public static string SayHello(string name) =>  "Hello " + name;
}

My machine loads Dna6-AddIn.xll without any issue while the user machine has the error that @tvidvei has posted. I first thought .Net 6 runtime was missing on the client but you can see below it is installed.

Here is a comparison of the User vs Dev profile:
User

.NET Command Line Tools (2.1.202)

Product Information:
 Version:            2.1.202
 Commit SHA-1 hash:  281caedada

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.202\

global.json file:
  Not found

Host:
  Version:      6.0.14
  Architecture: x64
  Commit:       2a90daa2cc

.NET SDKs installed:
  1.1.7 [C:\Program Files\dotnet\sdk]
  1.1.14 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 1.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Download .NET:
  https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info

Dev

.NET SDK:
 Version:   7.0.302
 Commit:    990cf98a27

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.302\

Host:
  Version:      7.0.5
  Architecture: x64
  Commit:       8042d61b17

.NET SDKs installed:
  5.0.301 [C:\Program Files\dotnet\sdk]
  7.0.302 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  arm64 [C:\Program Files\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Both machine uses same Excel version: Microsoft® Excel® for Microsoft 365 MSO (Version 2208 Build 16.0.15601.20676) 32-bit

I’ve tried everything and looked online but apart from this thread I can’t find any help on this error. To give a bit of feedback on our project, we are trying to migrate our ExcelDna solution from .Net Framework 4.7.2 to .Net 6.0 and we’ve just spotted this problem. Is there anything we're missing on the client side to get the add-in running?

[govert]

@Hydraxize I think the problem is that you only have the 64-bit version of the .NET 6 runtime installed, but on the problem machine you are running the 32-bit version of Excel. On your development machine you have both 32-bit and 64-bit versions of .NET installed (that part under 'Other architectures found').

[Hydraxize]

Thank you for the suggestion @govert. We're working on deploying .Net Runtime 32-bit on our user machines and will post an update after testing.

[Meowfit]

Thank you for the suggestion @govert. We're working on deploying .Net Runtime 32-bit on our user machines and will post an update after testing.

Does it work?

[Hydraxize]

The 32-bits runtime has to go through the entire validation process before being installed on the user network (it's frustrating but that how it is, the security and integrity of our infrastructure is paramount). Last time I've checked this process was at final stage so hopefully I'll be able to test it in the next couple of days. I'll post the result as soon as I got them.