Skip to content
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

Added Framework 4.8 to all projects #1326

Merged
merged 15 commits into from
Aug 23, 2024
Merged

Added Framework 4.8 to all projects #1326

merged 15 commits into from
Aug 23, 2024

Conversation

josephmyers
Copy link
Collaborator

@josephmyers josephmyers commented Jun 6, 2024

And fixed all warnings other than those warning about Framework 4.6.1.


This change is Reviewable

@josephmyers josephmyers mentioned this pull request Jul 19, 2024
Copy link

github-actions bot commented Jul 25, 2024

LibPalaso Tests

    35 files  +   17      35 suites  +17   10m 12s ⏱️ + 1m 58s
 4 824 tests  -    68   4 593 ✅  -    68  231 💤 ±  0  0 ❌ ±0 
11 044 runs  +4 707  10 516 ✅ +4 463  528 💤 +244  0 ❌ ±0 

Results for commit 6730607. ± Comparison against base commit 8220e84.

This pull request removes 68 tests.
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_CacheFileWithUidUnknown_StatusFileFromSldrCache
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_CacheFileWithUid_StatusFileFromSldrCache
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("ar")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("en")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","ar")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","az")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","bn")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","de")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","en")
SIL.WritingSystems.Tests.SldrTests ‑ GetLdmlFile_GetsValidLDML("false","en-GB")
…

♻️ This comment has been updated with latest results.

@josephmyers josephmyers marked this pull request as ready for review July 26, 2024 04:53
Copy link
Contributor

@hahn-kev hahn-kev left a comment

Choose a reason for hiding this comment

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

I left a question about a change.

Also, I figured out why dotnet test wasn't working and you had to pass in a list of dlls. It's because each test package needs to reference <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.0" />. However when I did that I started getting some test failures. That said they seem to be due to some weird reference issues. If I start clean and use dotnet test then I get failures. However if I run a dotnet build first, then dotnet test works and the tests pass. So there's something weird going on. I'd say we would like to be able to use dotnet test without anything else, so we should look into that.

SIL.Core/IO/DirectoryHelper.cs Show resolved Hide resolved
@josephmyers josephmyers linked an issue Aug 1, 2024 that may be closed by this pull request
8 tasks
@josephmyers josephmyers marked this pull request as draft August 1, 2024 05:06
@josephmyers josephmyers removed a link to an issue Aug 1, 2024
8 tasks
@josephmyers
Copy link
Collaborator Author

SIL.WritingSystems.Tests takes a ridiculous amount of time to finish. It's 8-10 minutes on my machine, and enough on the build server to time out. This is exacerbated by increasing our supported frameworks. Seems an appropriate time to look into how we can get those tests speedier.

@josephmyers
Copy link
Collaborator Author

The majority of the pain seems to be coming from the SldrTests. We could just not run these on the build server.

@josephmyers
Copy link
Collaborator Author

4a5ad40 succeeded in 10 minutes. Why did the previous time out at 30?

@josephmyers josephmyers marked this pull request as ready for review August 6, 2024 00:15
@hahn-kev
Copy link
Contributor

@josephmyers I was seeing some tests hang when working on my writing systems tests, there's now a timeout in dotnet test to detect that so if it happens you should have some details about it at least, this is now in master.

Copy link
Contributor

@hahn-kev hahn-kev left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@hahn-kev hahn-kev left a comment

Choose a reason for hiding this comment

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

oops, it looks like the following projects actually override TargetFrameworks meaning they don't pickup net48 from Directory.Build.props

  • AddSortKey
  • SIL.Core.Desktop
  • SIL.Core
  • SIL.DblBundle
  • SIL.DictionaryServices
  • SIL.Lexicon
  • SIL.Lift
  • SIL.Linux.Logging
  • SIL.Scripture
  • SIL.TestUtilities
  • SIL.WritingSystems

@josephmyers
Copy link
Collaborator Author

oops, it looks like the following projects actually override TargetFrameworks meaning they don't pickup net48 from Directory.Build.props

  • AddSortKey
  • SIL.Core.Desktop
  • SIL.Core
  • SIL.DblBundle
  • SIL.DictionaryServices
  • SIL.Lexicon
  • SIL.Lift
  • SIL.Linux.Logging
  • SIL.Scripture
  • SIL.TestUtilities
  • SIL.WritingSystems

Good catch. So why is the test run doubled? Looks to me like it's running everything, though based on the code, it's likely not

LibPalaso Tests
   34 files  +   17     34 suites  +17   9m 32s ⏱️ - 3m 43s
4 815 tests  -    68  4 584 ✅  -    68  231 💤 ±  0  0 ❌ ±0 
9 668 runs  +4 766  9 180 ✅ +4 522  488 💤 +244  0 ❌ ±0 

Results for commit https://github.com/sillsdev/libpalaso/commit/d51226f79643393b134126283aa26325aabef746. ± Comparison against base commit 269c813.

And fixed all warnings other than those warning about Framework 4.6.1.
Should fix test failures on server
It was requiring an error thrown by .NET code to have a very specific message, where, with later versions, a different error is thrown. The newer message is still related to the original, dealing with the path, and the updated test captures the core intent without being so picky.
.NET behavior changed with 4.6.2. See here for more details: https://learn.microsoft.com/th-th/dotnet/framework/migration-guide/mitigation-path-normalization

4.6.1 DirectoryInfo apparently strips ... (and maybe similar tokens, too), particularly for its FullName property, which is being used here. This changed in 4.6.2.

Assuming that the test indicates a desire for support, the simplest thing to do is to strip dots for comparison.

I also experimented with "Switch.System.IO.UseLegacyPathHandling=true" in the app.config, but this had no discernible impact and generally seems ill-advised.
Copy link
Contributor

@hahn-kev hahn-kev left a comment

Choose a reason for hiding this comment

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

LGTM

@josephmyers josephmyers merged commit d982d80 into master Aug 23, 2024
3 checks passed
@josephmyers josephmyers deleted the net48 branch August 23, 2024 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants