Paket pack fails when building/creating packages for Windows on Linux (docker), even using --build-platform flag

[bVanHertum]

Description

I've noticed this issue when moving to Gitlab CI/CD, which uses dockerized runners for builds (before, we had dedicated build servers on Windows). Our target machines for our APIs and services are all Windows-based, so this required directing the build process (using the Dotnet CLI) to build for Windows specifically (using the -r win-x64 directive on most commands).

However, paket pack fails to take into account the different build environment, even when instructed to do so.

Repro steps

1. Build the code in a linux container, for windows. Something like this

dotnet tool restore --configfile nuget.config
dotnet paket restore
dotnet restore -r win-x64 --configfile nuget.config
dotnet build --no-restore -c "Release" -p:MyRuntimeIdentifier=win-x64

This will output the build result to /bin/build-config/build-platform, like this:

Cart.Client -> /builds/dotnet/microservices/dotnet-common-client/src/Cart.Client/bin/Release/netstandard2.1/win-x64/Cart.Client.dll

(note: the runtime identifier is to force the dotnet CLI to build for win-x64 at solution level. See here for more info.
2. Run paket pack at solution level, indicating the desired build-config and build-platform

dotnet paket pack --version $VERSION --build-config Release --build-platform win-x64 $PACKAGE_DIR --minimum-from-lock-file

Expected behavior

Paket pack runs and builds .nupkgs for all the paket.template files within the solution, and puts them in the output directory. It uses the build artifacts from step 1 in the right build-platform directory.

Actual behavior

File not found exception, as paket doesn't look in the correct subdirectory for the build platform:

Paket failed with
-> FileNotFoundException: Could not find file '/builds/dotnet/microservices/dotnet-common-client/src/Cart.Client/bin/Release/netstandard2.1/Cart.Client.dll'.

Known workarounds

None that work, as far as I know. I figured I could try to redirect the output of the dotnet build command, but that's a unilateral redirect (i.e., all projects will push to the same output directory, as detailed here ). There's also no way to force paket pack to check certain directories for the build artifacts, so I can't run something like a for script manually on all the template files.

[baronfel]

Is there a particular reason you're not using Paket's built-in support for integrating into the dotnet pack command to package your packages? It's the most integrated way forward, and should seamlessly take -r, -c, etc dotnet CLI flags into account.

[bVanHertum]

Yes, I have actually tried converting the above script to using dotnet pack, but came across another issue entirely. Unsure if this issue is related to paket, the dotnet CLI, or the integration of the two.

If you replace paket pack with the dotnet pack command, above, you get something like this:

dotnet pack -c Release --no-restore --no-build -o $PACKAGE_DIR -property:RuntimeIdentifier=win-x64 -p:PackageVersion=$VERSION

This works correctly (inluding, indeed, using the correct subdirectory), but the nuspec files produced appear to have issues with their dependencies - they set the minimum version of the packages included incorrectly.

An example: one of our packages as produced by our Windows build engines has these listed:

    <dependencies>
     ...
      <dependency id="Emulator.Helpers" version="[16.1.0.6151-develop]" />
    </dependencies>

This one is produced by paket pack, with [] meaning >= the included package, as expected. When I run the above dotnet pack command against this same repository, I get this:

    <dependencies>
     ...
      <dependency id="Emulator.Helpers" version="(16.1.0.6151-develop, )" />
    </dependencies>

Same solution, same templates, same everything, but the resulting nuspec file has the requirement of strictly greater then (>) rather than >= the included package, even though the package in question is actually used during build, and the highest available version. Which means consuming this nuget package will give errors down the line (since there's no version higher than the one listed here).

As said, not sure whether my script, paket, or the dotnet CLI is the source of this one.