Sdk: Publishing standalone app with a dot '.' in name on linux generates executable in an unexpected way

[kichalla]

Steps to reproduce

• On Ubuntu 16.04 LTS, install the latest version of CLI (I had 5825)
• mkdir sample.webapi
• cd sample.webapi
• dotnet new webapi
• Open the .csproj file and add a runtime identifier for linux-x64 <RuntimeIdentifiers>linux-x64</RuntimeIdentifiers> and save the file
• Open the NuGet.config file and remove the dotnet-core feed as aspnetcore-dev would suffice here
• dotnet restore
• dotnet publish -r linux-x64

Expected behavior

The published output should have an executable with name sample.webapi

Actual behavior

An executable with name sample.webapi.webapi

Environment data

dotnet --info output:

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

Product Information:
 Version:            2.0.0-preview1-005825
 Commit SHA-1 hash:  b4a821109d

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview1-002061-00
  Build    : 2b70ec9c3b014af0c2a5f45de0e5b73a1ae51c09

[kichalla]

I think I am seeing the same issue on Mac OS too.

cc @livarcocc

[Inirit]

I've been running into this issue as well, it caused me a few hours of confusion before realizing that it might be a bug in dotnet itself.

Is there a workaround in the meantime to override the generated executable name? It would be preferable to not have to manually rename the file every time.

EDIT:
I came up with this incredibly awful hack to get the desired behavior. Adding this target to the .csproj file of the project being published lets me override the name of the app host. (Note that my condition for detecting the platform is very flimsy and is specific to my use case, anyone else who uses this would have to add their own logic there for when they want this target to apply)

<Target Name="DeployAppHostWorkaround" DependsOnTargets="_ComputeNETCoreBuildOutputFiles" AfterTargets="DeployAppHost" BeforeTargets="CopyFilesToPublishDirectory" Condition="'$(DeployAppHost)' == 'true' AND '$(RuntimeIdentifier)' == 'linux-arm'">
    <ItemGroup>
        <ResolvedFileToRemove Include="%(ResolvedFileToPublish.Identity)" Condition="'%(ResolvedFileToPublish.RelativePath)' == '$(AssemblyName)%(Extension)' AND '%(Extension)' != '.dll'" />
        <ResolvedFileToPublish Remove="%(ResolvedFileToRemove.Identity)" />

        <ResolvedFileToPublish Include="%(ResolvedFileToRemove.Identity)">
            <RelativePath>$(AssemblyName)</RelativePath>
        </ResolvedFileToPublish>
    </ItemGroup>
</Target>

[TingluoHuang]

@livarcocc this is current block us adopt net core 2.0, i noticed you tag the milestone to 2.1.0, do you have idea about what the target date for 2.1.0?

[Petermarcu]

Reopening this because it looks like it may have regressed? https://github.com/dotnet/core/issues/1119

[dasMulli]

This also reproduces on the 2.0.3 CLI:
msbuild.binlog.zip

[fbarletta]

This has been the bane of my existence for the last 48 hours. Happy to contribute any way I can for a resolution.

[Petermarcu]

In https://github.com/dotnet/core/issues/1119, this was also causing @fbarletta issues using dotnet run. We should confirm whether that is also due to this issue or if there is another issue hidden behind this one.

[fbarletta]

From what I am seeing, when executing dotnet run
bin\Debug\netcoreapp2.0\osx-x64\ is created and there is a file inside
called online.portal.portal

On Wed, Nov 29, 2017 at 3:02 PM, Peter Marcu [e-mail]
wrote:

In the original issue, this was also causing @fbarletta
https://github.com/fbarletta issues using dotnet run. We should confirm
whether that is also due to this issue or if there is another issue hidden
behind this one.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-347979171, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc6L19T_IZbv65kZz-cUvn74svka0ks5s7bhOgaJpZM4NGoay
.

--

Francis Barletta
CEO
UPTOP
www.liveuptop.com

[dasMulli]

Found it. The culprit is https://github.com/dotnet/sdk/blob/8c5d7a7c5bfd3b3eba5cb5bde4339dda470bd39a/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.targets#L291

The host is copied into the obj folder with the right name for embedding the dll name and then included as copy local item with the pseudo extension added again

[Petermarcu]

@livarcocc I moved this to 2.2 so its on the radar. Also, should consider porting it to other places that may have regressed.

[dasMulli]

@fbarletta as a workaround, could you add this to the project and test if it works?:

  <Target Name="FixRidSpecificHost" AfterTargets="_ComputeNETCoreBuildOutputFiles">
    <ItemGroup>
      <None Remove="@(NativeAppHostNETCore)" />
      <None Include="@(NativeAppHostNETCore)" Link="$(AssemblyName)" CopyToOutputDirectory="PreserveNewest" CopyToPublishDirectory="Never"/>
    </ItemGroup>
  </Target>

[fbarletta]

It creates the application without the funky naming issue but I do get this
error though:

Application startup exception: System.PlatformNotSupportedException:
Windows Principal functionality is not supported on this platform.
at System.Security.Principal.WindowsIdentity.GetCurrent()
at
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.Implementation.ApplicationFolderProvider..ctor(IDictionary
environment, String folderName)
at
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.Implementation.Transmitter.Initialize()
at
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel.Initialize(TelemetryConfiguration
configuration)
at
Microsoft.Extensions.DependencyInjection.TelemetryConfigurationOptionsSetup.Configure(TelemetryConfiguration
configuration)
at
Microsoft.Extensions.DependencyInjection.TelemetryConfigurationOptions..ctor(IEnumerable`1
configureOptions)
--- End of stack trace from previous location where exception was thrown ---

Long Long Long

On Wed, Nov 29, 2017 at 3:42 PM, Martin Andreas Ullrich <
[email protected]> wrote:

@fbarletta https://github.com/fbarletta as a workaround, could you add
this to the project and test if it works?:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-347989664, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc4lAnqPPrtFXTOaxWRfvO2M-BZfCks5s7cGcgaJpZM4NGoay
.

--

Francis Barletta
CEO
UPTOP
www.liveuptop.com

[Petermarcu]

I assume your application is using ApplicationInsights? Are you using some functionality that is only supported on Windows?

[livarcocc]

@dasMulli thanks for root causing it. We will look into fixing it. I remember fixing this in master a while ago. It must have regressed somehow. Also, we never ported the fix back to the 2.0.3 release, which is why it happens there.

[fbarletta]

Yes.

I disabled all references to ApplicationInsights and it works.

I didn't test the workaround other than renaming everything to remove the
"." in the name but hopefully, this is addressed soon.

On Wed, Nov 29, 2017 at 5:30 PM, Peter Marcu [e-mail]
wrote:

I assume your application is using ApplicationInsights? Are you using some
functionality that is only supported on Windows?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-348018640, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc5Jl-k_KPEJzXZ_AerbJPeKgT_2Aks5s7dsLgaJpZM4NGoay
.

--

Francis Barletta
CEO
UPTOP
www.liveuptop.com

[dasMulli]

@livarcocc https://github.com/dotnet/sdk/pull/1378 did fix the publishing part - the publish output is fine with it but the host generated during the build still has this problem, which is why dotnet run is failing for a project with a single RID set. Probably isn't a common use case to produce a RID-specific build output, only RID-specific publishes.

[livarcocc]

@dasMulli got it, thanks. That makes sense. We will look into it.

[fbarletta]

I just tested the workaround @dasMulli posted and it worked. Just wanted to share. I am surprised others did not experience this but I supposed it's rare for people to use "." in the naming

[ppumkin]

Which version of NetCore is this fix coming out with? And what is a temp work around.. i am on dotnet --version 2.1.104 ? Getting issue on Ubuntu system

[fbarletta]

@ppumkin The workaround is to not use a . in your naming at all. When you publish, it'll correct itself.

I'm surprised this is still open.

[peterhuene]

@livarcocc This was inadvertently fixed for 3.0 when I refactored the the default apphost on build. We now properly use $(_NativeExecutableExtension) in the Link, which is empty for platforms other than Windows.

We can close it for 3.0, but do we want to still fix this in 2.2 (too late, I suspect, even for a servicing bar)?

[fbarletta]

3.0 of ....

On Tue, Oct 23, 2018 at 4:44 PM Peter Huene [e-mail]
wrote:

@livarcocc https://github.com/livarcocc This was inadvertently fixed in
3.0 when I refactored the apphost. We now properly use
$(_NativeExecutableExtension) in the Link, which is empty for platforms
other than Windows.

We can close it for 3.0, but do we want to still fix this in 2.2?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-432412244, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc2w7wAm8CFRL_Kpfq_kle4bSpW__ks5un3-hgaJpZM4NGoay
.

--
Frank Barletta

You can schedule time with me here https://calendly.com/francis_barletta.

UPTOP | 1460 Broadway New York, NY 10036
https://maps.google.com/?q=1460+Broadway,+New+York,+NY+10036&entry=gmail&source=g
[email protected] | 212.837.8276; 889
www.liveuptop.com

Follow us on Instagram http://instagram.com/live.uptop/ | Facebook
https://www.facebook.com/liveUPTOP | Twitter
https://twitter.com/liveuptop| Linkedin
https://www.linkedin.com/company/up-top/

--
This e-mail message is intended only for the use of the individual or
entity to which it is addressed and may contain information that is
privileged, confidential and exempt from disclosure.

[peterhuene]

@fbarletta 3.0 of .NET Core, which is an upcoming release (currently the master branch of the cli and sdk repos).

[livarcocc]

Re-target the milestone to 3.0 and close it.

[fbarletta]

It’s still broken in 2.2. Are you confirming 3.0 this has been fixed?

On October 23, 2018 at 8:15 PM, Livar [e-mail] wrote:

Re-target the milestone to 3.0 and close it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-432466503, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc3j7IMziEH-F90DLrAsnIJiHfyanks5un7EHgaJpZM4NGoay
.

--
This e-mail message is intended only for the use of the individual or
entity to which it is addressed and may contain information that is
privileged, confidential and exempt from disclosure.

[peterhuene]

So there are two issues here, one related to building and one related to publishing.

The publishing issue was fixed in 2.1.300 by @livarcocc (see https://github.com/dotnet/sdk/commit/3748d660e262d6166733e1a79bb9e8bfdedf0202). In you look in the publish directory, you should see the executable has a .exe extension for Windows runtimes and no additional extension for other runtimes.

However, whenever you build with a runtime identifier, it also creates an executable in the build output directory. This is what has been fixed in 3.0 by https://github.com/dotnet/sdk/pull/2578.

I'm closing this issue as fully addressed in the future 3.0 release.

[fbarletta]

I don't believe that is correct. We're using 2.2 and it's still not working
on MacOS which was the initial issue reported.

On Tue, Oct 23, 2018 at 9:16 PM Peter Huene [e-mail]
wrote:

So there are two issues here, one related to building and one related to
publishing.

The publishing issue was fixed in 2.1.300 by @livarcocc
https://github.com/livarcocc (see dotnet/sdk@3748d66
https://github.com/dotnet/sdk/commit/3748d660e262d6166733e1a79bb9e8bfdedf0202).
In you look in the publish directory, you should see the executable has a
.exe extension for Windows runtimes and no additional extension for other
runtimes.

However, whenever you build with a runtime identifier, it also creates an
executable in the build output directory. This is what has been fixed in
3.0 by dotnet/sdk#2578 https://github.com/dotnet/sdk/pull/2578.

I'm closing this issue as fully addressed in the future 3.0 release.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/6397#issuecomment-432477109, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEHAc9yIlJ906OU6yzTKMyIIttaW1iU_ks5un79wgaJpZM4NGoay
.

--
Frank Barletta

You can schedule time with me here https://calendly.com/francis_barletta.

UPTOP | 1460 Broadway New York, NY 10036
https://maps.google.com/?q=1460+Broadway,+New+York,+NY+10036&entry=gmail&source=g
[email protected] | 212.837.8276; 889
www.liveuptop.com

Follow us on Instagram http://instagram.com/live.uptop/ | Facebook
https://www.facebook.com/liveUPTOP | Twitter
https://twitter.com/liveuptop| Linkedin
https://www.linkedin.com/company/up-top/

--
This e-mail message is intended only for the use of the individual or
entity to which it is addressed and may contain information that is
privileged, confidential and exempt from disclosure.

[peterhuene]

@fbarletta could you please describe what is not working and provide any additional repro steps if they differ from this issues? That would help us diagnose the problem for you. Thank you.

I've verified that a 2.1 and 2.2 SDK both create the correct apphost executable in the publish directory. However, in the build output directory, you would see what is described in this issue. That has been addressed in 3.0.

[dasMulli]

@peterhuene any chance to get a fix into 2.2? It's a bit sad that dotnet run doesn't work when a RuntimeIdentifier is specified in the project file and there is a dot in the project name..

[ppumkin]

This is quite odd.. I bet its a regex problem.. nobody gots the time to fix it.

[livarcocc]

@dasMulli Unfortunately, we are too late on the 2.2 cycle to take this change in.

[dasMulli]

The fix isn't that difficult, it's probably just a pain vs risk vs release cycle issue.. (the fix actually got easier due to some changes introduced in recent updates)

--- a/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets
+++ b/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets
@@ -325,7 +325,7 @@ Copyright (c) .NET Foundation. All rights reserved.
     <ItemGroup Condition="'@(NativeAppHostNETCore)' != '' ">
       <NativeNETCoreCopyLocalItems Include="@(NativeAppHostNETCore)">
         <!-- Rename the host executable to the app's name -->
-        <Link>$(AssemblyName)%(NativeAppHostNETCore.Extension)</Link>
+        <Link>%(NativeAppHostNETCore.Filename)%(NativeAppHostNETCore.Extension)</Link>
       </NativeNETCoreCopyLocalItems>
     </ItemGroup>

[peterhuene]

It's a pure release cycle issue at this point; agreed that the fix is pretty easy. 2.2 is about to ship and this issue fell through the cracks.

I didn't think about how this would impact dotnet run, which it does indeed (it fails, ungracefully, with an unhandled exception).

@livarcocc perhaps we can bring a new issue regarding this problem to shiproom for a bar check, maybe for servicing? https://github.com/dotnet/core/issues/1119 is the existing issue, but it was closed. It was the "other half" of the issue described here.

I've also confirmed the dotnet run issue is fixed in master.

[dasMulli]

No guarantees but I think I got a test failing on *nix if you need sth:

--- a/src/Tests/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildASelfContainedApp.cs
+++ b/src/Tests/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildASelfContainedApp.cs
@@ -27,7 +27,7 @@ namespace Microsoft.NET.Build.Tests
             var targetFramework = "netcoreapp1.1";
             var runtimeIdentifier = EnvironmentInfo.GetCompatibleRid(targetFramework);
             var testAsset = _testAssetsManager
-                .CopyTestAsset("HelloWorld")
+                .CopyTestAsset("Hello.World")
                 .WithSource()
                 .WithProjectChanges(project =>
                 {
@@ -45,17 +45,17 @@ namespace Microsoft.NET.Build.Tests
                 .Pass();

             var outputDirectory = buildCommand.GetOutputDirectory(targetFramework, runtimeIdentifier: runtimeIdentifier);
-            var selfContainedExecutable = $"HelloWorld{Constants.ExeSuffix}";
+            var selfContainedExecutable = $"Hello.World{Constants.ExeSuffix}";

             string selfContainedExecutableFullPath = Path.Combine(outputDirectory.FullName, selfContainedExecutable);

             outputDirectory.Should().OnlyHaveFiles(new[] {
                 selfContainedExecutable,
-                "HelloWorld.dll",
-                "HelloWorld.pdb",
-                "HelloWorld.deps.json",
-                "HelloWorld.runtimeconfig.dev.json",
-                "HelloWorld.runtimeconfig.json",
+                "Hello.World.dll",
+                "Hello.World.pdb",
+                "Hello.World.deps.json",
+                "Hello.World.runtimeconfig.dev.json",
+                "Hello.World.runtimeconfig.json",
                 $"{FileConstants.DynamicLibPrefix}hostfxr{FileConstants.DynamicLibSuffix}",
                 $"{FileConstants.DynamicLibPrefix}hostpolicy{FileConstants.DynamicLibSuffix}",
             });

will be travelling over the next days so it's probably not a good idea for me to start a PR if you need it do be done quickly if it does meet a bar check.

[BeanMc]

someone else try fix that. or when new dotnet cli version is release?