The Arcade SDK requires that the obj/ and bin/ folders be placed in the top-level artifacts/ folder of the repo. Although this PR does not complete our Arcade convergence, this is a step towards updating our repo to build with the Arcade SDK.
Changes:
* Set output path for build to artifacts/bin/$(ProjectName)/
* Set intermediate output path for build to artifacts/obj/$(ProjectName)/
* Cleanup .gitignore files (remove duplication between repo-root and tested gitignore files)
* Add code check which looks for project files that share the same name (could cause issues)
* Rename project files to have unique names (avoid race condition of build output)
* Update all locations which were hard-coded to expect bin/ and obj/ in the project directory
* Add overrides for tests which still assert test binaries exist in a given location relative to the source code
* Add yarn.lock file for NodeServices
* Remove references to 'npm install' (causes double-download of node modules) and replace npm commands in package.json with yarn for consistency
* Upgrade yarn to 1.15.2
* Deprecate the Microsoft.AspNetCore.App metapackage in favor of targeting and runtime packs
* Stop producing Microsoft.AspNetCore.App, and runtime.$(rid).Microsoft.AspNetCore.App
* Generate the shared framework without using 'NuGet' restore
* Stop producing intermediate packages for shared-framework only assemblies
* Put the platform manifest into the targeting pack (data/Microsoft.AspNetCore.App.PlatformManifest.txt)
* Create well-known, shared intermediate directories that installers can use to bundle content
Changes:
* Make Visual Studio 2019 a prerequisite for building this repo
* Update .sln files
* Update Windows SDK to 17134
* Update developer docs
* Disable ANCM tests
* Update to .NET Core SDK 3.0 Preview 2
* Use Microsoft.NET.Sdk.Razor as a package consistently accross the repo
* React to changes in metadata from Microsoft.NETCore.App
* React to changes in .NET Core SDK
* Attempt to workaround CodeCheck.ps1 failure which doesn't repro locally or on different agents. Possibly due to differences in the version of the PowerShell task?
* Remove dead YML file
* Rename usages of win7-{x64,x86} to win-{x64,x86}
* Update KoreBuild to 3.0.0-build-20190219.1
* Create a new package - Microsoft.AspNetCore.App.Runtime.${rid} - which contains crossgen-ed versions of shared framework assemblies. This will be used by the SDK to replace rid-split packages
* Add a task which can generate the .deps.json file for the shared framework. Unlike the existing task we have, this does not rely on consuming a .deps.json file generated by first running a restore on packages.
* Move the reference to xunit.runner.console into the normal targets and files for managing dependencies
* Produce binlogs during build
Add new command line parameters for working with the project:
* `-NoBuild`, `-NoRestore` - these already existed, but users found it hard to discover this powershell syntax: '-build:$false'
* `-Arch`/`--arch` - set the target CPU architecture to build. Defaults to x64
* `--os-name` - on non-Windows builds, manually specify if the build should target Alpine. generic Linux, or MacOS
* Rename flags used to build specific project types. The pattern now is `--build-$(group)` or `--no-build-$(group)` (In PowerShell its `-Build$(Group)` or `-NoBuild$(Group). Example: -NoBuildJava
Changes to build definitions:
* Update the ci build definition to build all supported architectures
* Support publishing multiple artifacts per job
Other changes:
* `-NoBuild` implies `-NoRestore`
* Add new properties, `TargetArchitecture`, `TargetOsName`, and `TargetRuntimeIdentifier`
* Replace usages of `SharedFxRid` with these new properties
* To make `--no-build-nodejs` actually work, replaced Components.Browser.JS.csproj with Components.Browser.JS.npmproj
* Fix errors when building for win-arm on a clean machine
* Fix a few other project errors, like using the wrong syntax for DefaultItemExcludes, or using the wrong Platform value for x86
Changes:
* Remove obsolete targets which are unnecessary now that this repo no longer builds git submodules in a separate build process
* Remove the need for static analysis of 'ArtifactInfo' items
* Simplify how the code signing task is configured
* Remove unused repo tasks
* Remove duplicate lists of external dependencies and packages to be produced
* Remove obsolete build definition
* Remove obsolete build script parameters
* Add VisualStudioSetupOutputPath
.NET Core 2.0 reached EOL last year. This removes multi-targeting our test projects and test assets to only use .NET Core 2.1 and .NET Framework 4.6.1.
Follow-up to #6078
This should solve race conditions in restoring .wixproj files.
Co-authored-by: Nate McMaster <natemcmaster@users.noreply.github.com>
Co-authored-by: Justin Kotalik <jkotalik@users.noreply.github.com>
The following package archives which are no longer used by partner teams. It is expected that these will be replaced by targeting packs.
* LZMA (was used by dotnet-cli)
* Package zips (ended up not getting used by anyone)
* Compat package zips (was used by Azure Web Apps)
- 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.
The removes the need to ship packages for assemblies which are part of Microsoft.AspNetCore.App. The implementation of this requires first building packages, and then modifying .nuspec's and categorizing packages as "noship". This will be cleaned up in the future as we continue to refactor the way this repository builds.
This should unblock the consumption of the latest .NET Core SDK, which includes breaking changes in MSBuild. We don't _really_ need the MSBuild APIs which were broken because ProdCon v1 is dead. This removes the unused ProdCon v1 tasks and targets.
This generates additional metadata for the .NET Core SDK to resolve conflicts between Microsoft.AspNetCore.App and PackageReferences which contain the same assemblies.
This changes the way Microsoft.AspNetCore.App works to follow patterns set by Microsoft.NETCore.App. Instead of being a metapackage with dozens of dependencies, this package has no dependencies. It uses RID-splitting to deliver standalone assets for self-contained deployments.
Changes:
* Implements RID-split packages for Microsoft.AspNetCore.App.
* Update shared fx deps.json generation to only include entries for the RID-specific metapackages
* Include platform-specific packages in publish output
* Remove all nuspec dependencies of Microsoft.AspNetCore.App and collect all references into the package.
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 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)
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)
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
- `AnalyzeBuildGraph` fix should correct Update Universe build break
- `VerifyCoherentVersions` fix should correct UniverseCoherence build break
nits:
- add and rename a couple of variables for clarity and reduced repetition
- remove and sort `using`s