- partial cherry-pick from 8be5bd6de6f5
- needed to get internal merges going again
- also correct confusion in NuGet.config from e9a385dba2
Co-authored-by: DotNet Bot <dn-bot@microsoft.com>
[release/5.0] Update dependencies from dotnet/efcore dotnet/runtime
- Merge branch 'release/5.0' into darc-release/5.0-d4478e43-6d04-47a1-8a7c-c6c2dcd90d64
- Tweak tests
- Remove Extensions.Internal.Transport from Runtime
- Microsoft.AspNetCore.App.Runtime project does not expect compilation-only references
- !fixup! Rearrange a `Condition`
- slight change to 49cc13cb5ac6 workaround
- Do not compile against assemblies with newer assembly versions
- avoid problems with e.g. System.Extensions.DependencyInjection in 5.0.1
- Revert "Remove package version pinning for ref/ assemblies in servicing (#25851)"
- dotnet/runtime assembly versions are unexpectedly changing in servicing
This reverts commit bfc1ec6792.
- Update `SharedFxTests` to handle dotnet/runtime version changes
- assemblies with non-0.0 versions end up in Microsoft.AspNetCore.App
- future-proofs these tests because more dotnet/runtime versions may change
- !fixup! Revert of bfc1ec6792 messed up `RepoTasks`
- need the RTM-versioned packages on all platforms
- we only target `net472` on Windows
Razor requires referencing two different versions of Roslyn
Razor compiler (rzc) that ships as part of the SDK. rzc ships copies of compiler binaries (Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.Common).
Razor runtime compilation is shipped as a NuGet package and needs to reference a version of Roslyn that ships as a NuGet package.
Roslyn doesn't follow the runtime ship schedule so to reliably the 2nd item, ASP.NET Core manually updates this package version. As part of 5.0.1, it was discovered that there's two different versions of these binaries in the SDK (a 3.8.0 version carried by the compiler and a 3.7.0 version carried by Razor). This is a bit vexxing, more so in source build which only builds the newer version.
Fixes#28096
Description
Update the Roslyn version referenced by Razor to 3.8.0
Customer impact
Razor compilation uses a newer version of the compiler consistent with the rest of the SDK.
Users updating to the 5.0.1 version of runtime compilation package will now use a newer version of the compiler. While it's slightly unusual to update a reference by a minor version as part of a patch release, we do not see users taking a hard dependency on the compiler version to be affected by this.
Regression
No
Risk
Low.
[release/5.0] Update dependencies from dotnet/efcore dotnet/runtime
- Return to RTM version of a package
- dotnet/runtime is not currently producing a useful Microsoft.Extensions.Internal.Transport
- quickest way to ignore the bad stuff is to pin the package here
- Update eng/Version.Details.xml
- Update eng/Version.Details.xml
- Update eng/Version.Details.xml
- Unpin Microsoft.Extensions.Internal.Transport
* Move all PublicAPI.Unshipped.txt files to PublicAPI.Shipped.txt
- we have now shipped this API surface
* Add eng/PublicAPI.empty.txt file
- make it easier to add new implementation projects
* Add missing public API baseline files
- #26784 part 1/2
- a few unexpected files turned up missing beyond the #26784 list…
* Reference Microsoft.CodeAnalysis.PublicApiAnalyzers more often
- #27484 part 2/2
- emit errors when API baseline files are missing
- update categorization of some projects
- specification tests are not implementation projects
- but _were_ project reference providers (keep that)
- correct `$(IsTestAssetProject)` setting for Razor shims et cetera
- correct `$(IsSampleProject)` setting for casing of some Sample directories
- Microsoft.AspNetCore.Analyzer.Testing should be treated as test asset
- add `$(AddPublicApiAnalyzers)` property to support overrides
- e.g. for `msbuild` task projects and tools
nit:
- remove useless `$(IsTestProject)` setting in a specification test project
- wrap some long `Condition`s
* Do not run public API analyzer in `RazorCoreCompile` target
* Remove old `$(EnableApiCheck)` settings
- property does nothing
- also remove a dangling ApiCheck comment
* Move to 5.0.1 versions
* Move to GA .NET SDK
- required for some tests to pass
* Remove feeds that won't be needed after 5.0.0 is GA
* Cherry-pick `$(CrossgenOutput)` and Directory.Build.*.in changes from master
- [master] Update dependencies from dotnet/runtime dotnet/efcore (#26788)
- 219ecd688012
- when project template tests run test assets, need latest shared Fx bits
- hit `BadImageFormatException`s otherwise
- test projects build against uploaded packages
- those packages reference the 5.0.1 shared framework
- the ASP.NET parts of the 5.0.1 shared Fx are `crossgen`ed to target Windows
- Use runtime and ref/ assemblies matching repo in Helix testing
- add Directory.Build.*.in files based on project template test infrastructure
- use files as import boundary where the project doesn't create its own Directory.Build.* files
- ensure `dotnet-watch` tests also use the latest runtime and ref/ assemblies
- Extend Helix Directory.Build.* workarounds
- generate Directory.Build.* files when restoring any projects
- include generated files in Helix runs needing the latest runtime
- copy generated files when testing `dotnet-watch` locally
- include generated content in Microsoft.NET.Sdk.BlazorWebAssembly.IntegrationTests test assets
- remove duplicate settings from existing Directory.Build.* files
- ensure shared framework and targeting packs are laid out under .dotnet/ before test assets restore
- Disable `crossgen` when building for Helix runs
- make `$(CrossgenOutput)` property override-able
- use override in CI jobs that submit to other platforms
- for now, leave the ARM64 Helix jobs alone (build on Ubuntu, run in Debian)
* Correct an `$(IsTestAssetProject)` setting
- affected projects are all test assets or provide test support
- without this, a number of the projects are incorrectly marked as shipping
* Baseline released 5.0.0 packages
- this is a complete rewrite of eng/Baseline.xml
- based on the 5.0.0 MergedManifest.xml file
* Add 5.0.0 PackageOverrides.txt and PlatformManifest.txt files
- need consistent versions when servicing targeting packs
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
* Fix some post-build signing issues
This fixes some post-build signing issues that are present in the aspnetcore repo
1. Add the .msi extension to be signed by Microsoft400 - Msis must be signed. With in-build signing these get handled explicitly by the wixproj infrastructure. When we do post build signing, we must sign these files.
2. Remove the strong name exclusions. These exclusions are incorrect when applied in post-build and unnecessary for in-build signing. Most importantly, the aspnetcore PKT would not end up re-strong named (it doesn't need to be strong name signed by ESRP since it's strong named in-build) because the PKT doesn't match any of the StrongNameSignInfo specified in arcade. The rest of the entries seem to be mostly about optimization. I could not find any performance difference between these entries being present and not. I am not sure whether they actually even apply to any assets. Moreover, when doing post-build signing, they would conflict with the entries in runtime and other places.
Verification - I have a tool that I wrote which unpacks every file between two directories and compares the strong name, nuget, and authenticode certs between equivalent files. This is the same tool being used to verify post-build signing. This tool shows no difference in any aspnetcore produced asset.
Baseline: https://dev.azure.com/dnceng/internal/_build/results?buildId=836183&view=results
Diff: https://dev.azure.com/dnceng/internal/_build/results?buildId=837176&view=results
* Do not push VS packages for installers when PostBuildSign == true
* Output wix command packages to the installers output path
* Don't import microbuild signing targets from wix when PostBuildSign=true
* Tweaks:
- Don't sign wixpacks when not in post-build signing
- Generate a wixpack for both the original msi name (which the wixproj generates) AND the name we use in the final outputs. This is because while these files are the same, signing differentiates the certificate based on the file name, and wixpack lookup is also based on the file names. Aspnetcore and other repos have uses the final outputs (e.g. dotnet-aspnetcore-runtime-123.5..) as well as the internal names (e.g. AspNetCoreSharedFramework_x64.msi).
- Don't sign msi's when not post-build signing.
* Avoid generating sha512 files for wixpack zips
* Don't run xplat code sign jobs if PostBuildSign == true
* Change original target names
* Conditionalize codesign operations
* Add publishing flag for linux x64 and add deb sha512 generation
* Do not push the x64 linux runtime archive more than once
* !!! Correct condition controlling `public` API analysis !!!
- #26785 demonstrated analyzers were inoperable
* Remove unused `public` API files
* Update `public` API files
- three Components files were missing `#nullable enable`
- `nullable` annotations missing or out-of-date elsewhere
* Ignore `public` API files completely during source build
- do not warn about unused files
* Update more `public` API files
dotnet-bot
Tanay Parikh
William Godbe
DotNet Bot
Matt Mitchell
dotnet-maestro[bot]
Michelle McDaniel
Doug Bunting
Pranav K
James Newton-King
Jan Vorlicek
Safia Abdalla