Publishing console app with WPF app as dependency in self-contained emits broken AppHost

[mjcheetham]

Versions

PS> dotnet --version
5.0.201

Problem(s)

1. Publishing an application (as self contained) that has another application project (not a class library) as a dependency does not pass through the chosen runtime identifier to child projects.

2. Publishing (as a single-file) a console application that has a WPF application/project as a dependency emits a broken AppHost for the child project.

Repro Steps

Please see a full reproduction of the bugs in this repository:

https://github.com/mjcheetham/bug-wpfconsole

Simplified Repro

mkdir test
cd test
dotnet new console -n cli
dotnet new wpf -n wpfapp

Edit cli\cli.csproj:

   <PropertyGroup>
-    <TargetFramework>net5.0</TargetFramework>
+    <TargetFramework>net5.0-windows</TargetFramework>
   </PropertyGroup>

dotnet add cli reference wpfapp
dotnet publish cli -r win-x86
.\cli\bin\Debug\net5.0-windows\win-x86\publish\wpfapp.exe
# No window appears

Remarks

Note that publishing not self contained and not as a single file works OK. The problems occur in handling of AppHost vs SuperHost, and in passing of all properties to the child Publish targets.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Versions

PS> dotnet --version
5.0.201

Problem(s)

1. Publishing an application (as self contained) that has another application project (not a class library) as a dependency does not pass through the chosen runtime identifier to child projects.

2. Publishing (as a single-file) a console application that has a WPF application/project as a dependency emits a broken AppHost for the child project.

Repro Steps

Please see a full reproduction of the bugs in this repository:

https://github.com/mjcheetham/bug-wpfconsole

Simplified Repro

mkdir test
cd test
dotnet new console -n cli
dotnet new wpf -n wpfapp

Edit cli\cli.csproj:

   <PropertyGroup>
-    <TargetFramework>net5.0</TargetFramework>
+    <TargetFramework>net5.0-windows</TargetFramework>
   </PropertyGroup>

dotnet add cli reference wpfapp
dotnet publish cli -r win-x86
.\cli\bin\Debug\net5.0-windows\win-x86\publish\wpfapp.exe
# No window appears

Remarks

Note that publishing not self contained and not as a single file works OK. The problems occur in handling of AppHost vs SuperHost, and in passing of all properties to the child Publish targets.

Author:	mjcheetham
Assignees:	-
Labels:	area-Single-File, untriaged
Milestone:	-

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[vitek-karas]

Related (possibly a duplicate) to:
#16184 - propagation of properties
#15117 - SDK should prevent mismatched configurations (since it is broken)
#1675 (fixed in #14488) - support at least some configurations of exe->exe references correctly.

[vitek-karas]

I tried this with 6 Preview 4 nightly and the wpfapp pops up a dialog that it's missing a shared framework.
This is basically expected. The cli is published as self-contained and the wpfapp is published as framework dependent (no RID propagation) into the same folder. The host will detect the presence of self-contained-like files in the folder and will treat wpfapp as self-contained to a degree as well. Basically the files on disk and the runtimeconfig.json for wpfapp are not in sync and the host gets confused.

#15117 would make this an explicit failure in the SDK.
If #16184 is implemented it would probably try to publish both as self-contained and it "might" work - not sure how SDK would handle runtime pack asset deduplication in this case though.

publishing with /p:PublishSingleFile=true will also not work - the WPF app in this case is "corrupted" in a slightly different way and it won't start either (and not show anything). In this case it's because the wrong host was chosen (using apphost, but publishing as single-file-like). I assume this is also because the RID is not propagated.

[mjcheetham]

Feels like #15117 would be a pretty poor "fix" for this scenario. The same scenario that works today in .NET Framework and .NET Core/5.x with FD deployments would be an error in 5/6.x.

#16184 sounds like it would be a better "fix", if not 100% correct, at least produces a working set of executables. The definition of "100% correct" is ill-defined the way publishing and the self-contained deployment model has been designed.

All the assumptions so far have been a single top-level application, without thought for multi-executable "products" that share code.