Sdk: Default apphost should take platformtarget of app into account

[nguerrera]

With x64 SDK on PATH:

1. mkdir apphost
2. cd apphost
3. dotnet new console
4. Edit apphost.csproj, set PlatformTarget to x86
5. dotnet run (or execute bin\Debug\netcoreapp3.0\apphost.exe directly)

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'D:\Temp\apphost\bin\Debug\netcoreapp3.0\apphost.dll'. An attempt was made to load a program with an incorrect format

[nguerrera]

cc @peterhuene

[nguerrera]

It occurs to me that fixing this will address a long-standing issue where F5 would use dotnet on path instead of dotnet with matching bitness. The default apphost can save us here. 😁

[peterhuene]

Should be a simple fix to coerce DefaultAppHostRuntimeIdentifier if there is a mismatch between the SDK RID and the PlatformTarget to what the PlatformTarget expects it to be (if set).

[dasMulli]

Related to https://github.com/dotnet/sdk/issues/1905

The important question is: what is the guidance wrt which property to set?
Is PlatformTarget considered for default RID selection?
I'd prefer to set RuntimeIdentifier because it is well documented and a known "knob" for .NET Core applications. Also, NuGet should resolve correct native dependencies if needed.

[peterhuene]

I think that RuntimeIdentifier is the "knob" for .NET Core. The problem here is that we have an implicit "runtime identifier" just for the apphost which only occurs when RuntimeIdentifier is _not_ specified. The use of PlatformTarget would only help hint at the desired default architecture for the apphost in this case.

Ideally, this is going to be a temporary measure for 3.0 anyway. I don't like having to restore for an additional runtime for "runtime agnostic" builds just to get the platform-specific apphost. This will be how it works for the first preview of 3.0, but I'm hoping to replace this before 3.0 releases with a better mechanism that doesn't pollute your assets graph just to enable this.

[ericstj]

@peterhuene any update on this?

[livarcocc]

Not yet. This is behind the download only package work on NuGet.

[ericstj]

Does it need to be? We could directly reference the RID-specific host packages to make sure they get downloaded for the RID-less restore, so long as the SDK can handle seeing these as runtime target items.

[nguerrera]

I think we can fix this without blocking on download only package as Peter described here: https://github.com/dotnet/sdk/issues/2632#issuecomment-434429197

[nguerrera]

I would suggest something even stronger, the fix here is separate from download only package. To pick a package, we must pick a rid. If we pick a rid wrong, it doesn't matter how we acquire the package. I would expect there to still be a concept of default rid for this feature and I would expect the fix to carry over.

[peterhuene]

I agree that I think we can fix this without relying on download-only packages. I'll work on the fix now that I'm back from vacation.