runtime: remove netcoreapp2.x targets#1890
Conversation
|
The patch doesn't apply: |
|
I want to bring up a prioritization issue--there's a reasonable variety of of repos using these (from a recent local build): Microsoft.NETCore.DotNetAppHost/2.0.0Microsoft.NETCore.DotNetAppHost/2.1.0(I think the other ones are fairly similar.) There could also potentially be more usages that don't show up properly in I think it will take significantly less time to use SBRP to fill these in. Since there aren't any However... it looks like we're basically run out of non-SBRP things to work on (other than Humanizer, and I'm waiting on a build to complete in a couple hours to update the table again). So I don't think it's bad to go for the good TFM fixes at the same time as the SBRP fix, but I want to let you know where I think we're at and why I think we should plan to add these into SBRP even though you're also working on this side of a fix. |
Although, there's no special tooling required to add a text-only prebuilt to SBRP. Just grab the expanded restored package and add it to SBRP under src/textOnlyPackages, copy an existing textOnlyPackage .csproj and modify it to match the pattern. |
|
I've added two more patches which should eliminate We can have a look at the prebuilt report once CI is done and then see if we want to finish this PR or use SBRPs instead. |
|
My patch that changed arcade to target |
|
I removed changes that involved |
|
This PR is also now addressing these prebuilts: Since they're 5.0-preview.3 versioned and not text only, it's not quite as nice if we stuck them in SBRP (vs. Microsoft.NETCore.DotNetHost) so I guess it will be necessary to get these TFM changes through. |
Missed what this was connected to earlier--I think adding a target to |
I pushed a commit for this, ptal. Now I hit a new issue: I think this is because the prebuilt |
dagood
left a comment
There was a problem hiding this comment.
Functionally looks fine (other than comment you noted)--comments on position and style.
Yeah, this makes sense... I suppose the replacement target needs to be conditioned on whether the repo proj does this or similar (and it applies)... there's some logic to this I don't quite have in my head at the moment: |
|
Production fails at Build source-build with: Online/Offline fail at Build tarball with: |
|
I continue to get bitten by the viral nature of the tfm change ... |
|
Oh, no, ... it's due to me removing |
|
CI is looking good. @dagood, I have also addressed your feedback about the tools.sh substitution |
|
Filed #1900 for the weird roslyn-analyzers error in one leg and pressed retry. I'd seen it before locally but assumed it was my fault at the time. |
|
CI is happy. I hope this means we are close to merging this. This is the remaining 2.0.0 host usage, xliff is no longer here: I can look at updating these projects in a new PR so we don't need a 2.0.0 sbrp. |
This is probably just a side effect of how it works, not actually usage. The prebuilt tooling looks for nupkgs that exist in the package cache first, then finds all
IMO we should just put these in SBRP. We can do it both ways in parallel, but crafting patches is riskier from a schedule perspective. (The real big prebuilt win with this PR is |
|
@dagood thanks you for helping me get past some bumps. |
Contributes to removing
Microsoft.NETCore.DotNetHost*2.x prebuilts.cc @dagood @crummel @dseefeld @omajid