This removes EntityFrameworkCore as a git submodule. The EFCore repo will build on its own, and the AspNetCore repo will consume EFCore via PackageReference.
This refactors the targets used to build the shared framework and its .zip files. There are lots of reasons motivating this: Arcade convergence, migration to VSTS, making it easier to build this locally, etc.
Changes:
* Moves move content of build/Sharedfx.{props/targets} into eng/targets/SharedFx.Common.{props/targets}
* Update the build to produce a `runtime.$rid.Microsoft.AspNetCore.App` package (not just the one with symbols in it)
* Refactor the targets which produce .tar.gz/.zip files into separate projects in `src/Installers/`
* Refactor installers, unit tests, and the framework projects to use ProjectReference to flow dependencies between different parts of the build.
* Makes it easier to build the shared framework locally (for the inner dev loop, you can run `dotnet build -p src/Framework/Microsoft.AspNetCore.App/src/ -r win-x64`)
As a part of merging and reducing the number of repos we use, the aspnet/Common repo was renamed to aspnet/Extensions and it now builds on its own and not as a submodule of this repo.
This is an update of our VS dependencies to the RTM versions based on
15.8. We anticipate updating again soon in master to pick up 16.0
versions - this change is just to catch up with the current state so
there are fewer surprises.
* Add Microsoft.AspNetCore.BuildTools.ApiCheck as an external dependency
* Move the global.json files temporarily to avoid loading the wrong version of Internal.AspNetCore.Sdk
Our policy since 1.0.0 has been to always cascade version updates in the packages we own. e.g. if Logging has a product change in 2.1.x, then Kestrel, EF Core, Mvc, etc also re-ship with the updated Logging dependency. This has been done for a variety of reasons:
* NuGet does not show updates for transitive dependencies, only direct ones
* NuGet does resolves the lowest compatible transitive dependencies
* ASP.NET Core ships to both .NET Framework (where transitive dependency version matters) and .NET Core (where it matters less if you use the shared framework)
While transitive dependencies is still an important scenario, this practice of always patching has led to bigger issues.
* High probability users will unintentionally upgrade out of the shared framework: #3307
* Conflicts with metapackages that attempt to use exact version constraints: aspnet/Universe#1180
* A quality perception issue: the high volume of new versions in servicing updates with only metadata changes has created the impression that new versions of packages may not be very important. It's also made it appear like there are more issues product than there really are.
* High volume of packages changing with only metadata changes. Of the last 301 packages published in a servicing update, only 11 contained actual changes to the implementation assemblies. (3.5%)
This change implements a system to verify a new, non-cascading versioning policy for servicing updates. This required changes to repos to pin version variables to that matter per-repo,
and to remove some of the restrictions and checks.
Incidentally, this should make defining new patches easier because it automatically determines which packages are or are not patching in the release.
New package versions incoming to this patch causes a cascading change to preserve transitive dependencies
* System.Data.SqlClient
* System.Memory
* System.Runtime.CompilerServices.Unsafe
* System.Threading.Tasks.Extensions
Nate McMaster
Nate McMaster
BrennanConroy
Ryan Nowak
Brice Lambson
N. Taylor Mullen
Justin Kotalik
Ryan Brandenburg
Doug Bunting
Chris Ross (ASP.NET)