Skip to content

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.