Unable to create x86 + x64 package (re: ref folder also requires lib folder?)

[sofakng]

I'm trying to create a NuGet package that has separate assemblies for both x86 and x64.

Here is the folder structure:

• ref\net40\PixTools.PixCore.dll (AnyCPU assembly for compile-time only)
• runtimes\win-x86\lib\net40\PixTools.PixCore.dll (x86 specific .NET assembly)
• runtimes\win-x64\lib\net40\PixTools.PixCore.dll (x64 specific .NET assembly)
• PixTools.nuspec

Here is the .nuspec file:

<?xml version="1.0"?>
<package >
  <metadata>
    <id>PixTools</id>
    <version>8.6.3</version>
    <authors>OpenText</authors>
    <owners>OpenText</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>PixTools</description>
    <releaseNotes>PixTools SDK</releaseNotes>
    <copyright>Copyright 2023</copyright>
    <dependencies>
      <group targetFramework="net40"/>
    </dependencies>
  </metadata>
</package>

However, when I try to pack the file I get the following warning:

WARNING: NU5131: References were found in the nuspec, but some reference assemblies were not found in both the nuspec and ref folder. Add the following reference assemblies:

• Add PixTools.PixCore.dll to the net40 reference group in the nuspec

...and when I add it to my project the reference assembly doesn't show up.

What am I doing wrong?

I thought I only need the DLL(s) in the ref and runtime folders of the NuGet package?

[zivkan]

You haven't done anything wrong, if you want your package to only work with projects using PackageReference, and not be compatible with projects using packages.config. NU5131 is a warning, not an error.

The warning was added at a time when .NET (Core) usage was very low, most customers were still using .NET Framework, non-SDK style projects, and packages.config. The warning primarily helped package authors creating packages that worked with packages.config to be aware they need to make changes to make their packages compatible with PackageReference, and therefore the "future of .NET".

We should probably change the warning to only detect packages that are compatible with packages.config and not PackageReference, and stop warning on packages such as yours, which are only compatible with PackageReference.

[sofakng]

Ahhh - Thanks!

It's working with PackageReference, but how do I maintain compatibility with packages.config?

If I add a reference group like the error/warning suggests:

    <references>
      <reference file="PixTools.PixCore.dll" />
    </references>

...then I get a different error:
Error NU5018: Invalid assembly reference 'PixTools.PixCore.dll'. Ensure that a file named 'PixTools.PixCore.dll' exists in the lib directory.

However, I don't want to use the lib directory. I want to use the ref directory so these files are only used for compile-time references and I can have different runtime (x86 vs x64) runtime binaries.

EDIT: Also, how do I include the XML documentation for reference assembly? If I add PixTools.PixCore.xml to the ref folder it doesn't seem to work.

[zivkan]

I wrote a doc regarding managed wrappers of native code. Unfortunately it's a very complex issue: NuGet/docs.microsoft.com-nuget#3092

There's a big long discussion at the end about supporting projects that target .NET Framework (regardless if it uses packages.config, or PackageReference through SDK style projects, or the "classic" non-SDK style projects).

Regarding xmldoc, until about a year ago, PackageReference unfortunately didn't support it at all. NuGet made some changes, and now we write info into the assets file for the .NET SDK to be able to use, but I have no idea if they made changes on their end to enable it. It's possible they did and NuGet has a bug where it only works for lib/ and not ref/. Basically, in your project where you reference the package, check the obj/project.assets.json file, and see if the ref dll has something like "additionalFiles": [ "xml" ]. If not, it's either a package authoring error, or a bug in nuget not doing the right thing for ref/. If it is, then it sounds like a https://github.com/dotnet/sdk issue.