Hello,
when trying to compile a .Net Core App (Console/Forms/WPF Exe) for Windows 10 32bit i always get
the following error message
“App Host template for the current platform not found.”
I guess this is because this Template isn’t provided for 32 bit. 
Hmm. we don’t provide the app host templates (the stub that is used to generate the .exe file); Microsoft does, and we get them via NuGet. It seems for some reason it cannot find that file.
…
It seems that Microsoft cannot be consistent so safe their own lives, and even though everywhere else they use “i386” to refer to the 32-bit intel architecture, for just this one case they use win-x86 
.
If you set
<RuntimeIdentifiers>win-x86</RuntimeIdentifiers>
instead off win-i386, it will work. I’ll update the project settings picker to reflect this.
Thanks for clarification, now it compiles and runs 
(But is not debuggable)
Do you know what’s the difference to using “dotnet.exe” as the host ?
Debugging doesn’t use the app host.
the app host really Is just s small native .exe file that has the same code as dotnet.exe to launch the app – which is in the .dll – but is hardcoded to the specific .dll.
Personally find the while idea stupid. For classic .NET, Microsoft extended the OS to allow .exe files to not be native windows executables; the OS detects this and runs the process suing .NET instead (a .NET exe has a small native .exe stub that would just print out that its a .NET app, ir un on a winds that didn’t know about .NET.
For some reason, this was way too elegant for Microsoft, so for .NET Core then went “back” to compile the main executable for a project as “.dll” (really the ONLY difference is the file extension!), but of course a .dll cant be run, and since its unintuitive for end-users to use “dotnet.exe” to run an app, they introduced the concept of these app hosts.
It;s basically a native sub that knows how to run the .NET Core app. on build we take the default stub, and we patch it with he name of your .dll, and optionally with your app’s icon, so it shows nicely Explorer. And now when you run it, it does the same as “dotnet.exe <your.dll>” would do.
But as said before, debugging doesn’t use the app host; for debugging, we (Fire/Water) launch the executable on the .NET Core runtime ourselves, using what Microsoft calls a “debug shim” (also obtained per platform from NuGet – at launch time).
How does debugging fail for you? whats the error output in Water? Which architecture of .NET Core do you have installed (you cant easily have both, not w/o major pain), x64 or x86?
Thank you. I have the same impresson concerning the missing OS integration.
And thanks for the information.
The debugging issue is the same as on the other thread.
I’ve installed the Corre versions with respect to the bitness of the OS.
Can can do further testing tomorrow.