Use SingleFileHost

[swaroop-sridhar]

This commit implements the following changes for single-file apps:

• When publishing self-contained single-file apps:
  • Use SingleFileHost instead of apphost
  • Trim the native components of the runtime published for the app.
  • Fixes Use SingleFileHost for self-contained single-file apps #11567.
• Implements the optional additional settings for .net 5 PublishSingleFile.

[dsplaisted]

Preferrably this should use net5.0 for the TargetFramework.

[dsplaisted]

Consider the following to avoid repeating the same Select clause:

Suggested change

	IsSelfContained ?
	IsSingleFile ? RuntimePackAssets.Where(item => !item.GetMetadata(MetadataKeys.DropFromSingleFile).Equals("true"))
	.Select(item => RuntimePackAssetInfo.FromItem(item)) :
	RuntimePackAssets.Select(item => RuntimePackAssetInfo.FromItem(item)) :
	Enumerable.Empty<RuntimePackAssetInfo>();
	IsSelfContained ?
	RuntimePackAssets.Where(item => IsSingleFile ? !item.GetMetadata(MetadataKeys.DropFromSingleFile).Equals("true") : true)
	.Select(item => RuntimePackAssetInfo.FromItem(item)) :
	Enumerable.Empty<RuntimePackAssetInfo>();

[dsplaisted]

What's the reason for having a separate _IsSingleFilePublish property rather than using PublishSingleFile directly?

[swaroop-sridhar]

The PublishSingleFile property is captured by telemetry, which reports the three states: true, false, and unset. So, I wanted to leave the user input in its pure state and use a different variable.

[swaroop-sridhar]

Thanks for the review, @dsplaisted. I have committed the changes you've suggested.

[swaroop-sridhar]

The Linux/Osx failures are because singelfilehost was not packaged into the host packages for these platforms. These will get fixed once dotnet/runtime#37147 is available in the installer repo.

[dsplaisted]

The Linux/Osx failures are because singelfilehost was not packaged into the host packages for these platforms. These will get fixed once dotnet/runtime#37147 is available in the installer repo.

So once that is fixed then you should be able to update stage 0 for this PR and merge it?

[swaroop-sridhar]

So once that is fixed then you should be able to update stage 0 for this PR and merge it?

Yes that is my plan -- would like to have it in Preview 6.

• The fix for singlefilehost is already checked in the runtime repo. I'm waiting for the changes to propagate to SDK->Installer repos, so that I can update stage0.
• With a more recent SDK (5.0.100-preview.6.20278.11) there's a new unrelated failure on Windows. Looks like there's a bug in the crossgen2 package (missing clrcompression.dll). I'm working on getting that fixed.

[swaroop-sridhar]

@dsplaisted Updating stage0 triggered crossgen2 failure: dotnet/runtime#37196.
Therefore, I disabled two crossgen2 tests in this commit: d48f3e0

I think it is a good idea to disable these tests temporarily, rather than holding the global.json update (and this PR) until dotnet/runtime#37196 is fixed.
I wanted to call this out before checking in. Thanks.

CC: @trylek.

[dsplaisted]

@dsplaisted Updating stage0 triggered crossgen2 failure: dotnet/runtime#37196.
Therefore, I disabled two crossgen2 tests in this commit: d48f3e0

I think it is a good idea to disable these tests temporarily, rather than holding the global.json update (and this PR) until dotnet/runtime#37196 is fixed.
I wanted to call this out before checking in. Thanks.

CC: @trylek.

Sounds good. We don't have a great process to track re-enabling tests like this. Will you remember to re-enable these? We could also file an issue in the sdk repo to track re-enabling the tests when the bug is fixed.

[swaroop-sridhar]

OK @dsplaisted, I filed #11845 to re-enable the tests once the underlying issue is fixed.