Debugging for .NET Core does not calculate the output path correctly with TargetName

I’ve been using <TargetName>ActualOutputFileNameWithoutExtension</TargetName> as a good way to control the output filename independently from the assembly’s actual name. Once in a while, for style reasons, this is handy. Sometimes I’ll need a long namespace and matching assembly name containing the namespace, but the output file name looks kinda silly.

As @boriscallens discovered, when you try to debug, the executable path is not properly calculated and debugging does not start. I don’t know if he’s using the old or new csproj SDK, but I did discover an issue with the new project system:

I’ve always happened to use this in the new csproj and targeting .NET Framework, where the debug executable path is properly calculated. It’s when you target .NET Core that it stops working.

Runs and debugs as expected:

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

  <PropertyGroup>
    <TargetFramework>net47</TargetFramework>
    <OutputType>exe</OutputType>
    <TargetName>TestFilename</TargetName>
  </PropertyGroup>

</Project>

Does not run or debug, unless you remove the <TargetName>:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp11</TargetFramework>
    <OutputType>exe</OutputType>
    <TargetName>TestFilename</TargetName>
  </PropertyGroup>

</Project>

Specifically, my expectation would be that debugging would honor <TargetFileName> calculated in Microsoft.Common.CurrentVersion.targets.

[davkean]

I looked into this, there’s SDK bugs here:

1. The generated host exe does not respect TargetName
2. The generated runtimeconfig and deps.json does not respect TargetName

Moving over to the SDK.

[jibbers42]

Here is a simpler set of steps to reproduce the issue, but for running instead of debugging - hopefully the same fix for both.

==> dotnet --version 
5.0.300

==> dotnet new console -o TargetNameIssue
The template "Console Application" was created successfully.
...

==> cd TargetNameIssue

==> dotnet run
Hello World!

Edit TargetNameIssue.csproj and add <TargetName>CustomName</TargetName> within the ProperyGroup section.

==> dotnet run
The application to execute does not exist: '/home/jibbers42/code/testbeds/TargetNameIssue/bin/Debug/net5.0
/TargetNameIssue.dll'.

==> ls bin/Debug/net5.0/
CustomName.dll  ref              TargetNameIssue.deps.json               TargetNameIssue.runtimeconfig.json
CustomName.pdb  TargetNameIssue  TargetNameIssue.runtimeconfig.dev.json

It would be great to see a fix released for this issue 🙂