PackAsTool true breaks debugging in Visual Studio when project is WPF

[fernacolo]

I'm writing a tool application that uses WPF. It is intended to be called from console, but it shows graphics that cannot be represented by text, therefore I need WPF. It works fine in .NET Framework, but when migrating to .NET Core, when I add <PackAsTool>true</PackAsTool>, VS2019 cannot debug it anymore, saying:

The debug executable 'c:\path\to\mytool.exe' specified in 'mytool' debug profile does not exist.

This might be a VS2019 issue (as you are probably thinking right now 😉), however it seems that when <PackAsTool>true</PackAsTool> is added to the .csproj, it changes the output type to dll, even though the project says it's WinExe:

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

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UseWPF>true</UseWPF>
    <PackageType>DotnetTool</PackageType>
    <PackAsTool>true</PackAsTool>
  </PropertyGroup>

</Project>

This is bad because I cannot use the simplicity of <PackAsTool>true</PackAsTool> for publishing and installation (i.e. have an automatic shim installed to path).

Even if I ignore the VS limitation, I'm also not sure if a DLL would work as expected for a WPF project. My understanding is that WPF requires WinExe for certain features.

Here's my dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview3-010431
 Commit:    d72abce213

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview3-010431\

Host (useful for support):
  Version: 3.0.0-preview3-27503-5
  Commit:  3844df9537

.NET Core SDKs installed:
  2.1.601 [C:\Program Files\dotnet\sdk]
  2.2.103 [C:\Program Files\dotnet\sdk]
  3.0.100-preview3-010431 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview3-19153-02 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview3-27503-5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview3-27504-2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

And this is my VS version:

[fernacolo]

Just FYI, I was able to mitigate by doing this:

<PackAsTool Condition="'$(BuildingInsideVisualStudio)'!='true'">true</PackAsTool>

Yet I think the issue is prevalent. Just not sure if this is dotnet/sdk or VS2019 issue. Thanks!

[fernacolo]

Actually, the fix is not effective. I need the tool to be packed as .exe, because otherwise it uses the context of dotnet.exe process, which does not work for me.

[wli3]

The direct cause is PackAsTool will set UseAppHost to false regardless. And VS expects this exe to debug.

@nguerrera @peterhuene see if my solution make sense
https://github.com/dotnet/cli/issues/11300 should get in first. So WPF and Winform work in general

I will keep UseAppHost to be true if it is an desktop app. By detecting if _UseWindowsGraphicalUserInterface is true. Since run directly with dotnet.exe will have a different result in desktop app case, it is "not complete" without the exe.

At the same time, I can get "windowsGraphicalUserInterface" flag properly in CLI "tool install time". The exe will be part of the package, CLI can dig the exe and get the flag.

[wli3]

@nguerrera @peterhuene ?

[nguerrera]

And VS expects this exe to debug.

It should be respecting the RunCommand, which would be adjusted with UseAppHost (if the ordering is correct, I know we had some issues with where we were changing it before.) But, yes, a windows app may behave wrong when run with dotnet. It will get dotnet's win32 manifest, start a console window, etc.

[wli3]

RunCommand is fixed by #3212

But there is still a bug on due to lack of an apphost during build, PE bits do not takes effect during debug(works after install and run the app).

Talked to @nguerrera, we think a better solution is to generate apphost during build, but does not pack it

[nguerrera]

I actually would have expected debug to work, but use dotnet app.dll. This would still be bad, it would not respect the win32 manifest, but we should investigate why that wasn't the symptom to make sure there aren't other consequences. UseAppHost=false is still a vaild thing. F5 should work on that. It is probably an msbuild timing thing with when PackAsTool was doing it, but we should be sure there isn;t a more general issue here.

[nguerrera]

Oh, nevermind, we fixed the part where it wouldn't run at all in #3212.