-
Notifications
You must be signed in to change notification settings - Fork 485
Move tests to target .NET 8 #6437
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
Conversation
@mavasani I'm not sure whether this will pass CI or will need more work, but wanted to confirm if we want to stay on .NET 8 or we want to use .NET 7? |
41c6704
to
81cc28e
Compare
I think .NET 7 is preferable but tagging others to confirm their preference @buyaa-n @jmarolf @sharwell @stephentoub |
For reference, the .NET SDK got upgraded to .NET 8 by #6409. The PR got created and merged automatically. |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #6437 +/- ##
==========================================
+ Coverage 96.41% 96.45% +0.04%
==========================================
Files 1371 1372 +1
Lines 319011 321402 +2391
Branches 10269 10655 +386
==========================================
+ Hits 307568 310023 +2455
+ Misses 8985 8935 -50
+ Partials 2458 2444 -14 |
Build is green. In case we want to keep on .NET 8, this should be ready to merge. Otherwise, I'll see if it's easy to get back to .NET 7 without build issues |
Personally, I'd stick with .NET 7 for now until we're further along in .NET 8. |
|
@mavasani Can we merge this? |
@stephentoub are you fine with this given the comments in #6441? |
@Youssef1313 checking out your branch locally and attempting to run unit tests in VS2022 gives the following error for every test:
|
@mavasani Does deleting |
Nope, same issue. |
@sharwell Any idea? |
@Youssef1313 I have identified the root cause for this issue. It's primarily due to the hardcoding of the Microsoft.CodeAnalysis package at below places:
I am going to push the required fix to your branch. I'll also open a tracking issue for us to figure out some way to avoid this version hardcoding in source and instead derive this version from |
Strange that this is only happening after moving to .NET 8. |
It also happens if you try to run the tests with net472 as active project context. We have just delayed fixing this issue.
We would need some way for test infrastructure to be able to restore the NuGet package with specified version. I don't know if test framework supports this. Btw, moving to newer version of Microsoft.CodeAnalysis leads to whole bunch of new test failures, which all seem legitimate for the newer package. I'll try to see how much I can fix, and if required hand the PR back to you to fix more failures. |
Seems we actually do have tests which start failing when moved to newer version because they are explicitly relying on absence of new types added in later version of MS.CA. I am not sure how to go about fixing these - I am going to let these keep failing inside VS (as the tests still seem to pass from command line) and open a tracking issue to address this problem. |
@Youssef1313 So this causing almost half the tests to still fail inside VS. For example, all tests which use
|
@Youssef1313 Feel free to take a stab at this if you'd like. Seems like there many follow-up issues with the testing library to be resolved here. Meanwhile, I would suggest that we remove the net472 target for test projects, as they fail inside VS and lead to confusion. Tests with netcoreapp31 target are passing fine inside VS as well as command line, so that should probably suffice. |
@mavasani Maybe this is related to sources we have in NuGet.config? I think the test framework might be trying to restore from our root I can take a closer look on the weekend. |
It already does this (it's the only option it supports).
It's using NuGet.org as the only source unless something inside the test overrides it. |
3b683b7
to
701d201
Compare
@mavasani I rebased on latest I haven't tried before the rebase though. Could you re-test? |
108f88f
to
38fa7f1
Compare
@mavasani @stephentoub Could we get this merged? |
Since the last commit is quite old, I'm closing and re-opening to start a new build, in case something went in between that fails the changes here. |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Closes #6490