Part of #4246
Changes:
* Update source code layout to follow the new conventions for this repo
* Update project files to use `<Reference>`
* Update targets to build NPM packages
* Update BuildTools to support custom 'restore' and 'test' targets
Changes:
* Condense Routing.sln into HttpAbstractions.sln
* Workaround NU1105 by adding all ProjectReferences to the .sln
* Workaround exceptions in the ReferencesHostBridge by moving Reference items to a temporary item group
* Add a 'startvs.cmd' script for launching VS with the right env variables
* Remove RangeHelper test project
* Move RangeHelper tests into StaticFiles.Tests and add target for NPM restore
- Stop producing the 'Universe' lineup package
- Removes all PackageLineup code
- Use full msbuild on Windows
- Fix invalid reference to internal.aspnetcore.sdk in 2.1.x
- Fix shared folder references for PackageArchive task.
This changes DataProtection to build as projects instead of a pseudo-submodule. It replaces Package and ProjectReference with <Reference> items which custom targets then resolve.
Changes:
* This removes MSBuild targets which invoke `docker` commands to build
deb and rpm installers
* Remove installer targets from the KoreBuild context. Put them into
separate project files
* Simplify the targets used to build installers by reducing duplicate
variable names and deeply nested MSBuild contexts
* Remove unused dependencies from the Docker build context
Changes:
* Sign shared fx zips
* Sign metapackages
* Disable signing on inner repo builds and instead sign all packages at the end
* Add a list of files from other Microsoft teams which can be excluded from signing
* Add a list of 3rd party assemblies which are bundled in the shared frameworks.
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`)
* Add build definition for Azure DevOps
* Put code for metapackages in a subfolder
* Update targets to prepare for submodules merging into this repo
* Add source code for windows installer
* Add source code for Debian installers
As a part of converging repos, we no longer need this code. It is currently buggy and slow, and we can get away without by hard-coding the repo graph (which rarely changes)
* 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.
List explicitly as .csproj files the scenarios for which the offline package cache is important
Produces new artifacts designed for various scenarios, such as:
* Docker (where xml doc files are not needed)
* Azure web apps (where 1.x SDKs must still be supported, but xml docs are not needed)
The PR #1175 was incomplete. This fixes the cascading effect of patching to 2.1.1
Changes:
- add CheckRepoGraph (ported directly from the release/2.0 branch)
- Update submodules
All packages were being ignored. This adds an error if 0 packages are found, and also fixes the folder scanned for coherence.
This also required removing the 'Private' designation from external dependencies, because we no longer scan just shipping packages,
Removed unused NoWarn metadata as well.
Nate McMaster
Nate McMaster
Justin Kotalik
John Luo