Repro
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PackAsTool>true</PackAsTool>
<PackAsToolShimRuntimeIdentifiers>win-x64;win-x86</PackAsToolShimRuntimeIdentifiers>
</PropertyGroup>
</Project>
dotnet pack
Result
C:\Users\namc\.dotnet\x64\sdk\3.0.100-preview-010166\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(228,5): error NETSDK1065: Cannot find app host for win-x64. win-x64 could be an invalid runtime identifier (RID). For more information about RID, see https://aka.ms/rid-catalog. [C:\src\aspnet\BuildTools\repro\CliTool\CliTool.csproj]
Details
Using 3.0.100-preview-010166
cc @nguerrera @wli3
Marking as blocking-partner because we cannot update aspnet to build with a new SDK until this is resolved.
@wli3
ack
@peterhuene I think something like https://github.com/dotnet/cli/issues/10566 need to happen, since PackAsTool still resolves apphost from runtime package. Could you give me a pointer to what is 3.0 way to resolve apphost?
still works for netcoreapp2.0 but not netcoreapp3.0 that's why no tests caught it
In SDK master, the apphost gets resolved via the ResolveFrameworkReferences task. This outputs an AppHostPack item that we set the AppHostSourcePath property that triggers the apphost generation logic when building and publishing.
It looks like this change broke this for tool shims, so we'll need to figure out the proper way to fix this. I can sync up with you tomorrow about it.
@natemcmaster is this blocking aspnet preview 2? @livarcocc @KathleenDollard for awareness. This won't be a straight forward bug to fix.
Not for preview 2, but it will be for preview 3
Proposed fix https://github.com/dotnet/sdk/pull/2870
Any update on this? We're trying to work on our C# 8 related features and could really use the latest version of the SDK...
cc @ajcvickers
The fix has been merged into dotnet/sdk, so now the change just needs to make its way to dotnet/core-sdk for a SDK build to contain the fix.
This should have flowed into core-sdk naturally by tomorrow. Otherwise, we can manually expedite it.
There was a conflict in the toolset maestro PR which I've now resolved to help it along its way.
Still seeing this in 3.0.100-preview-010234. Is it expected to be fixed in there?
Unfortunately it looks like dotnet/core-sdk never took a newer toolset (6 days old still) and as a result the SDK does not yet contain the fix.
We're noticing build failures in multiple repos which I assume is arcade-related; perhaps it is preventing Maestro from updating the toolset dependency in dotnet/core-sdk?
@livarcocc should we manually update the toolset to one that contains @wli3's fix to unblock repos with tool shims that would like to move to a newer 3.0 build?
let me babysit a build for now
https://github.com/dotnet/core-sdk/pull/451 manual update here
@bricelam @natemcmaster sorry for the long delay. I verified the latest core sdk build does not repro the bug.
Thanks for confirming the fix @wli3
Still seeing this on 3.0.100-preview3-010281
@bricelam The one I verified is 3.0.100-preview4-010309. Are you downloading from https://github.com/dotnet/core-sdk ?
So it won鈥檛 be fixed for preview 3? Ok, we should be able to ship preview 3 using our current version of the SDK
It might be codeflow backed up in preview 3. Toolset hasn't gone in for a while. https://github.com/dotnet/core-sdk/pull/506
@wli3 - Does the current preview3 version have this fix?
https://github.com/dotnet/core-sdk/blob/master/eng/Versions.props#L15
3.0.100-preview3.19123.1
Scaffolding build is blocked because of this. If you can confirm the version, I will send a PR to update the KoreBuild to this version.
I just checked 3.0.100-preview3-010373 is a good
Thanks! I have updated the KoreBuild to use 3.0.100-preview4-010309. If we run into any other issues. I will lower it to the above preview3 version.
Most helpful comment
I just checked 3.0.100-preview3-010373 is a good