Skip to content

Merge 2.2 to Master #6772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 29 commits into from
Jan 17, 2019
Merged

Merge 2.2 to Master #6772

merged 29 commits into from
Jan 17, 2019

Conversation

jkotalik
Copy link
Contributor

#6761

Please confirm all changes are done correctly for area owners.

jkotalik and others added 21 commits January 15, 2019 13:12
The 2.0 version of the Microsoft.Extensions.DependencyModel does not
support the assembly/file version metadata. We must have at least 2.1.

Between 2.1.6 and 2.1.7, we switched the build to use MSBuild.exe
("full" MSBuild) instead of `dotnet msbuild` ("core" MSBuild). MSBuild
has different assembly loaders behaviors in core vs full. By switching
MSBuild types, we were also unintentionally switching the version of
Microsoft.Extensions.DependencyModel.dll that was being used by our build
 task from 2.1 back down to 2.0.

The reason we didn't discover this in earlier 2.1.x patches is that
building on msbuild core automatically upgraded our build tasks to
Microsoft.Extensions.DependencyModel.dll, Version=2.1.0.0. This happens
because of differences in the way .NET Core and MSBuild handles
assemblies with the same ID and different versions, and differences in
the layout of MSBuild and the .NET Core CLI.

In the end, this happened because we didn't have test coverage. MSBuild
and custom tasks burned asagain, but we should have just had unit tests
all along, which would have uncovered this regression as soon as we
switched to msbuild.exe.
* Fix #6102 - Intense CPU utilization on page change

The issue here was that every time a Razor Page changed, we would
subscribe an additional time to the endpoint change notifications. This
means that if you tweaked a page 30 times, we would update the address
table 31 times when you save the file. If you were doing a lot of editing
then this would grow to a really large amount of computation.

The fix is to use DataSourceDependentCache, which is an existing utility
type we developed for this purpose. I'm not sure why it wasn't being
used for this already. We're already using DataSourceDependentCache in a
bunch of other places, and it's well tested.

I also tweaked the stucture of this code to be more similar to
EndpointNameAddressScheme. This involved some test changes that all
seemed like good cleanup. The way this was being tested was a little
wonky.

(cherry picked from commit a5658a8)
- do not let Templating get behind branding changes
* Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)

* Move dotnet watch to a seperate test group (#6730)

* Reuse root `version.props` in Templating
- do not let Templating get behind branding changes

* Revert "Put Razor.Design.Test and Razor.Language.Test in a different test group (#6725)" (#6753)

This reverts commit 563ff7c.

* Revert file watch test changes

Assert.Equal(originalToken, originalRegistration.Token);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Kestrel part LGTM. Thanks @jkotalik 🎉

Copy link
Member

@JamesNK JamesNK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Routing changes from @rynowak and I look good

Copy link
Member

@Tratcher Tratcher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Auth Samples

<Reference Include="Microsoft.AspNetCore.Authentication.Cookies" />
<Reference Include="Microsoft.AspNetCore.Mvc" />
<Reference Include="Microsoft.AspNetCore.StaticFiles" />
<Reference Include="Microsoft.NET.Sdk.Razor" PrivateAssets="All" />
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@natemcmaster these references were required in netcoreapp3.0. I remember you saying Microsoft.NET.Sdk.Web would bring it in.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine for now. We'll clean this up later. We need to cleanup a bunch of other projects in master, and we can do that in one sweep.

Copy link
Contributor

@natemcmaster natemcmaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@jkotalik jkotalik closed this Jan 17, 2019
@jkotalik jkotalik reopened this Jan 17, 2019
@jkotalik
Copy link
Contributor Author

Kestrel InMemory.FunctionalTests/netcoreapp3.0 hung on the last test run.

@jkotalik
Copy link
Contributor Author

Alright, I have hit ~5 runs of test failures:
https://github.com/aspnet/AspNetCore/pull/6772/checks?check_run_id=51058950
DATA_Sent_TooSlowlyDueToFlowControlOnSmallWrite_AbortsConnectionAfterGracePeriod
Microsoft.DotNet.Watcher.Tools.Tests.MsBuildFileSetFactoryTest.SingleTfm

I'm going to try running this one more time and if it fails again, someone with admin will have to merge it.

@jkotalik jkotalik closed this Jan 17, 2019
@jkotalik jkotalik reopened this Jan 17, 2019
@jkotalik jkotalik force-pushed the jkotalik/masterMerge branch from 931c109 to 2cc1323 Compare January 17, 2019 16:24
@jkotalik
Copy link
Contributor Author

@ajaybhargavb make sure the test fixes you add to DefaultRazorProjectFileSystemTest.cs and RazorCompileIntegrationTest.cs get ported to https://github.com/aspnet/aspnetcore-tooling

@jkotalik jkotalik changed the title Merge most of 2.2 to Master Merge 2.2 to Master Jan 17, 2019
@natemcmaster natemcmaster merged commit 53682c0 into master Jan 17, 2019
@natemcmaster natemcmaster deleted the jkotalik/masterMerge branch January 17, 2019 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants