TargetExt conflicts with UseAppHost

TargetExt defaults to “.dll” on .NETCore and .NETStandard even if the OutputType is “.exe”: https://github.com/dotnet/sdk/blob/90e8a529be026d06fc8965d460927193aca5b005/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets#L74-L75

Starting with “.NETCoreApp, Version=3.0”, UseAppHost defaults to true: https://github.com/dotnet/sdk/blob/372e67d51167792db2fdaeebf48b6d8fb962e713/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets#L110

The _NativeExecutableExtension defaults to true as the DefaultAppHostRuntimeIdentifier on Windows is “win-x64”: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L67

The _GetAppHostPaths target sets the AppHostIntermediatePath property (based on _NativeExecutableExtension which defaults to “.exe” because auf UseAppHost is true) which then is added to the None ItemGroup determined to be copied to the output directory: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L491-L497

The issue is that such a file is never produced as the TargetExt defaults to “.dll”. If I got this right this means that every app “.NETCoreApp, Version=3.0” with OutputType “Exe” fails to copy its content to the output directory. This would be big break and I’m sure this would have already been caught. I assume I’m missing something here.

cc @nguerrera @dsplaisted @ericstj

[ericstj]

Yeah. Makes sense.

I think the SDK should have a test case for what it looks like to build a project without framework reference and compose references on our own. That way when new features/fixes break this it’s clearer and the SDK has the ability to look at it and create an intentional override/disable path. Otherwise we’ll end up growing an ugly set of workarounds that neither side is happy with.

In the past we could rely on a couple properties like DisableImplicitFrameworkReference and maybe something to turn off deps/runtimeconfig, but lately it seems like each milestone grows the set of workarounds we accumulate for this scenario.

[ViktorHofer]

Make sense?

Yes makes sense. I understand that this is not critical for customers but for partners like aspnetcore and us it is. How much work do you think this would be?