sdk: 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.

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 12
Comments: 18 (7 by maintainers)

Commits related to this issue

dotnet/sdk 2.1.700-preview-64015-02 (#11173) — committed to wli3/sdk by nguerrera 5 years ago

Most upvoted comments

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

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

Moving over to the SDK.

davkean on Apr 7, 2020

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 🙂

jibbers42 on May 30, 2021

Any chance of getting some love on this issue? Repro steps are well documented, and it’s been a few months. The StackOverflow link in the original report has some more info on motivation.

rkagerer on Feb 6, 2020

Repro Steps:

File, New Project
Select ‘Windows Forms App (.Net Framework)’ from C# tree
Name project ‘DebugExeIssue’
Hit OK
From ‘Build’ menu, select ‘Configuration Manager’
Select ‘<New…>’ from Configuration dropdown
Type in ‘Debug_newname’ and select ‘Debug’ from ‘Copy settings from:’ dropdown. Hit OK
In Solution Explorer, Right Click on ‘DebugEXEIssue’ project node.
Select ‘Properies’
Click on ‘Build’ on the Project Properties window.
Change ‘Configuration’ to ‘Debug_newname’
In ‘Conditional compaliation symbols:’ texbox, add symbol ‘Debug_newname’
Click ‘Save’ button
In Solution Explorer, Right Click on ‘DebugEXEIssue’ project node.
Select ‘Open Folder in File Explorer’
Open ‘DebugEXEIssue.csproj’ in Notepad
Locate line ‘<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug_newname|AnyCPU'">’
Hit the <enter> key to add a new line
Add Property ‘<AssemblyName>Debug_newname</AssemblyName>’
Save file and exit notepad
Click ‘Reload All’ on ‘File Modification Detected’ messagebox in Visual Studio
Press ‘F5’ to start debugging session

Expected:

Visual Studio will attach debugger to Debug_newname.exe and debugging session will start

Actual:

Visual Studio is unable to attach debugger to Debugnewname.exe because it is looking for DebugEXEIssue.exe.

The value in the ‘AssemblyName’ on the project properties is not updated based on the active configuration set in the Configuration manager.

stevepresley on May 13, 2019

It’s not exactly clear what fails; to route this to the correct component - can you fill out the following:

Repro Steps:

Expected:

Actual:

davkean on May 13, 2019