Nuget Arch Handling is Very Frustrating for CI/DevOps perspective

[solvingj]

I don't have a feature request at this point because I can't imagine what options exist to solve this issue. However, I'll just describe the challenge as clearly as I can from my perspective.

I've found the Architecture handling between x86 and x64 for Nuget packages to create very awkward problems. The "front-end" of this problem is perhaps Appveyor (or any CI system). The traditional approach is to use a build matrix, which very commonly runs one-or-more builds for each architecture, but each build is completely separate. The CI workflow for other package systems is then to upload the arch-specific package to a repository, which each build can do independently upon completion. This workflow isn't valid for Nuget. Nuget's strategy is unique in that it requires a single package file to contain all the binary files for all architectures. This is just a fundamental incompatibility with what Appveyor and other packaging systems do. For now, there are several ways to engineer around this design, and I'm not sure there's ever a future in which this could change, but this is my feedback.

[jainaashish]

Thanks for the feedback! We have not given it a thought so far and neither it has been brought up by community. But we'll keep this request active here and let community give their feedback on this feature now.

But meantime, you can always create multiple packages with each architecture and allow your current workflows to work as is with nuget packages as well right? or is there any other part which is missing?

[solvingj]

Thanks for the response. Indeed there are workarounds. Most people just compile for both arch's in a single build step, ignoring the Appveyor build matrix feature. Also, some people build separate packages : ourlib_x86 and ourlib_x64, but then they cannot be consumed as transitive dependencies in a cross-platform way like normal dependencies.

Also, it's worth pointing out that this doubles the size of the nuget packages. So, if the lib compiles up to 75 MB, users have to download 150 MB because of the unified package structure. This is more of a problem with things like Chocolatey which are now using Nuget to package larger applications.

Finally, it's worth pointing out that as netcore will target more and more platforms and architectures, this problem may be emphasized.

Rather than just relying on recent complaints or a lack thereof as an indicator of the merit of a really old design decision, I advise a look to other package systems which deal in native architecture aware packages and see how they're doing it. If everybody else is doing differently, maybe they're just silently enjoying subtle advantages like faster downloads, and parallel build and packaging, while this user base maybe has just learned to work around it (or look for alternatives like Paket).

[rrelyea]

What language are the users of these packages using? C++ or managed languages or ???

[solvingj]

For any modern language that builds artifacts which are architecture-aware , the status quo with CI systems is to divide the work of building and packaging a separate artifact for for each target architecture across multiple machines/instances using a build matrix. The status quo is also to have a final instance-level step to deploy each such artifact to some repository independently from it's siblings. Once again, the key concept I am highlighting here is that .nuget package structure simply does not align with this common workflow, because it does not manage each build artifact as an independent entity.