Bug #5403
closed
SaxonCS NuGet SaxonCS.dll is for Amd64 processor architecture and that way doesn't work with Arm64 processors like Apple M1 and .NET 6
0%
Description
Based on my problems to use SaxonCS 11.2 from NuGet with .NET 6 on an Apple Mini M1 where any app fails with a "Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'SaxonCS, Version=11.2.0.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format." for SaxonCS.dll I file this bug to hopefully in the future have a SaxonCS for any CPU or MSIL or a dedicated .NET 6 package.
A simple .NET 5 console application using the NuGet package of SaxonCS 11.2 and outputting the processor architecture rom the assembly is
using System;
namespace SaxonCSAssemblyInspection
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(".NET {0}, OS {1}, 64bit {2}", Environment.Version, Environment.OSVersion, Environment.Is64BitOperatingSystem);
var saxonCSInfo = System.Reflection.AssemblyName.GetAssemblyName("SaxonCS.dll");
Console.WriteLine(saxonCSInfo.ProcessorArchitecture);
}
}
}
and outputs on a Mac M1
.NET 5.0.15, OS Unix 11.6.4, 64bit True
Amd64
If I add
var xmlResolverInfo = System.Reflection.AssemblyName.GetAssemblyName("XmlResolver.dll");
Console.WriteLine(xmlResolverInfo.ProcessorArchitecture);
that shows "MSIL".
Based on that I think it is not possible to use SaxonCS with .NET 6 on an M1 as the NuGet SaxonCS.dll targets only Amd64 and I think that should be fixed as .NET 6 is the long term .NET release and current/future packages integrate with .NET 6.
Updated by Martin Honnen over 2 years ago
https://devblogs.microsoft.com/dotnet/dotnet-5-end-of-support-update/ says: ".NET 5.0 will reach End of Support on May 08, 2022"
Updated by Martin Honnen over 2 years ago
I updated my only Mac to OS 12 some days ago and now find that .NET 6 can run SaxonCS 11.3. No more System.BadImageFormatException.
Not sure whether .NET 6 on MacOS 12 is somehow smarter than .NET 6 on MacOS 11 to consume a NuGet package or whether SaxonCS has changed.
Based on Norm's comments elsewhere the SaxonCS 11.3 NuGet package was produced with the same tool chain as 11.2 so it might be that the MacOS version makes the difference.
Updated by Norm Tovey-Walsh over 2 years ago
I failed to update this bug, sorry.
While trying to construct the final release artifacts for 11.3, I was frustrated to discover that I was still getting 64-bit-only DLLs when you and I had (privately) exchanged a few examples where I was not getting those.
I worked out, after some trial and error, that building the release executable (which is 64 bit because that's the only option) rewrites the .nupkg package as a 64 bit only DLL. In other words, the dotnetRelease build target produces an architecture-independent DLL, the dotnetPublish target produces an executable and a 64 bit DLL.
My build process was to run the dotnetPublish target, which depends on the dotnetRelease target, and publish the resulting artifacts. That was the problem.
For 11.3, I changed things so that the dotnetRelease target copies it's output .nupkg package to a distributions directory before the dotnetPublish target scribbles all over it (Grrrrr...)
Unless you find that 11.2 now works for you, I think it's more likely that this is what fixed the problem. But it's all still a bit opaque, I confess.
Updated by Michael Kay almost 2 years ago
- Status changed from New to Closed
I believe this can be closed with no further action needed.
Please register to edit this issue
.