Cannot Publish when Referencing other EXE Projects

TonyValenti commented 2 years ago

Description

It is not possible to publish a single file EXE that references other EXE files in the project.

Reproduction Steps

Try to publish this attached file: MyApp.zip

Expected behavior

It should work without issue.

Actual behavior

It is not able to publish. This seems to be caused by the build process looking for "singlefilehost.exe" for the "child" EXEs and not finding it.

Regression?

Not sure.

Known Workarounds

None.

Configuration

Windows 11 x64. .NET 6.x in VS 17.2.6

Other information

The goal that I am trying to accomplish is to have a console and WPF version of my application in the same EXE. If there is a better way, I'd love to know.

ghost commented 2 years ago

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

Issue Details

### Description It is not possible to publish a single file EXE that references other EXE files in the project. ### Reproduction Steps Try to publish this attached file: [MyApp.zip](https://github.com/dotnet/runtime/files/9276705/MyApp.zip) ### Expected behavior It should work without issue. ### Actual behavior It is not able to publish. This seems to be caused by the build process looking for "singlefilehost.exe" for the "child" EXEs and not finding it. ### Regression? Not sure. ### Known Workarounds None. ### Configuration Windows 11 x64. .NET 6.x in VS 17.2.6 ### Other information The goal that I am trying to accomplish is to have a console and WPF version of my application in the same EXE. If there is a better way, I'd love to know.

Author:	TonyValenti
Assignees:	-
Labels:	`area-Single-File`
Milestone:	-

vitek-karas commented 2 years ago

Having a GUI and Console version of the app in the same exe seems to be pretty tricky on Windows. Search for example for "windows GUI app with console" there are some good links. The short version is:

Make it Console app which can use WinForms just fine, in the Main decide which version you want and run the appropriate code. The downside is that if it's launched as a GUI app with double-click it will have a console window opened by Windows (you can close that from Main, but it will always start with it)
Make it a GUI app, but in this case it's pretty tricky to hook it up to stdin/stdout of the parent console if it should behave as a Console app - AttachConsole API seems to be he way to go, but there seem to be quite a few problems either way.

.NET doesn't have any feature which would help with this. In case of single-file, I don't know what should be the meaning of trying to publish two executables into one single-file in a general case. The error should be more explicit, but I don't think .NET should support it.

TonyValenti commented 2 years ago

@vitek-karas I was hoping to leverage the fact that .Net would decompress to a temporary folder to essentially be able to do the following:

"Main" EXE is run.
If command line Args exist, run the decompressed console EXE.
Otherwise, run the WPF EXE.

vitek-karas commented 2 years ago

This would mean that you're running the CLI (command line) version as a child process. Which may be fine in your scenario (it's frequently not desirable though).

You could probably do this in two ways: Build/publish the CLI exe project explicitly as a target from your "main" exe project file - this is effectively a "Fix" for the failure you're seeing. And then one of the these:

Include it as an embedded managed resource in the "main" exe. Then when the main exe starts and you decide to use CLI, write the content of the managed resource to disk and run it - basically implement your own self-extract. I would recommend this solution as it gives you full control over the behavior - and you could even cleanup the file after it exits (which built-in self-extract doesn't do)
Include it as a content file into the single-file bundle. It will get self-extracted for you, and you can do the rest, but you don't have full control over where it goes - and it won't be cleaned up. Plus you're going to pay the price of extraction regardless if it's needed or not.

dotnet / runtime