Skip to content

Migrating sources from dotnet/extensions #19033

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 537 commits into from
Feb 21, 2020
Merged

Conversation

JunTaoLuo
Copy link
Contributor

@JunTaoLuo JunTaoLuo commented Feb 13, 2020

This PR is made on top of #19032 to simplify reviews. When approved, the changes in both PRs will be merged into master.

Update: all build/test issues have been resolved and I have re-targeted the base branch to master, I'll add more details in the PR description but this is ready to be merged.

Components being migrated:

  • M.E.FileProviders.Embedded
  • M.E.FileProviders.Embedded.Manifest.Task
  • M.E.Configuration.KeyPerFile
  • M.E.Localization
  • M.E.Localization.Abstraction
  • M.E.ObjectPool
  • M.JSInterop
  • M.JSInterop.JS
  • M.E.WebEncoders
  • M.E.Diagnostics.HealthChecks
  • M.E.Diagnostics.HealthChecks.Abstractions

Note that I anticipate that we will need to address a few more issues in collaboration with the dotnet/runtime team. Specifically:

  • How to consolidate our usages of shared sources
  • How to split up Logging.Testing
  • How to transport reference assemblies from dotnet/runtime

I'll work with @maryamariyan on the dotnet side to address the remaining concerns once there is progress on that side.

pranavkm and others added 30 commits August 16, 2019 16:19
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@969f9a1
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@f8d29bc
…otnet/extensions#2210)

- unblocks work on aspnet/AspNetCoredotnet/extensions#4923
  - arguments for inside and outside men of service reference doc gen tool are mixed by default
  - users may add either argument type to the end of the outside man's command line
- e.g. "command --unexpected unexpectedValue --expected" can now set the "expected" option
  - only "--unexpected" and "unexpectedValue" are added to RemainingArguments in that case

- default behaviour of the command-line parser is unchanged to avoid breaking existing applications
- new switch is supported only when calling `CommandLineApplication` constructor for top-level commands
  - `dotnet-getdocument` (the outside man) has no (sub)commands and expanding scope would increase churn

nits: take VS suggestions in changed files\n\nCommit migrated from dotnet/extensions@e443397
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@14efea2
…ge/release/3.0-preview9-to-release/3.0

[automated] Merge branch 'release/3.0-preview9' => 'release/3.0'\n\nCommit migrated from dotnet/extensions@a459d9e
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@a070a81
- no-op merge, no reason to wait\n\nCommit migrated from dotnet/extensions@7f64f14
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@12a28e4
…ge/release/3.0-to-master

[automated] Merge branch 'release/3.0' => 'master'\n\nCommit migrated from dotnet/extensions@d8590b1
@@ -2,12 +2,13 @@

<PropertyGroup>
<Description>A simple object pool implementation.</Description>
<TargetFramework>netstandard2.0</TargetFramework>
<TargetFrameworks>netstandard2.0;$(DefaultNetCoreTargetFramework)</TargetFrameworks>
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@JunTaoLuo JunTaoLuo added the blocked The work on this issue is blocked due to some dependency label Feb 20, 2020
@JunTaoLuo
Copy link
Contributor Author

Waiting for #19122

- Multi-target ObjectPool
- Move Embedded.Manifest.Task.Internal.Entry to the public namespace
- Remove ref assemblies from AspNetCore.Testing
- Skip TestPathUtilitiesTest since it's a pattern we want to migrate away from
- Fix FileProviders.Abstractions version in Embedded.*.nuspec
- Add workarounds for project references to FileProviders.Embedded
@JunTaoLuo JunTaoLuo force-pushed the johluo/migrating-extensions branch from b180f84 to 7d1f5d8 Compare February 20, 2020 22:00
@JunTaoLuo JunTaoLuo changed the base branch from johluo/extensions to master February 20, 2020 22:00
@JunTaoLuo JunTaoLuo changed the title Updates for extensions migrations Migrating sources from dotnet/extensions Feb 20, 2020
@JunTaoLuo
Copy link
Contributor Author

@javiercn @SteveSandersonMS who can help me take a look at the Blazor Template tests failures? I can't seem to run the tests locally so I can't debug the failure described in the CI test logs.

@JunTaoLuo
Copy link
Contributor Author

It turns out there are binlogs captured on the CI, so I might be unblocked.

@SteveSandersonMS
Copy link
Member

@JunTaoLuo Please let us know if you still need assistance after checking those logs.

Today was the final day before code-complete for the current Blazor milestone, so Javier and I were working pretty furiously on that, hence not responding sooner. Hope that's OK!

@JunTaoLuo
Copy link
Contributor Author

Turns out it's an issue with ref packs again. I'll look into a fix. This PR might need some additional verification.

@JunTaoLuo
Copy link
Contributor Author

@dotnet/aspnet-build can y'all look at this again before I merge? I'll also try to compare the ref pack outputs to ensure we didn't miss anything.

@JunTaoLuo
Copy link
Contributor Author

I verified the ref packs and everything looks good

@JunTaoLuo JunTaoLuo added this to the 5.0.0-preview2 milestone Feb 21, 2020
@JunTaoLuo JunTaoLuo removed the blocked The work on this issue is blocked due to some dependency label Feb 21, 2020
@@ -94,14 +78,17 @@ and are generated based on the last package release.
<LatestPackageReference Include="System.Net.Http" Version="$(SystemNetHttpPackageVersion)" />
<LatestPackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadataPackageVersion)" />
<LatestPackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="$(SystemRuntimeCompilerServicesUnsafePackageVersion)" />
<LatestPackageReference Include="System.Runtime.InteropServices.RuntimeInformation" Version="$(SystemRuntimeInteropServicesRuntimeInformationPackageVersion)" />
Copy link
Member

Choose a reason for hiding this comment

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

For my understanding - these were packages that (previously) Extensions depended on, but not this repo? And now we're adding a dependency on them since we're bringing in the Extensions stuff that uses them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea

Copy link
Member

@wtgodbe wtgodbe left a comment

Choose a reason for hiding this comment

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

Infra changes look reasonable - :shipit:

@JunTaoLuo JunTaoLuo merged commit 5a0526d into master Feb 21, 2020
@JunTaoLuo JunTaoLuo deleted the johluo/migrating-extensions branch February 21, 2020 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.