The executable generated from dotnet publish -r ubuntu.16.04-x64 doesn't have "x" permission

[daxian-dbw]

dotnet publish -r ubuntu.16.04-x64 generates an executable, however, the executable file doesn't have "x" permission.
This happens when building a stand-alone application targeting netcoreapp2.0 with dotnet-cli 2.0.0-preview1-005724. It is a regression comparing to dotnet sdk 1.0.

Steps to reproduce

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

# dotnet restore
# dotnet publish -r ubuntu.16.04-x64
[/temp/console]
bash:96> bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/console
bash: bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/console: Permission denied
[/temp/console]
bash:97> dir bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/console
-rw-rw-r-- 1 dongbo dongbo 66412 Apr 10 14:12 bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/console

Expected behavior

The file bin/Debug/netcoreapp2.0/ubuntu.16.04-x64/publish/console is an executable and should have the "x" permission.

Actual behavior

It doesn't have the "x" permission.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0-preview1-005724)

Product Information:
 Version:            2.0.0-preview1-005724
 Commit SHA-1 hash:  e391b5d5f3

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /home/dongbo/.dotnet/sdk/2.0.0-preview1-005724/

[kichalla]

cc @Eilon

[livarcocc]

@eerhardt @ramarag can we double check that apphost.exe is properly chmoded? I wonder if the change we made in the SDK for it broke this scenario.

[eerhardt]

Duplicate of NuGet/Home#4424

See https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#option-2-self-contained

[livarcocc]

@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.

[eerhardt]

It is pulled out of the nuget cache, like always.

Wondering if there is anything we can do to work around this problem during publish.

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.

[Eilon]

CLI folks: Is this planned to be fixed for Preview1? I think this could be a ship-blocker, no?

cc @livarcocc

[muratg]

ping

[eerhardt]

@muratg - please ping @rrelyea. This is a NuGet bug: NuGet/Home#4424

[tmds]

@eerhardt Why is this a NuGet bug? How does NuGet affect the executable file generated by the dotnet publish command?

[dasMulli]

How does NuGet affect the executable file

I think the idea is that NuGet should create the files in the package cache with proper permissions and record permissions on pack.

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.)

[tmds]

@dasMulli For pack, I understand the relationship. My question is how publish is related to NuGet.

[dasMulli]

It just copies / renames the dotnet / apphost executable from the cache

[RheaAyase]

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 ?

[eerhardt]

My question is how publish is related to NuGet.

We don't create the apphost executable during "publish". It is created when we build dotnet/core-setup and then put into a NuGet package.

"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 .sh script in it and you need to invoke it in your app. How is publish supposed to know to make that executable?

Or say (even more likely) a NuGet package has a .sh tool script in it, and it needs to be invoked during the build. (or some other executable like crossgen)

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 apphost executable? Yes. But then the next scenario comes along that needs to execute a file and is broken. So why add all these little workarounds to every place that needs to execute a file, and instead fix the underlying issue.

[tmds]

@dasMulli @eerhardt thanks, relationship is clear now.

[livarcocc]

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.

[muratg]

@livarcocc FWIW NuGet/Home#4424 is closed. Do we need another issue to track?

[eerhardt]

When is a new drop of NuGet coming into the .NET Core SDK?