[Feature]: Improved runtime support

[DaanV2]

NuGet Product(s) Involved

NuGet.exe

The Elevator Pitch

The support for different runtime versions needs to be improved. It's so difficult to create support for x64 or x86 libraries.

It's really easy to just add framework-specific versions:

        <file src="lib\net48\*.*" target="lib\net48\" exclude="*.tmp;*.pdb" />
        <file src="lib\netcoreapp3.1\*.*" target="lib\netcoreapp3.1\" exclude="*.tmp;*.pdb" />
        <file src="lib\netcore50\*.*" target="lib\netcore50\" exclude="*.tmp;*.pdb"/>

I think it would be amazing if we can have a subfolder for either x64 or x86 related files. I think an attribute that specifies the runtime would be best.

But mostly, I want the packager able to take in specified x64 and package them correctly into the package. With it may also be simplified framework specification.

for example:

        <file src="lib\net48\x64\*.*" framework="net48" runtime="x64"/>
        <file src="lib\net48\x86\*.*" framework="net48" runtime="x64"/>
        <file src="lib\net5\x64\*.*" framework="net5" runtime="x64"/>
        <file src="lib\net5\x86\*.*" framework="net5" runtime="x86"/>

I see no reason why the packager could not import dotnet class library into the correct structure itself

Additional Context and Details

I have tried multiple solutions and multiple days trying to get this to work properly work.

For a package manager that is meant to be simple, this is ridiculously hard, or undocumented.

I think it speaks volumes that a big majority of packages of the top packages all lack runtime support. Or even all dotnet packages seem to be missing runtime support as well.

I would really want to emphasize that even if this functionality exists, This area of the packager needs to be improved, and not just on documentation.

[nkolev92]

Thanks for filing this @DaanV2,

Please take a look at https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders

I think it speaks volumes that a big majority of packages of the top packages all lack runtime support.

I think this makes an assumption that these top packages need to have specific support based on the architecture. As majority of NuGet packages contain only managed code, it's not super common that the arch matters.

[nkolev92]

Functionality wise, can you think of any ways that the feature you're proposing is different from the already available one?

[DaanV2]

The problem more is that I have tried these methods over and after a couple of hours got nothing to work.

The process of adding framework/architecture to a packet could be simplified so so much for the benefit of all. So far I haven't seen any feature inside of the packet specification file that actually allows for this. but it's just an example.

But the simplicity of it all is, that I want to say: these files have been compiled .net5 x64 and these files have been compiled for .net48 x86

[nkolev92]

Are your concerns primarily with the authoring experience?

Are you having trouble creating a package that looks like the docs indicate? Or does the package you create not work in ways you expect it to work?

[DaanV2]

Bit of all.

I do think that trying to get anything to work for multiple hours is either not documented well enough, is not user friendly or is a difficult task. Which all 3 for a packaging tool doesn't seem great.

I cannot create a package as indicated by the docs that support x64 and x86, or the package doesn't work, I wouldn't know, as there is no debugging options in nuget.exe as far as I know

[nkolev92]

To evaluate that your package works, you should try to install it a project that is arch specific.

You can post your directory structure here and maybe we can provide some helpful advice. We do prioritize based on impact, so while we can leave this issue open, we'd want to hear from more customers before changing up things in this space.