Question on instructions for smaller footprint self-contained app

[guardrex]

@blackdwarf @mairaw

In ...

https://github.com/dotnet/docs/blob/master/docs/core/preview3/deploying/index.md#deploying-a-self-contained-deployment-with-a-smaller-footprint

... where it discusses changing ...

<TargetFramework>netcoreapp1.1</TargetFramework>

[Note: My test app is 1.1, so I changed that ☝️ to 1.1 over what's in the doc.]
... to ...

<TargetFramework>netstandard1.6</TargetFramework>

This operation indicates that, instead of using the entire netcoreapp1.0 framework, which includes .NET Core CLR, the .NET Core Library, and a number of other system components, our app uses only the .NET Standard Library.

I published the app both ways ... with the TargetFramework set to netstandard1.6 and with it set to netcoreapp1.1 and there was no difference in size: 45.5 MB (both down from 53.9 MB when using Microsoft.NETCore.App). Both apps run fine, and the published output looks identical.

Can you clarify the difference between using those two target frameworks, since I don't see a difference in app size or runtime behavior? If there is no difference, then why does the instruction say to change the TargetFramework?

Test project: https://github.com/GuardRex/testselfcontained

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

[guardrex]

This question is premature: There's still some work being done on this right now (dotnet/sdk#450 (comment)). I'll reopen later if needed.

[dsplaisted]

I think the reason you aren't seeing a size difference is because your app is referencing ASP.NET MVC, which probably brings in most everything that you could cut out by switching to the "smaller" footprint method. Try it on a "Hello World" console app and you should probably see a size difference.

[guardrex]

This subject makes more sense to me now. It's been explained to me that currently there is no difference between netstandard* and netcoreapp*. In the future, they may diverge. If they do, then a difference in app size might be seen if the TargetFramework is changed ... maybe.

There is a problem here (or a pair of problems).

This operation indicates that, instead of using the entire netcoreapp1.0 framework, which includes .NET Core CLR, the .NET Core Library, and a number of other system components, our app uses only the .NET Standard Library.

The words "using" and "includes" in the first part of the statement are troublesome: A TargetFramework of netcoreapp* does NOT bring in the runtime and host policy implementation all by itself, so the first part of the statement seems misleading (highly subject to whatever the dev thinks the words "using" and "includes" mean). You have to add add Microsoft.NETCore.Runtime.CoreCLR and Microsoft.NETCore.DotNetHostPolicy manually in package deps (or get the full Microsoft.NETCore.App metapackage) to make it a runnable app either way WRT the TargetFramework.

The other thing is that it really doesn't matter if the TargetFramework is left as netcoreapp* right now. There is an issue that I opened about a double-publish folder bug at dotnet/sdk#569. However, there isn't a difference in the size of the app or in its ability to get runnable output.

[blackdwarf]

/cc @rpetrusha

[guardrex]

I think this should go back to closed for now. I'll check again when 2.0 lands. If I can't get the small-footprint self-contained app working, I'll reopen at that time.