Which one is correct adding all runtimes or lib only in nuget package? RRS feed

  • Question

  • Hello, I have created a nuget package with a uwp usercontrol or consumption for my uwp apps. I have finished, it works good in my pc. However I need a proper advice from a Microsoft expert about which configuration is correct for a multi architecture model.

    I think (may be my misunderstanding), I have 2 options. One is to add only the AnyCPU only, another is adding all (AnyCPU, ARM, ARM64, x64, x86) while building. The following is my nuspec file.

          <file src="bin\Release\**" target="lib\uap10.0"/>	  
          <file src="bin\ARM\Release\**" target="runtimes\win10-arm"/>
          <file src="bin\ARM64\Release\**" target="runtimes\win10-arm64"/>
          <file src="bin\x64\Release\**" target="runtimes\win10-x64"/>
          <file src="bin\x86\Release\**" target="runtimes\win10-x86"/>

    The following is my nupkg file's explorer view.

    Is this configuration correct? 

    • Edited by Bhadurudeen Wednesday, July 1, 2020 5:58 PM
    Wednesday, July 1, 2020 5:55 PM

All replies

  • Hi Bhadurudeen,

    Thank you for posting here.

    Since this thread is related to nuget, so I suggest that you can ask this question in stackoverflow.

    The Visual C# forum discusses and asks questions about the C# programming language, IDE, libraries, samples, and tools.

    Best Regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, July 3, 2020 1:14 AM
  • Your NuGet package should contain all the platforms that you support and for which you need different binaries. This is how NuGet was designed to work. If you don't do this then you end up having to create multiple packages that differ only by the platform and they must all have a unique ID and name. This is a lot of work on your part.

    Furthermore when someone is searching for your package they will get multiple hits and will have to decide which one to use. The worst part about this is that you are forcing anybody using your package to manually have to edit their project file/package.config to use your package. The reason for this is because VS, at this point, does not have a UI for per-platform packages. So every time someone uses the UI to install/update a package it will be done for all the platforms. But if you have a separate package for each platform then I would have to reference different packages for each platform rather than letting the package reference specify the platform being used once. Each platform would therefore have a different line. Every time I updated the package I'd have to fix this manually as well using MSBuild conditional settings which can be a pain to write and maintenance since the condition changes based upon version of platforms in some cases (e.g. .NET Core)

    It gets worse though. NuGet caches packages so even though I only need 1 copy of your package I would have to tell NuGet I need X copies (one for each platform) and therefore I'm taking up way more space then I need. And in the case of automated builds this has to be done each time I build which slows down the build. 

    Then we can talk about versioning and dependencies. Each platform has its own package and therefore version. If I update 1 package to a newer version but not the others my code might behave differently across platforms. This means I'm going to have to do more in depth testing. This is, of course, assuming I have a dependency on your package at all. In many cases projects depend upon other packages that depend on your packages. Therefore I don't specify your package at all. Depending upon the NuGet options when I build it'll pull down the exact version that the dependent package needs which may or may not be the current version. If I have multiple dependencies relying on different versions of your package then I get consolidation errors which can result in runtime problems. To work around that I have to use runtime bindings which are per assembly. It is now harder because configuration files aren't per platform yet they will need to have per-platform assembly binding references.

    I, for one, would never use such a package as it is entirely too much maintenance and this would need to be done every time there is an update. If I had to use your package I would create a metapackage that does exactly what you should be doing to begin with which is creating a single package. NuGet assumes you will have a single package with all the different platforms you support in a single package. Each platform can have its own set of files and dependencies. There is zero benefit, in my opinion, for having multiple packages just because of platforms.

    Michael Taylor

    Friday, July 3, 2020 2:42 PM