dotnet store cross-gen all versions of a dependency

[JunTaoLuo]

From my understanding, the current dotnet store restores and cross-gens each package separately and this could lead to multiple versions of the same dependency in the store, even though we envision only one version being loaded at runtime.

This is better illustrated by the Microsoft.AspNetCore.Hosting package in the sample repro I have created at https://github.com/JunTaoLuo/StoreMultiVersion. The dependency is brought in via Microsoft.ApplicationInsights.AspNetCore:2.0.0 -> Microsoft.AspNetCore.Hosting:1.0.0 and Microsoft.AspNetCore.Server.Kestrel:2.0.0-preview1-final -> "Microsoft.AspNetCore.Hosting:2.0.0-preview1-final. This leads to both the 1.0.0 and 2.0.0-preview1-final versions of Hosting to be produced in the cache in the .out/ directory of the repro.

We envision users to consume all of our packages through the metapackage which means the version of Hosting will always resolve to 2.0.0-preview1-final, see the obj/project.assets.json and the *.deps.json files. The proposal here is that since only the 2.0.0-preview1-final version is used by the app, we should only produce stores with that resolved version by mimicking the logic in restore. Does this make sense?

cc @gkhanna79 @eerhardt @ramarag

[gkhanna79]

The proposal here is that since only the 2.0.0-preview1-final version is used by the app, we should only produce stores with that resolved version by mimicking the logic in restore

Store command has not inherent knowledge of which package will be required at runtime and should not be in the business of determining that as well. The only entity who knows this is the store profile manifest author who generates the store and they should use such knowledge to figure out what should be present or not.

[eerhardt]

The store command creates the fully expanded graph of dependencies for the packages you specify. There is no dependency version unification between separately specified packages.

The reasoning is because if someone just references Microsoft.ApplicationInsights.AspNetCore:2.0.0 in their app, and publishes against a store manifest that contains Microsoft.ApplicationInsights.AspNetCore:2.0.0 in it. The person's app will be transitively referencing Microsoft.AspNetCore.Hosting:1.0.0, because that is the version that was brought in by Microsoft.ApplicationInsights.AspNetCore:2.0.0. If the store command didn't put Microsoft.AspNetCore.Hosting:1.0.0 in the store, you'd get a behavior where one package (ApplicationInsights.AspNetCore) came from the store, but that package's dependency (AspNetCore.Hosting) needed to be published app-local.

[JunTaoLuo]

We are not concerned about the scenario of users referencing the M.Application.AspNetCore:2.0.0 package directly, and having it published app-local seems reasonable to me. In fact, we reference that package here along with M.A.Hosting (https://github.com/aspnet/AzureIntegration/blob/5d162d79e8edf195877088e530aa2a16c14915e2/src/Microsoft.AspNetCore.ApplicationInsights.HostingStartup/Microsoft.AspNetCore.ApplicationInsights.HostingStartup.csproj#L15-L16) which means the version of Hosting is always overwritten to 2.0.0 and version 1.0.0 is never used (unless specifically specified by the user). In an effort to reduce the number of redundant versions of the store, we were hoping to have dotnet store use the same version unification logic as dotnet restore.

[JunTaoLuo]

FYI @DamianEdwards @davidfowl

[ramarag]

Why do you refer M.A.Hosting 1.0 ever in M.Application.AspNetCore:2.0.0. Should you not be removing the reference there.

From the store user's perspective the App actually might not want to use M.A.Hosting 2.0 and actually downgrade it to some other version of M.A.Hosting that is the lowest common denominator.

[JunTaoLuo]

We don't ship M.ApplicationInsights.AspNetCore. That's created by the AppInsights team and they depend on our LTS 1.0.0 versions. However, in our store we would prefer hoisting up to the latest versions of our packages. If the user would like to downgrade then they will just end up with the older versions of our packages in the app local output.

My understanding is that stores are composable. If you want to, you can install the 1.0.0 store (hypothetically, but we won't be building it) and the 2.0.0 store and trim by the manifest of both. Otherwise the 2.0.0 store should only contain 2.0.0 packages and any 1.0.0 packages will be published app-local.

[ramarag]

This is the shortcoming of how the packages are specified, if we are to take a unit of dependency then nuget will compute the correct package graph. From the generic store functionality we have two options:

1. Specify the file as unit of dependency - This would imply multiple versions of the same package can never be put in the store using a single file.
2. Each PackageReference as the unit of dependency - which is what we have elected to do
3. Come up with a custom syntax to indicate a dependency group and one for specifying multiple versions

[ramarag]

By 3, I mean
PackageReference's will be restored as a group
Add another itemgroup called AdditionalPackageReference which will be restored individually.

We will have to take a breaking change to ensure that the ItemGroup names are consistent with their other usag

[gkhanna79]

@JunTaoLuo Why do we think this is required for 2.0? Store command's granularity is package and based upon the transitive closure of the packages specified.