The executable generated from dotnet publish -r ubuntu.16.04-x64 doesn't have "x" permission
#8097
Comments
|
cc @Eilon |
|
@eerhardt Is this exe pulled out of the nuget cache or out of the CLI build location? Wondering if there is anything we can do to work around this problem during publish. |
|
It is pulled out of the nuget cache, like always.
We could, but that doesn't solve every other scenario that needs to get executables/scripts out of nuget packages. I would rather we ask NuGet or corefx to fix this issue, so it gets solved for everyone. |
This change moves powershell to .NET Core 2.0. Major changes are: 1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`. 2. Refactor code to remove most CLR stub types and extension types. 3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed. 4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded). 5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this. 6. Replace the use of some APIs with the ones that take `SecureString`. 7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12. 8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
|
CLI folks: Is this planned to be fixed for Preview1? I think this could be a ship-blocker, no? cc @livarcocc |
|
ping |
|
@muratg - please ping @rrelyea. This is a NuGet bug: NuGet/Home#4424 |
|
@eerhardt Why is this a NuGet bug? How does NuGet affect the executable file generated by the |
I think the idea is that NuGet should create the files in the package cache with proper permissions and record permissions on I'd like to see a more comprehensive fix in the SDK that sets the proper permission on *nix machines, not assuming that the package cache can even have those flags (depending on file system, umask etc.) |
|
@dasMulli For pack, I understand the relationship. My question is how |
|
It just copies / renames the |
|
Just for the sake of OCD, could we just remove the ubuntu refence from the title of this issue and have it something like dotnet/cli#6437 ? |
We don't create the "publish" takes assets and copies them to your publish folder. It can't know what the permissions should be for all the assets that it copies. Say a NuGet package has a Or say (even more likely) a NuGet package has a The underlying issue here is that when I create a NuGet package, the .nupkg should retain the permissions at the time it was created. Then when the .nupkg is restored, it should be restored with the same file permissions. Can we work around this in publish just for the |
|
I agree with @eerhardt, we should not go around adding one workaround after another. I will close this issue and we will track this fix through NuGet/Home#4424. |
|
@livarcocc FWIW NuGet/Home#4424 is closed. Do we need another issue to track? |
|
When is a new drop of NuGet coming into the .NET Core SDK? |
dotnet publish -r ubuntu.16.04-x64generates an executable, however, the executable file doesn't have "x" permission.This happens when building a stand-alone application targeting
netcoreapp2.0withdotnet-cli 2.0.0-preview1-005724. It is a regression comparing todotnet sdk 1.0.Steps to reproduce
Expected behavior
The file
bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/consoleis an executable and should have the "x" permission.Actual behavior
It doesn't have the "x" permission.
Environment data
dotnet --infooutput:The text was updated successfully, but these errors were encountered: