Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Single-File: Implement statically linked apphost #32823

Closed
swaroop-sridhar opened this issue Feb 25, 2020 · 13 comments
Closed

Single-File: Implement statically linked apphost #32823

swaroop-sridhar opened this issue Feb 25, 2020 · 13 comments
Assignees
@VSadov
Labels
area-Single-File
Milestone
5.0.0

Comments

@swaroop-sridhar
Copy link
Contributor

swaroop-sridhar commented Feb 25, 2020 •
edited
Loading

In order to support single-file apps, implement the "static-host" host-builds as described here, publish them to be consumed by the SDK.
@swaroop-sridhar swaroop-sridhar added this to the 5.0 milestone Feb 25, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Feb 25, 2020
@swaroop-sridhar swaroop-sridhar removed the untriaged New issue has not been triaged by the area owner label Feb 28, 2020
@jkotas jkotas mentioned this issue Mar 6, 2020
Merged
@tarekgh tarekgh mentioned this issue Mar 6, 2020
Closed
@swaroop-sridhar
Copy link
Contributor Author

swaroop-sridhar commented Mar 12, 2020 •
edited
Loading

Adding notes from an offline discussion:

@vitek-karas wrote:
What is the current plan to build the apphost for self-contained single-exe? Specifically the hosting layers:

  • We know we need at least some of the hosting code (parsing of .runtimeconfig.json, probably also parsing .deps.json in some cases)
  • We know we don’t need all of the code (framework resolution, most of deps processing, lot of the customizations and backward compat stuff)
  • We should not have a fork of that code – that will be hell to maintain
  • The code lives in a different place than coreclr

@swaroop-sridhar wrote:
In our previous discussion about building the super-host (for self-contained builds), we concluded that:

  • In order to support upstream scenarios (ex: AssemblyLoadContext), we’ll start with statically linking all existing host components (apphost, hostfxr, hostpolicy)
  • The checks/processes involved should be optimized by removing unnecessary checks (likely for all self-contained builds).
  • The deps.json parsing etc code will still be available, they may simply not be run in the startup path.

This is noted in the design here: https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#host-builds (although I realized not in so many words).

On Linux, we’ll additionally link the CoreCLR components to this host.

What is the plan to ship this new apphost? My understanding is that we plan to have two apphosts:

  • The existing one which will be able to handle framework-dependent normal mode, self-contained normal mode and framework-dependent single-exe mode
  • The new “superhost” with runtime and other native libs linked in which will handle self-contained single-exe mode.

Yes, for any given target, we’ll have two hosts:
• Windows/Osx: AppHost and StaticHost (host components linked)
• Linux: AppHost and SuperHost (host and runtime linked).

The main difference between apphost and superhost is that currently apphost is tiny and has no real versioning problems. On the other hand the superhost is very tied to a specific version of the runtime/corelib/corefx.
Currently apphost ships as a separate NuGet package which the SDK downloads as needed – I don’t know what are the versioning requirements today – what the SDK uses to decide which version of that package to use.

For a given TFM and RID, the SDK expects a unique apphost package, from which it obtains the apphost to use:
https://github.com/dotnet/sdk/blob/611fcdd2ce0b29abae9967ca8e425db1a4def176/src/Tasks/Microsoft.NET.Build.Tasks/ResolveAppHosts.cs#L71-L90

Will the existing infra work for superhost? Do we want to ship it in the same package as apphost or do we want it to be part of the runtime pack instead? What’s the versioning story?

I think it’s better to publish the SuperHost as its own package -- that’s only downloaded for SingleFilePublish scenarios, again based on TFM, RID, PublishSingleFile, and Self-Contained properties.

The StaticHost fits well with runtime.<arch>.microsoft.netcore.dotnetapphost (along with apphost, comhost, ijwhost, etc), since it only consists of host components. However, we may still want to ship it as a separate pack, because:

• StaticHost is a temporary artifact, till super-host is built for Windows, so staying close to superhost scenario.
• We currently don’t have plans to use static-host for all self-contained builds.
• When using the static-host, in addition to packaging these hosts, we’ll also need more information about required native binaries. Here’s the proposed list of files that are published on Windows: coreclr.dll, clrjit.dll, clrcompression.dll, mscordaccore.dll. This is a small subset of all files SDK currently obtains from runtime.<arch>.microsoft.netcore.app package. So, we need to do one of:
- Annotate FrameworkList in the runtime pack with an additional XML element to indicate the files that should be included in the singe-file scenario.
- Ship the necessary components in a separate package.

A proposal is to build the runtime.<arch>.microsoft.netcore.superhost packs as follows:
Windows/Osx

runtime.win-x64.microsoft.netcore.superhost\<version>\runtimes\win-x64\native\
    superhost.exe (even though this is just hostcomponents)
    coreclr.dll, 
    clrjit.dll, 
    clrcompression.dll, 
    mscordaccore.dll.

Linux

runtime.linux-x64.microsoft.netcore.superhost\<version>\runtimes\win-x64\native\
superhost.exe

For self-contained single file builds (only), the SDK obtains native components from runtime.<arch>.microsoft.netcore.superhost and managed components from runtime.<arch>.microsoft.netcore.app.

@swaroop-sridhar
Copy link
Contributor Author

CC: @dsplaisted @wli3

@wli3
Copy link

wli3 commented Mar 12, 2020

So that means publish self contained vs non self contained and Windows VS Linux will have different host. 1 code path now spitted to 4 code path, including how the package flows.

If so, we also need to double the apphost pack count in core-sdk. We used to have 8 apphost pack, and now it will be 16?

All of them can be done, but we need to watch out the infra load, and we may need more time to design it. Also, can they be stored in the same package? apphost and superhost? May reduce some of the issues.

@jkotas
Copy link
Member

jkotas commented Mar 12, 2020 •
edited
Loading

Also, can they be stored in the same package

I agree that it would make sense to have both hosts in the same package.

I do not think we should be calling this superhost. It does not say anything about what it is. This can be described netcoreapp single file host. I would call it netcoreapp host or single file host, but it would be a good idea for others to chime in.

@swaroop-sridhar
Copy link
Contributor Author

swaroop-sridhar commented Mar 12, 2020 •
edited
Loading

So that means publish self contained vs non self contained and Windows VS Linux will have different host. 1 code path now spitted to 4 code path, including how the package flows.

@wli3 the change will be for self-contained single-file publish vs all other paths.
I am hoping this will be two paths instead of 4:

  • PublishSingleFile self-contained will obtain native components and Apphost from a different pack
  • All other configurations will proceed as normal
    This is regardless of whether the hosts live in the same pack or two.

If so, we also need to double the apphost pack count in core-sdk. We used to have 8 apphost pack, and now it will be 16?
All of them can be done, but we need to watch out the infra load, and we may need more time to design it. Also, can they be stored in the same package? apphost and superhost? May reduce some of the issues.

I agree that it would make sense to have both hosts in the same package.

We can configure the new hosts to be set within the existing host packages if that is simpler
This involves:

  • Building the host packages versioned based on changes in the Runtime.
  • Configuring the SDK to choose the correct host from the same package.
  • Annotating the RuntimeList in the runtime pack with an additional attributes to identify the files that should be included in the singe-file scenario.

I do think we should be calling this superhost. It does not say anything about what it is. This can be described netcoreapp single file host. I would call it netcoreapp host or single file host, but it would be a good idea for others to chime in.

I agree. @samsp-msft can you please suggest the proper names for this host?

@swaroop-sridhar swaroop-sridhar assigned VSadov and unassigned lpereira Apr 30, 2020
@swaroop-sridhar swaroop-sridhar mentioned this issue May 5, 2020
Merged
@swaroop-sridhar
Copy link
Contributor Author

@dsplaisted @wli3

I wanted to note the changes to be done in the SDK to support this feature. Please take a look at it, and let me know any suggestions/corrections.

There are two main tasks that need to be done for self-contained single-file publish scenario:

  1. Use singlefilehost:
  • @VSadov's PR adds singlefilehost to the microsoft.netcore.app.host.* packages.
  • ResolveAppHosts will resolve singlefilehost to the same package as apphost, ijwhost, and comhost.
  • When publishing for self-contained single-file apps, the CreateAppHost task will be invoked with the singlefilehost path as its AppHostSourcePath. This will generate an app using singlefilehost.
  • This may not work very well for a sequence such below. However, I think fixing this case is not crucial, because the --no-build already has similar concerns for self-contained vs framework-dependent publish.
    dotnet build -r win-x64 
    dotnet publish --no-build -r win-x64 /p:PublishSingleFile=true.
  1. Trim the native components of the runtime:
  • Certain files in microsoft.netcore.app.runtime.* package are no longer necessary to be published for single-file apps.
  • For example, hostfxr and hostpolicy are not necessary since they are statically linked with singlefilehost. Later coreclr, clrjit will also be linked with the singlefilehost, and they are also not necessary. Certain other files such as createdump are excluded from the publish as a matter of policy decision.
  • This exclusion is different from ExcludeFromSingleFile
    • In this case, the files, the excluded files are not published at all (neither in the bundle nor in the publish directory beside the single-file bundle).
    • Files marked ExcludeFromSingleFile are copied to publish directory alongside the single-file app.
  • The plan to realize this exclusion of runtime components is:
    • The RuntimeList.xml in microsoft.netcore.app.runtime.* package will contain special meta-data identifying that the file is not necessary for single-file scenario
      <File FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/createdump" Type="Native" DropFromSingleFile="true"/>
    • The ResolveRuntimePackAssets task will transfer this annotation as (DropFromSingleFile) meta-data on the asset.
    • The Single-file publish targets will use this meta-data to drop these files, and not publish them in the single-file app.

@dsplaisted
Copy link
Member

@swaroop-sridhar Sounds good. Can you file an issue on the SDK for these changes? Are you planning to send a PR for them or is this something we will need to do?

FYI @marcpopMSFT

@swaroop-sridhar
Copy link
Contributor Author

Thanks @dsplaisted I was planning to implement the change, of course, with some help from SDK devs.

@swaroop-sridhar
Copy link
Contributor Author

dotnet/sdk#11567

@dsplaisted dsplaisted mentioned this issue May 6, 2020
Closed
@swaroop-sridhar
Copy link
Contributor Author

@VSadov, I think we want to see the following annotations on RuntimeList.xml

In microsoft.netcore.app.runtime.linux-x64

<FileList FrameworkName="Microsoft.NETCore.App" TargetFrameworkVersion="5.0" TargetFrameworkIdentifier=".NETCoreApp" Name=".NET 5.0">
  … managed entries … 
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/createdump" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Globalization.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Globalization.Native.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.IO.Compression.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.IO.Compression.Native.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.IO.Ports.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.IO.Ports.Native.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Native.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Net.Security.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Net.Security.Native.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Security.Cryptography.Native.OpenSsl.a" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libSystem.Security.Cryptography.Native.OpenSsl.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libclrjit.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libcoreclr.so" Type="Native"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libcoreclrtraceptprovider.so" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libdbgshim.so" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libhostfxr.so" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libhostpolicy.so" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libmscordaccore.so" Type="Native" DropFromSingleFile="true"/>
  <File   FileVersion="0.0.0.0" Path="runtimes/linux-x64/native/libmscordbi.so" Type="Native" DropFromSingleFile="true"/>
</FileList>

In microsoft.netcore.app.runtime.osx-x64

<FileList FrameworkName="Microsoft.NETCore.App" TargetFrameworkVersion="5.0" TargetFrameworkIdentifier=".NETCoreApp" Name=".NET 5.0">
  … managed entries … 
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Globalization.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Globalization.Native.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.IO.Compression.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.IO.Compression.Native.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.IO.Ports.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.IO.Ports.Native.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Native.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Net.Security.Native.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Net.Security.Native.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Security.Cryptography.Native.Apple.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Security.Cryptography.Native.Apple.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Security.Cryptography.Native.OpenSsl.a" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libSystem.Security.Cryptography.Native.OpenSsl.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libclrjit.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libcoreclr.dylib" Type="Native"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libdbgshim.dylib" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libhostfxr.dylib" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libhostpolicy.dylib" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libmscordaccore.dylib" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="0.0.0.0" Path="runtimes/osx-x64/native/libmscordbi.dylib" Type="Native" DropFromSingleFile="true"/>
</FileList>

In microsoft.netcore.app.runtime.win-*

<FileList FrameworkName="Microsoft.NETCore.App" TargetFrameworkVersion="5.0" TargetFrameworkIdentifier=".NETCoreApp" Name=".NET 5.0">
  … managed entries … 
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-console-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-console-l1-2-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-datetime-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-debug-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-errorhandling-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-file-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-file-l1-2-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-file-l2-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-handle-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-heap-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-interlocked-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-libraryloader-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-localization-l1-2-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-memory-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-namedpipe-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-processenvironment-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-processthreads-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-processthreads-l1-1-1.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-profile-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-rtlsupport-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-string-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-synch-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-synch-l1-2-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-sysinfo-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-timezone-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-core-util-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-conio-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-convert-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-environment-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-filesystem-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-heap-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-locale-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-math-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-multibyte-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-private-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-process-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-runtime-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-stdio-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-string-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-time-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/api-ms-win-crt-utility-l1-1-0.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="42.42.42.42424" Path="runtimes/win-x64/native/clrcompression.dll" Type="Native"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/clretwrc.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/clrjit.dll" Type="Native"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/coreclr.dll" Type="Native"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/createdump.exe" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/dbgshim.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/hostfxr.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/hostpolicy.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/mscordaccore.dll" Type="Native"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/mscordaccore_amd64_amd64_5.0.20.22715.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/mscordbi.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="5.0.20.22715" Path="runtimes/win-x64/native/mscorrc.dll" Type="Native" DropFromSingleFile="true"/>
  <File  FileVersion="10.0.19041.1" Path="runtimes/win-x64/native/ucrtbase.dll" Type="Native" DropFromSingleFile="true"/>
</FileList>

Can you please take a look at this? I'll work on consuming these annotations. Thanks.

@VSadov
Copy link
Member

VSadov commented May 6, 2020

not dropping native/mscordaccore.dll ?

@swaroop-sridhar
Copy link
Contributor Author

No, we'll keep that to enable dump-debugging. Please see https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#host-builds

@VSadov VSadov mentioned this issue May 15, 2020
Merged
@swaroop-sridhar swaroop-sridhar mentioned this issue May 16, 2020
Closed
30 tasks
@swaroop-sridhar
Copy link
Contributor Author

The static-host singlefilehost is implemented in #35368
Trimming native components is implemented in #36578

Generating Linux super-host singlefilehost is tracked by #37119
Consuming the singlefilehost by the SDK, and associated changes are tracked by dotnet/sdk#11567.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@VSadov VSadov

Labels
area-Single-File
Projects
None yet
Milestone
5.0.0
Development

No branches or pull requests
7 participants
@lpereira @dsplaisted @jkotas @wli3 @VSadov @swaroop-sridhar @Dotnet-GitSync-Bot