TargetExt conflicts with UseAppHost
See original GitHub issueTargetExt
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.
Issue Analytics
- State:
- Created 4 years ago
- Comments:10 (10 by maintainers)
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.
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?