-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet publish with a rid flattens Nuget package files. #9643
Comments
This has always been done like that. One of the reasons being that full frameworkdoes not know how to handle the Thanks @eerhardt, this is straight up a copy of his wisdom. |
I fail to see how I will take a look at Thanks. |
I'm looking into So, I'm not seeing a proper work around for this issue. |
A workaround could be to split packages for the different runtimes. So the native assets would be |
@pauldotknopf Like stated above, this is currently by design and we don't have plans to change it. It would be very significant and would lead to other scenarios being broken. Please try @dasMulli's suggestion above. |
Quoting my reply from NuGet dotnet/sdk#8748 here: I just wanted to point out that the suggested solution with contentFiles has it's drawbacks:
|
@livarcocc To me it reads like the quoted text is a response as to why runtimes/x/native got flattened. The issue is not that the E.g. a file in cc @eerhardt (because he wrote the quoted text) |
Filed a doc issue at https://github.com/NuGet/docs.microsoft.com-nuget/issues/2322. Hopefully someone from the .NET Core or NuGet team can help answer whether this behavior (as @Jjagg says, the flattening of files within This popped up in microsoft/playwright-dotnet#1145 where it broke the ability to publish platform-specific / self-contained projects. /cc @eerhardt |
@eerhardt Any update on this issue? |
While I appreciate the logic here, the ramifications are that assembly detection and loading must use different logic depending on the settings used with the command Also, flattening directory structure breaks when you have multiple files with the same name in different sub-directories. |
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
…ory. NuGet adds 'native' assets without a directory component (see dotnet/sdk#9643), which means that for frameworks in NuGets all files in those frameworks are added as plain files, without any information about which subdirectory to put them in. This is obviously wrong, so just don't add any native assets to the content directory. Additionally, frameworks shouldn't be in the hot restart content directory in the first place, because: * They need to be signed in order to execute on the device. * iOS won't allow executing native code from a writeable directory * As such they can't be copied on demand, they have to be installed with the app.
Bump @eerhardt, is any progress being made on this? |
Steps to reproduce
Expected behavior
I expect both methods of publishing to preserve the NuGet package's file structure, like this.
Original NuGet package directory structure.
Actual behavior
dotnet publish
produces a proper folder structure, mimicking the original NuGet package.dotnet publish -r osx-x64
produces an invalid folder structure. It flattens everything into the root. My libraries have specific rpath's that require them to be in certain directories to work properly."dotnet publish -r osx-x64" directory structure
Take note that the
/lib
,/plugins
and/qml
directories were flattened.Environment data
The text was updated successfully, but these errors were encountered: