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

[jnm2]

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:

```c#

net47
exe
TestFilename

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

```c#
<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.

[jnm2]

Can someone point me to where I should ask the same for old csproj? It also calculates <TargetFileName> based on <TargetName>, and the debugger for that project system has the same problem as the .NET Core debugger in the new csproj.

[davkean]

@jnm2 We track both in this repo.

[jnm2]

Also, every time you start debugging a new csproj .NET Framework console app, it creates .runtimeconfig.json and .runtimeconfig.dev.json files which do not match the target name.

Just had another case today where I'm creating a tool with projects ToolName, ToolName.Console, ToolName.MSBuild, etc, and I want the ToolName.Console project's assembly name to be ToolName.Console while the output name is ToolName.exe.

[bruceburge]

@srivatsn and @basoundr so is no one tracking or assigned to this issue?

[Pilchie]

@bruceburge we're tracking all of these issues, but focused more on performance and significant blocking issues at the moment. @nguerrera - if the .runtimeconfig.json is generated with the wrong name, that sounds like an SDK issue, right? It's possible that fixing that will fix the debugging too...

[bruceburge]

@Pilchie I appreciate that, just saw that someone had been assigned and unassigned with no one attached to it. Thanks for that clarification, and hopefully this will spark a solution to this issue.

[nguerrera]

@nguerrera - if the .runtimeconfig.json is generated with the wrong name, that sounds like an SDK issue, right? It's possible that fixing that will fix the debugging too...

Yes. That would be an SDK issue.

[Pilchie]

Filed https://github.com/dotnet/sdk/issues/2252 for the incorrect runtimeconfig files.

[stevepresley]

Any update on this? I'm having the same issue with a c# Winforms app. I change the AssemblyName based on a configuration condition, and it fails when I change AssemblyName to something other than that specified in the csproj file. I have tried removing from the section all together, or leaving it it. Works correctly if the new AssemblyName matches what is currently defined in VS at runtime, fails if I change the current Configuration to another name. The scenario below fails after adding a new Configuration named "Debug NotMyAssemblyName" and then start debugging.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug NotMyAssemblyName|AnyCPU' "> <AssemblyName>NotMyAssemblyName</AssemblyName> .. </PropertyGroup>

[davkean]

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

Repro Steps:

Expected:

Actual:

[stevepresley]

Repro Steps:

1. File, New Project
2. Select 'Windows Forms App (.Net Framework)' from C# tree
3. Name project 'DebugExeIssue'
4. Hit OK
5. From 'Build' menu, select 'Configuration Manager'
6. Select '
7. Type in 'Debug_newname' and select 'Debug' from 'Copy settings from:' dropdown. Hit OK
8. In Solution Explorer, Right Click on 'DebugEXEIssue' project node.
9. Select 'Properies'
10. Click on 'Build' on the Project Properties window.
11. Change 'Configuration' to 'Debug_newname'
12. In 'Conditional compaliation symbols:' texbox, add symbol 'Debug_newname'
13. Click 'Save' button
14. In Solution Explorer, Right Click on 'DebugEXEIssue' project node.
15. Select 'Open Folder in File Explorer'
16. Open 'DebugEXEIssue.csproj' in Notepad
17. Locate line ''
18. Hit the key to add a new line
19. Add Property 'Debug_newname'
20. Save file and exit notepad
21. Click 'Reload All' on 'File Modification Detected' messagebox in Visual Studio
22. 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.

[rkagerer]

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.

[sguryev]

Have to change AssemblyName. Waiting for solution. Thank you!

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