Saxon

So, is the use of AMD64 for SaxonCS.dll an intentional or necessary configuration?

It's certainly not intentional. There's nothing in the .csproj that suggests an architecture-dependency, we need to look at whether some default is being applied somewhere along the line.

Saxonica Developer Community notifications@plan.io writes:

But I am wondering whether the SaxonCS.dll is intentionally built only
for x64/AMD64 or whether that is some kind of build misconfiguration.

Configuration error, I expect. As Mike pointed out, there’s nothing in
the .csproj files so it must be something I’m doing wrong in the build
commands.

Since I’m not explicitly selecting x64, I wonder if I have to explicitly
select “any architecture”.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I don't have a full picture of that issue, I found an article (https://medium.com/@trapdoorlabs/c-target-platforms-x64-vs-x86-vs-anycpu-5f0c3be6c9e2) that says running a tool CorFlags.exe on the dll outputs some information about the flags set in the assembly ("a flag in the assembly’s CLR header").

When I run CorFlags.exe "C:\Users\Martin Honnen\.nuget\packages\saxoncs\11.0.1\lib\net5.0\SaxonCS.dll" I get

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

The article explains that PE32+ means x64 (sic) so I guess what is what VS complains or warns about. I am not sure, however, where the .NET (Core) compilation/build tools set that flag or allow setting it. VS has a dialog to select "any CPU" (this is the default it seems) or "x64" or "x86".

Norm Tovey-Walsh, as you build both SaxonCS and your XML resolver, when I run CorFlags.exe "C:\Users\Martin Honnen\.nuget\packages\xmlresolver\0.1.0\lib\net5.0\XmlResolver.dll" it indeed shows a different flag

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

which translate into "AnyCPU" I think. When using the XML resolver, I am never warned by VS about the x64/AMD64 issue.

Perhaps comparing your build approaches allows you to figure where/how SaxonCS aquires that 64bit flag.

Norm Tovey-Walsh, as you build both SaxonCS and your XML resolver, when I run
CorFlags.exe "C:\Users\Martin
Honnen.nuget\packages\xmlresolver\0.1.0\lib\net5.0\XmlResolver.dll"
it indeed shows a different flag

Thanks, Martin. (And thank you for being patient; I’m definitely still a
n00b on the .NET platform.)

I’ll compare the builds and see if I can spot the difference!

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

It's not immediately obvious to me what the difference is between the two projects. I do note that the solution files in both cases read:

	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Release|Any CPU = Release|Any CPU
	EndGlobalSection

So we're not setting the architecture in there...

The XmlResolver project actually uses a plugin to run the dotnet commands, a plugin that I couldn't make work in the SaxonCS project, so the actual difference in commands is obscured. I'll see if I can sort that out. Alas corflags doesn't seem to be available on the Mac so I'll have to do the investigation on the Windows box.

Norm Tovey-Walsh, there is also a programmatic way to read that info out mentioned in the article I linked to using reflection e.g. along the lines of

var asmInfo = System.Reflection.AssemblyName.GetAssemblyName("SaxonCS.dll");
Console.WriteLine(asmInfo.ProcessorArchitecture);

https://docs.microsoft.com/en-us/dotnet/api/system.reflection.processorarchitecture?view=net-5.0

and https://docs.microsoft.com/en-us/dotnet/api/system.reflection.portableexecutablekinds?view=net-5.0 seems to be what the tool outputs.

I'm having trouble getting the .dll file out of the Saxon 11.2 nuget package. I'm still very clumsy on Windows. But I ran the build again and copied the files over to another machine where I have after much struggling worked out how to get corflags installed.

PS C:\Users\ndw\x\Release\net5.0> & 'C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\CorFlags.exe' .\SaxonCS.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0
PS C:\Users\ndw\x\Release\net5.0> & 'C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\CorFlags.exe' .\XmlResolver.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0
PS C:\Users\ndw\x\Release\net5.0>

It looks like SaxonCS.dll and XmlResolver.dll now have the same "PE" flags. Is that your experience on Windows with 11.2?

I get PE32+ for the SaxonCS.dll 11.2 in my NuGet cache

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>CorFlags.exe  "C:\Users\Martin Honnen\.nuget\packages\saxoncs\11.2.0\lib\net5.0\SaxonCS.dll"
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

but PE32 for XmlResolver.dll 1.3

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>CorFlags.exe  "C:\Users\Martin Honnen\.nuget\packages\xmlresolver\1.3.0\lib\net5.0\XmlResolver.dll"
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

Interesting. I'll have to checkout the 11.2 tag and try again. I don't recall making any intentional changes since the 11.2 release, but I have spent many frustrating hours trying to sort out signing the Apple release, so it's possible that I nudged a configuration setting in some way.

Well, I'm no less confused now. I checked out the 11.2 release tag and rebuilt the distribution package. Both the DLL in the "net5.0" directory and the DLL extracted from the .nupkg file identify as "PE32" and not "PE32+".

I have no explanation for how or why the published NuGet package should be different, though I don't dispute that it is. The temptation is to imagine that the publishing process changes it somehow, but the package is signed so I don't think that's possible.

Curiously, if I extract the contents of the published NuGet package, I find that SaxonCS.runtimeconfig.json claims to be including the "5.0.9" version of "Microsoft.NETCore.App" where the one I built today claims to be including the "5.0.0" version. Apparently there was something different in the build. I have no explanation for that either.

As far as I can tell, the version of dotnet (5.0.400) is unchanged and was installed on that machine on 26 January, well before the 11.2 release.

"Wat."

I downloaded https://www.nuget.org/api/v2/package/SaxonCS/11.2.0, renamed it to .zip, unzipped and when I run the CorFlags.exe I get

CorFlags.exe "saxoncs.11.2.0 - Kopie\lib\net5.0\SaxonCS.dll"
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.8.3928.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 0x1
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 0
Signed    : 0

I don't know why we get different results.

We don't. Sorry if I was unclear.

If I inspect the .DLL file that's in the nuget package we distributed for 11.2, I see "PE32+" as well.

1. Download .nupkg file
2. Unpack it
3. SaxonCS.dll => PE32+

What I'm saying is that when I rebuild the .nupkg file from the same sources, on the same host, with the same toolchain, I get different results today:

1. Checkout the 11.2 tag
2. Delete the build artifacts
3. Build the .nupkg file again
4. Unpack that package
5. SaxonCS.dll => PE32

I am stumped. (You're good at finding the hard problems! :-) )