8000 Upgrade to .Net 6.0 by peteraritchie · Pull Request #283 · fixie/fixie · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Upgrade to .Net 6.0 #283

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 7 commits into from
Closed

Upgrade to .Net 6.0 #283

wants to merge 7 commits into from

Conversation

peteraritchie
Copy link

No description provided.

@thefringeninja thefringeninja mentioned this pull request Sep 27, 2022
Closed
@plioi plioi force-pushed the main branch 2 times, most recently from 0b0e193 to 652d1dd Compare October 9, 2022 20:59
@plioi
8000 Copy link
Contributor
plioi commented Oct 10, 2022

I apologize for the delayed response here. I had a number of things to figure out before I could evaluate it against the roadmap plan with .NET 7 on the horizon, and the earth moved out from under us a bit along the way.

Short version:

Due to a lack of documentation on my part and a preexisting mistake in Fixie.Tests.csproj that is now fixed, I need to close this. In short, it'd be a breaking change for users on .NET Core 3.1 and .NET 5.0 as-is. Instead, I have merged net6.0 targeting (#290) in a way that won't break the support commitments for the Fixie 3.x line of development.

Long Version:

We had a preexisting mistake hiding in the Fixie.Tests project, where it was mistakenly using an aggresssive RollForward. The effect was to reduce the meaning of our self-tests coverage across supported frameworks. I've fixed that in #287 but naturally that impacts the runtime behavior of the self-tests precisely in the tests you had to bump here, so unfortunately you were working with incomplete/invalid feedback as you ran and troubleshot the tests.

Targeting net6.0 directly in exclusion of netcoreapp3.1 would be a breaking change, violating my (until now unpublished 🤦) roadmap plans and support commitments as net7.0 approaches. In short, it's more about multi-targeting than replacing the target framework mentions.

(Just to complicate matters, Fixie.Console correctly uses RollForward and so its TargetFramework must target the lowest supported framework in my support commitments rather than multi-target).

As soon as I tried multi-targeting, I revealed a bug in MinVer's handling of our atypical nuspec-driven Fixie.TestAdapter package, but resolved that in isolation over in #289.

Target framework changes have been a nightmare historically. It's not a nightmare this time around now that .NET is stabilizing, but Fixie happens to have a handful of atypical gotchas still, largely around the dotnet fixie command and VsTest integration. Integrating with VsTest is, in technical terms, Super Bonkers, so some pivotal things aren't going to get hit properly by an upgrade tool. There's a manual nuspec, for instance, that has to 'redundantly' mirror changes in the csproj; if we don't use an old style nuspec here, VsTest punches us square in the face at build/package time. Less nightmare, but still pretty spooky 👻.

I've finally documented the roadmap planning concerns and the intricacies of how Fixie needs to deal with phasing in and phasing out target frameworks in the wiki page Contributing to Fixie but in order to devise what the actual steps and constraints and surprises are, I had to go ahead and make the changes in a fresh branch: #290.

So, now that that has merged, I'm closing this.

I do have a few questions about the following bits which might be worthwhile in dedicated PRs:

  • Was there an issue which motivated Path.GetTempFilename() to Path.GetRandomFileName() that I need to worry about? It appears the latter produces a relative file path, and I'm not entirely sure that'd be safe (I couldn't say what counts as the 'current directory' at that point since we're messing with msbuild oddities at that point).
  • Regarding Thread.Sleep vs Task.Delay at the point where we're trying not to overwhelm the Azure DevOps API: I think at this point we don't really have concurrent work going on, so I'm not sure it would be necessary, but I admit my mind turns to spaghetti when I try to picture all the moving parts. Was there a risk I should know about aside from possible performance improvement?

@plioi plioi closed this Oct 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@peteraritchie @plioi
0