FPLedit / AppHostPatch-Linux

This tool allows to build .NET5 GUI AppHosts for Windows on Linux, when using cross platform UI frameworks like Eto.

AppHostPatch for Linux

This tool provides an easy and containerized way tho shim some missing features in the .NET 5.0 cross platform build tools. It adds the following two features needed to build well-integrating Windows desktop apps:

• Copy resources (e.g. application icons)
• Set the WinExe bit so that no console window appears on Windows

THIS TOOL IS ONLY NEEDED WHEN BUILDING WINDOWS DESKTOP APPLICATIONS ON LINUX. And it will only work if no custom windows UI code is used, e.g. when a cross-platform UI framework like Eto or Avalonia is only consumed via NuGet!

A (hopefully quite lightweight) container based on Alpine Linux and including a 64-bit wine will be created using podman (using docker should be also possible with some modifications, see below). In this container, a self-contained .NET5 application will perform the actual task on the assembly files copied into the container. It uses the same code as the dotnet SDK on Windows (which uses P/Invoke for resource updating and thus only runs on Windows or wine).

Building the main executable

$ dotnet publish -c Release -r win-x64

Even though we are using linux, we build the application as a standalone application for Windows. This allows us to use it in wine in our container. The files in the publish folder will be the only ones that we will use from now on.

Manual execution

The shell script respatch.sh in the publish directory can be used to test the container without integrating it into msbuild. Run the following command in the linux shell. APPHOST_EXE_FILE and ASSEMBLY_DLL_FILE point to the respective output files generated by dotnet publish of your main project.

$ ./respatch.sh <APPHOST_EXE_FILE> <ASSEMBLY_DLL_FILE>

Now, APPHOST_EXE_FILE should show a non-generic icon on Windows (e.g. by testing with a VM). Currently, the GUI bit will always be set.

Integrate into msbuild

Add some lines like the following to your main project file (e.g. the one where the executable file will be generated from). Of course, you will have to adjust all the given paths to fit your folder structure. AppHostPatcher.exe must always be in the same directory as the Containerfile.

<PropertyGroup>
    <!-- Adjust this property to point to the full path of the provided Containerfile -->
    <AppHostPatch_ContainerFile>$(SolutionDir)/app_host_patch/Containerfile</AppHostPatch_ContainerFile>
    <!-- Change this to "docker" to run on docker. -->
    <AppHostPatch_ContainerTool>podman</AppHostPatch_ContainerTool>
</PropertyGroup>
<Import Project="$(SolutionDir)/AppHostPatch.targets" />

The AppHostPatcher will now run after each Publish and copy the programs resources. The GUI bit will be set if <OutputType>WinExe</OutputType> is specified in the main project file.

Docker instead of podman

Docker is untested as I am currently only using podman. All commands should run equally on docker, but only if the given user can run Docker without sudo.