Architecture-specific files folder hierarchy lost (native subfolders)

[ezolotko]

Details about Problem

NuGet product used: VS UI, dotnet.exe

NuGet version: 4.60

dotnet.exe --version: 2.1.503

VS version: 15.9.5

OS version: Microsoft Windows [Version 10.0.17134.523]

Detailed repro steps

1. Download the attached archive containing the repro files, extract the downloaded archive at [path]

2. In the nuget options, add local package source at the location [path]\NativeFilesFoldersPackage, so that the included NativeFilesFoldersPackage.0.0.1.nupkg is available to install.

3. Inside the NativeFilesFoldersPackage.0.0.1.nupkg file, notice that folder \runtimes\win-x64\native contains the following folder hierarchy:

|- native
   | - RootNativeFile.txt
   | - MySubfolder
          |- NativeFileInSubfolder.txt

3. Create a .NET Core class library project, install the NativeFilesFoldersPackage.0.0.1 package in it.

4. For the created project, run the following command: dotnet publish -c Release -r win-x64

5. In the created publish folder (bin\Release\netcoreapp2.1\win-x64\publish), notice that the files RootNativeFile.txt and NativeFileInSubfolder.txt are in the publish directory next to each other (without the MySubfolder folder included), i.e. the native folder hierarchy in the package is lost while publishing.

6. The same effect is observed with native DLLs while debugging the project in Visual Studio without publishing.

This issue is really important for scenarios when the native libraries need to maintain a fixed folder hierarchy around them to function (for example, libraries which look for data or plugins in a subfolder, cases with "xxx.framework" folders on MacOS, and many others).

Sample Project

NativeFilesFoldersTest.zip

Verbose Logs

NativeFilesFolders_Publish.log

[jainaashish]

If you don't pass runtime identifier -r win-x64 then it does the right thing and preserve the folder structure but as soon as you pass runtime, it flattens out the folder.

@nguerrera @dsplaisted can help understand the difference here and give more details.

[ezolotko]

@jainaashish if I understand this correctly, passing -r win-x64 publishes a self-contained application, while not passing any -r does a framework-dependent deployment. If this is correct, what if I want my application to be self-contained and use a package with native library which depends on a fixed hierarchy of subfolders with data around it?

[jainaashish]

I've the same understanding and I'd imagine it should keep the same folder structure in a self-contained app as well. Which is why I've added dotnet SDK folks to respond on this issue. This isn't related to NuGet and once dotnet folks agree, I'll move it over to their repo.

[nguerrera]

I am nearly certain there is a duplicate issue somewhere, but I cannot find it. I believe there were opinions that this was by design because you should be using content instead of native for auxiliary files to the native dll. But without finding the original issue I'm not sure. cc @eerhardt who I think was involved in the original discussion.

[eerhardt]

I think it was https://github.com/dotnet/cli/issues/9794...?

Basically, the suggested workaround was to use contentFiles, which maintains the folder structure.

Maybe we should consider changing the behavior, and maintaining the folder structure.... Or at least, an option to opt into maintaining the folder structure under runtimes\RID\native.

[jainaashish]

closing this as dupe of https://github.com/dotnet/cli/issues/9794

@ezolotko you can continue the further discussion on the above issue.

[dsplaisted]

@jainaashish I'm not sure we should be closing this as a dupe of another closed issue. If we want to continue discussion of this, it should probably be on an open issue.

[ezolotko]

I just wanted to point out that the suggested solution with contentFiles has it's drawbacks:

• I am not sure if in case of dotnet run (not dotnet publish) contentFiles can be made to copy the files next to the native files in the .nuget/packages folder. I think copyToOuput="true" makes them to be copied to the project output folder (like bin/debug) only. This will be a problem in cases when existing native libraries require subfolders next to them (in a .nuget/packages<package_name>/native/.. folder).
• I don't know how contentFiles can be published depending on target runtime. I.e. when we need to have one set of files for Windows and another for MacOS.
• Content folders cannot be hidden from the Visual Studio Solution Explorer (while content files can be, but we are discussing the case with subfolders here).

[jainaashish]

@dsplaisted then may we should reopen that closed issue but we should continue the discussion there so that we have the history of why did we closed at the first place.

[JerryJian]

So, any progress on this?