Resolve assets from targeting pack

[dsplaisted]

First steps for dotnet/cli#10085

• References "Targeting Packs" with ExcludeAssets="all", and resolves assets from the targeting packs directly (instead of going through the assets file)
• References "Runtime Packs" if necessary to support self-contained publish (these still go through the assets file for now)
• For now, hard-codes a KnownFrameworkReference to Microsoft.NETCore.App, and includes the RID graph directly. These will need to be added to core-sdk
• The list of runtime packs for each KnownFrameworkReference, and the RIDs available, will also need to be supplied by core-sdk

[dsplaisted]

TODO: Need to add an implicit reference to the Platforms package which brings in the RID graph. Currently, this is being brought in as a package dependency of Microsoft.NETCore.App (even though we are excluding all assets from it). When we resolve to an installed targeting pack, we won't have this package reference, so we'll need to implicitly reference the Platforms package. Once we do dotnet/cli#10528 or pass the runtime graph to NuGet via NuGet/Home#7351, then we can remove the implicit Platforms package reference.

EDIT: Done

[dsplaisted]

TODO: Before merging this PR, it would be nice to use a runtime.json that's bundled in dotnet/core-sdk (dotnet/cli#10104) instead of the copied version that's included in this PR.

EDIT: Done

[dsplaisted]

@peterhuene I could especially use your review of the changes to the apphost logic

[peterhuene]

LGTM regarding the apphost changes and my feedback has been addressed.

I'll let Nick also sign off on this since he had additional comments.

[peterhuene]

+1 on keeping RuntimeIdentifers modified for < 3.0 targeted apps. I've filed https://github.com/dotnet/cli/issues/10566 to clean this up.

[vitek-karas]

@nguerrera Thanks a lot, I was able to repro the failure.
It is actually not order related. If the app is executed via dotnet.exe (running the dotnet.exe from the .dotnet folder in the repo) then it works, regardless of order.
If the app is executed via the apphost (the .exe which is in the app output) then it fails. The problem is that the apphost doesn't know about the custom location of the dotnet (the .dotnet folder in the repo).

I was able to run the app successfully through the apphost by setting the DOTNET_ROOT (or DOTNET_ROOT(x86) env variable to the .dotnet folder in the repo. Then it works just fine.

I'm not sure what the typical workflow is in this repo, but I think we should fix the sdk-build-env.bat generated into the artifacts folder (this is done in here). That script should set the DOTNET_ROOT and DOTNET_ROOT(x86) to make the apphost work with the repo-local dotnet install.

Overall this behavior is by design, at least for now. There are discussions about improvements in this area (make it so that dotnet.exe also recognizes the DOTNET_ROOT variable, so that the global dotnet.exe could be used but still run with the repo-local install for example, there are other discussions of being able to influence this behavior in global.json or similar as well), but nothing close to resolution or implementation.

[nguerrera]

Hmm. We are currently setting DOTNET_ROOT in dotnet run pending those discussions. Also, I tried running the dll with custom dotnet directly.

The error message is looking for hostpolicy in the correct custom location but the wrong shared framework. So I'm confused. I will double check all of the above.

[nguerrera]

As far as workflow, I:

• checked out this change
• eng\dogfood.cmd
• mkdir \temp\repro
• cd \temp\repro
• dotnet new mvc
• dotnet run

Dogfood.cmd causes the build to use tasks and targets from the build of this repo. Sdk-build-env is just for building the repo, it will use tasks and targets from the "stage 0" / lkg the build downloaded.

I will make both of these set DOTNET_ROOT and write a doc on how they work, but I'm nearly certain this is a red herring. I won't be sure until I get to the office and retry my steps above.

[vitek-karas]

Thanks for the description @nguerrera . I think I finally got the repro of the problem you're referring to... looking into it.

[vitek-karas]

It's a bug in hostfxr. Not sure about fix yet.
It should work if the NetCoreApp version specified in the app equals the one specified in AspNet.App. If they are different we do resolve it correctly ("roll-forward"), but we screw up internal ordering and pick the wrong FX as the root FX - which leads to the error with hostpolicy.

[nguerrera]

Is putting Microsoft.NETCore.App last a reasonable workaround? We could do that.

[nguerrera]

I filed https://github.com/dotnet/core-setup/issues/4947 as a tracking issue.

Talking to @dsplaisted, sounds like a better workaround for now is not to write out netcoreapp at all when referencing one of the higher frameworks that will chain it in is referenced.

[vitek-karas]

Either should work (putting it last, or omitting completely).
Thanks for creating the issue in core-setup.

[dsplaisted]

@nguerrera @peterhuene @livarcocc I've added some more commits here, and this is ready for "final" review before merging :-)

Note that I copied in an ASP.NET Core target from Microsoft.AspNetCore.App. Per discussion with @natemcmaster, that functionality might be used in a unit test project which doesn't directly use the Web SDK. So he suggests we put it in the base SDK.

[natemcmaster]

Should we condition this target to only run when Microsoft.AspNetCore.App is referenced? If that targeting pack isn't reference, generated code may not compile since Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute would be undefined.

[dsplaisted]

I think that since you have to set the UserSecretsId property to enable this, it's probably not necessary to restrict this target to projects having an ASP.NET framework reference. If for some reason you want to set UserSecretsId without having it generate the attribute (e.g. if you aren't referencing ASP.NET), then you can always set GenerateUserSecretsAttribute to false.

[nguerrera]