Error LNK2019: unresolved external symbol _get_hostfxr_path@12 referenced in function _load_hostfxr

Hello, first of all I want to congratulate with the author. This is the only library that got me up and running. Unfortunately I am experiencing (what I believe to be) the same issue reported here. I am trying to build two separate x86 and x64 dll. x64 compiles fine, but the x86 fails with the following errors: Error LNK2019: unresolved external symbol _get_hostfxr_path@12 referenced in function _load_hostfxr Even if I export with [UnmanagedCallersOnly(CallConvs = new []{typeof(System.Runtime.CompilerServices.CallConvCdecl)})] it still fails with the same error. The project is a simple .Net 5 library containing the following function:

[UnmanagedCallersOnly()]
public static int Run(IntPtr parameters)
{
      return 0;
}

I am only interested in Windows 10, but I also need x86 architecture working. I am running the latest VS2019 with the latest Windows SDK available in its installer (19041). May be I’m missing something obvious, but after looking the documentation for hours without understanding what I am doing wrong I have no other choice than ask for help. Many thanks

[netcorefan1]

Oh my God! The fix was so easy and obvious! The x86 version of .Net 5 was not installed. It’s just that when someone is going to install the SDK they mostly go with the x64 thinking that it only relates to their OS architecture. Now it’s working, but I had hard time to find a working configuration and this is the one that only worked:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net5.0</TargetFramework>
                <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
                <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
                <EnableDynamicLoading>true</EnableDynamicLoading>
                <!--Compile first x64 and then x86 through dedicated targets-->
                <Platforms>x64</Platforms>
                <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers>
    </PropertyGroup>

    <!--Set x86 configuration when compiling x86, otherwise DNNE will fail!-->
    <Choose>
            <When Condition=" '$(Platform)'=='x86' ">
                <PropertyGroup>
                    <TargetFramework>net5.0</TargetFramework>
                    <PlatformTarget>x86</PlatformTarget>
                    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
                </PropertyGroup>
            </When>
    </Choose>

    <Target Name="BuildX86" AfterTargets="Build" Condition=" '$(Platform)' == 'x64' ">
        <MSBuild Projects="$(MSBuildProjectFile)" Targets="Build" Properties="Platform=x86" />
    </Target>

    <Target Name="RebuildX86" AfterTargets="Rebuild" Condition=" '$(Platform)' == 'x64' ">
        <MSBuild Projects="$(MSBuildProjectFile)" Targets="Rebuild" Properties="Platform=x86" />
    </Target>
   
     <Target Name="CleanX86" BeforeTargets="Clean" Condition=" '$(Platform)' == 'x64' ">
        <MSBuild Projects="$(MSBuildProjectFile)" Targets="Clean" Properties="Platform=x86" />
    </Target>
	
    <ItemGroup>
        <PackageReference Include="DNNE" Version="1.0.17" />
    </ItemGroup>
</Project>

This will allow to compile x64 and x86 binaries sequentially. I tried other configurations (which now I don’t remember) in order to have parallel compilation, but I get Error C1041: cannot open program database if multiple CL.EXE write to the same .PDB file, please use /FS. This flag is not enabled in DNNE compile command and I couldn’t find a way to add it (<DnneCompilerCommand>/FS</DnneCompilerCommand> just resulted in error). For me it’s enough as is since I already spent too much time, but if you have better ways to obtain the same please let me know.

@AaronRobinsonMSFT If it is not an expensive call, may be a quick IsX86SdkInstalled ?? As is we get a cryptic error which give us no idea on the cause, but if we get an error like “X86 SDK not installed” then we already know what to do and we can solve everything in a couple of minutes (instead of hours like happened in my case). Thanks

[AaronRobinsonMSFT]

@esso23 Added with https://github.com/AaronRobinsonMSFT/DNNE/pull/67.