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[bot]]

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 ```powershell 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 ```powershell mkdir test cd test dotnet new console -n cli dotnet new wpf -n wpfapp ``` Edit `cli\cli.csproj`: ```diff - net5.0 + net5.0-windows ``` ```powershell 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[bot]]

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: https://github.com/dotnet/sdk/issues/16184 - propagation of properties https://github.com/dotnet/sdk/issues/15117 - SDK should prevent mismatched configurations (since it is broken) https://github.com/dotnet/sdk/issues/1675 (fixed in https://github.com/dotnet/sdk/pull/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.