.NET 8 as target gives NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): {0}. Affected libraries: {1}. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

martin-honnen commented 1 year ago

As .NET 8 RC (release candidate 1) has been published last week, I have tried to build a .NET 8 console app using <PackageReference Include="IKVM" Version="8.6.4" /> and <PackageReference Include="IKVM.Maven.Sdk" Version="1.5.5" />, this leads to a warning I didn't have with earlier attempts to build .NET 6 or 7 console apps using IKVM:

Warning NETSDK1206 Found version-specific or distribution-specific runtime identifier(s): win10-arm64, win7-x64, win7-x86, win81-arm. Affected libraries: IKVM. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

So somehow it appears that using the existing IKVM with the upcoming .NET 8 is not going as smooth as it seemed you could earlier use IKVM for .NET 3.1 Core to build .NET 6 projects.

https://aka.ms/dotnet/rid-usage says:

Starting with .NET 8, the default behavior of the .NET SDK and runtime is to only consider non-version-specific and non-distro-specific RIDs. When restoring and building, the SDK uses a smaller portable RID graph. The RuntimeInformation.RuntimeIdentifier returns the platform for which the runtime was built. At run time, .NET finds RID-specific assets using a known set of portable RIDs. When building an application with RID-specific assets that may be ignored at runtime, the SDK will emit a warning: NETSDK1206.

Finally https://learn.microsoft.com/en-gb/dotnet/core/tools/sdk-errors/netsdk1206 says:

If your application does need the specified RID and the affected package doesn't have a version that uses portable RIDs, the runtime can be configured to perform asset resolution via the old RID graph with version-specific and distro-specific RIDs.

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Runtime.Loader.UseRidGraph" Value="true" />
</ItemGroup>

I will try that to see whether it fixes things.

martin-honnen commented 1 year ago

I get the project to build but an attempt to run it gives the dreaded "FileNotFound" for "tzdb.dat": Unhandled exception. java.lang.Error: java.io.FileNotFoundException: Could not find a part of the path 'C:\Users\marti\source\repos\SaxonHE12Net8Tools\SaxonHE12Net8XSLT\bin\Release\net8.0\ikvm\lib\tzdb.dat'.. If I create a project targeting .NET 7 it seems to work fine.

martin-honnen commented 1 year ago

Sample .NET 8 console app project that gives that error is at https://github.com/martin-honnen/SaxonHE12Net8Tools.

wasabii commented 1 year ago

Yeah. It's pretty much because we are using the RIDs for the .runtime packages and assembling the set of files for the image output, and we're relying on the runtime itself to tell us the RID. We do include our own graph though. Problem is we only navigate this graph starting where the runtime tells us. The runtime is now telling us win-x64, but the .runtime packages use win7-x64.

All the runtime packages need to be renamed.

wasabii commented 12 months ago

Should be fixed on 8.7.0-dev.531 now in internal NuGet. Being built for prerelease right now.

danielcweber commented 9 months ago

I'm afraid this still seems to be a problem even in version 8.7.3.

Update: After a few rebuilds, I cannot reproduce the "missing bin\Release\net8.0\ikvm\lib\tzdb.dat" thingy, but I'm back to "Could not load libjava" which I already knew. The libjava error doesn't seem to happen for everybody though.

ikvmnet / ikvm