cli including store packages [2.0]

[tmds]

@omajid and I asked some questions on this PR: dotnet/cli#6460 which were unanswered, so I am creating this issue.

In the meanwhile I got some more info as I hit an issue when publishing an mvc application: https://github.com/dotnet/cli/issues/6516.

I think the PR is to populate the store with typical ASP.NET packages. Those packages will no longer be included on publish.

For RHEL, we don't want to ship binary blobs we are not building. So it would be great if we can build the CLI and not include the packages. Instead, we can include the manifest file. Then the user can use the manifest to install those packages in his store.

Does this make sense? Can we make this happen?

CC @JunTaoLuo @ellismg @bleroy @davidfowl @eerhardt @livarcocc @aslicerh

[bleroy]

Yes, you should not have to include a package store. This should be a choice of each package maintainer.

[eerhardt]

@livarcocc and @ellismg will need to work out a plan on how to build a .NET Core SDK that doesn't include the ASP.NET store or lzma offline cache. I'm not sure if this is possible today in the dotnet/cli/release/2.0.0 branch.

[tmds]

@ellismg I assigned this to you. Feel free to re-assign if not appropriate.

[tmds]

This is also an interesting change to reduce the size of the docker sdk images. They contain the asp.net store, which never gets used.

[tmds]

ref dotnet/aspnetcore#2033

[tmds]

I'm looking what is in the aspnetcore.all package. The docker dotnetcore rhel images do not contain the aspnetcore.all packages, so they are downloaded for each build.

The metapackage represents about 130MB of other packages. About half of the packages are System.* 4.3.x packages introduced with .NET Core 1.x. I think these can be replaced by a single reference to NETStandard.Library.

Not only would this halve the size of the meta package, it would also help in the effort of building it from source.

This is a list of packages which are using direct references instead of a NETStandard.Library reference:

Microsoft.CodeAnalysis.Common/2.3.0-beta1 
Microsoft.DotNet.PlatformAbstractions/2.0.0-preview2-25407-01

Serilog/2.3.0
Serilog.Sinks.File/3.2.0 
Serilog.Sinks.RollingFile/3.3.0
Serilog.Sinks.PeriodicBatching/2.1.0

Newtonsoft.Json/10.0.1

Microsoft.IdentityModel.Tokens/5.1.3 
Microsoft.IdentityModel.Logging/1.1.3   
Microsoft.IdentityModel.Protocols/2.1.3
Microsoft.IdentityModel.Protocols.OpenIdConnect/2.1.3

Remotion.Linq/2.1.1

Microsoft.Extensions.DependencyModel/2.0.0-preview2-25407-01

Microsoft.AspNetCore.Mvc.Razor
> System.Runtime.Loader

Microsoft.AspNetCore.Diagnostics/2.0.0-preview2-final
Microsoft.AspNetCore.Hosting/2.0.0-preview2-final
Microsoft.AspNetCore.MiddlewareAnalysis/2.0.0-preview2-final
Microsoft.AspNetCore.Mvc.Core/2.0.0-preview2-final
Microsoft.EntityFrameworkCore/2.0.0-preview2-final
> System.Diagnostics.DiagnosticSource

[tmds]

@JunTaoLuo @ellismg @davidfowl can you give some feedback on the suggestion -^

[leecow]

@DamianEdwards to also look at the suggestion above.

[karajas]

@tmds Do you know if there is any activity on this issue? Can this be merged with the greater ASP.NET effort, @Eilon ?

[tmds]

@karajas afaik no one is looking at this yet.

[Eilon]

Is this still true with ASP.NET Core 2.0.0? We did a big push before the release to standardize the references of the ASP.NET Core 2.0.0. It's certainly possible we missed some. But, also, many of the packages mentioned above come from other teams at Microsoft, or are 3rd party packages.

[tmds]

@Eilon Perhaps there is no more work to be done for ASP.NET Core. For the other Microsoft and 3rd party packages, it's a matter of reaching out to those folks. Most library maintainers will be happy to reduce their dependency size by using the NETStandard.Library package.

[Eilon]

Yeah it would be good to re-check and see what the current problem places are (if any).

[tmds]

Are there some changes for 2.1?

• in the way the runtime store is distributed?
• whether those packages can be built from source and bundled for use with the runtime?

[omajid]

in the way the runtime store is distributed?

Based on my understanding, the runtime store is going away in 2.1. There are just too many issues with it. It will be replaced by a asp.net core shared framework. I don't know that means in practice and whether everything will be built from source by 2.1 time-frame.

[tmds]

@DamianEdwards @JunTaoLuo Is the idea we will be able to built the asp.net core shared framework for 2.1 from https://github.com/aspnet/universe? Or should we disable the shared framework dependency during publish (similar to what we have done for 2.0 via PublishWithAspNetCoreTargetManifest=false)?

[tmds]

Replaced by #375.