Upgraded SIL DLLs to latest stable versions

[tombogle]

No longer referencing any beta packages (e.g., L10nSharp)
Upgraded MarkDig.Signed to meet dependency requirements
Updated other packages to latest bug fix patch version for current major/minor version

---

This change is 

[github-actions]

Palaso Tests

     4 files  ±    0       4 suites  ±0   16m 9s ⏱️ + 4m 6s
 4 914 tests ±    0   4 686 ✅ ±    0  228 💤 ±  0  0 ❌ ±0 
15 994 runs  +4 078  15 310 ✅ +3 856  684 💤 +222  0 ❌ ±0 

Results for commit cc60efb. ± Comparison against base commit 35ab285.

♻️ This comment has been updated with latest results.

[imnasnainaec]

Reviewable status: 0 of 41 files reviewed, 2 unresolved discussions (waiting on @ermshiperete)

---

a discussion (no related file):
What determines which .csproj files require Markdig.Signed and which don't?

---

SIL.Windows.Forms.Scripture.Tests/SIL.Windows.Forms.Scripture.Tests.csproj line 17 at r1 (raw file):

    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.2" />
    <PackageReference Include="GitVersion.MsBuild" Version="5.11.1" PrivateAssets="all" />
    <PackageReference Include="Moq" Version="4.18.4" />

Why add Moq to SIL.Windows.Forms.Scripture.Tests when it has no tests with using Moq?

[tombogle]

Reviewable status: 0 of 41 files reviewed, 2 unresolved discussions (waiting on @ermshiperete and @imnasnainaec)

---

a discussion (no related file):

Previously, imnasnainaec (D. Ror.) wrote…

What determines which .csproj files require Markdig.Signed and which don't?

The only thing in libpalaso that uses it directly (i.e., has it as a Top-level dependency) is SIL.Windows.Forms. Most of the other SIL.Windows.Forms.* DLLs reference that, so they have it as a transitive dependency. I just noticed that SIL.Media.Tests also references it, but the thing that uses it really should be a Test App, not stuck inside the DLL with the unit tests. I think I'll change that in a separate PR.

---

SIL.Windows.Forms.Scripture.Tests/SIL.Windows.Forms.Scripture.Tests.csproj line 17 at r1 (raw file):

Previously, imnasnainaec (D. Ror.) wrote…

Why add Moq to SIL.Windows.Forms.Scripture.Tests when it has no tests with using Moq?

It is a transitive dependency there because SIL.Scripture.Tests references it, and SIL.Windows.Forms.Scripture.Tests\ScrPassageControlTests.cs uses TestScrVers, so it requires a reference to SIL.Scripture.Tests.

[tombogle]

Reviewable status: 0 of 41 files reviewed, 2 unresolved discussions (waiting on @ermshiperete and @imnasnainaec)

---

a discussion (no related file):

Previously, tombogle (Tom Bogle) wrote…

The only thing in libpalaso that uses it directly (i.e., has it as a Top-level dependency) is SIL.Windows.Forms. Most of the other SIL.Windows.Forms.* DLLs reference that, so they have it as a transitive dependency. I just noticed that SIL.Media.Tests also references it, but the thing that uses it really should be a Test App, not stuck inside the DLL with the unit tests. I think I'll change that in a separate PR.

This is the PR: #1408

[imnasnainaec]

Reviewed 15 of 41 files at r1, all commit messages.
Reviewable status: 15 of 41 files reviewed, all discussions resolved (waiting on @ermshiperete)

[tombogle]

@ermshiperete , Any idea why this is causing the Appveyor build to fail or what to do about it? The versions of System.Runtime.CompilerServices.Unsafe hasn't changed. I see there are some transitive dependencies on version 4.5.3 for some of our DLLs, though not for some that are experiencing test failures. I'm reticent to turn all these into top-level dependencies, even if I knew that would solve the problem. I could add binding redirects, but we have hitherto not needed any redirects for System.Runtime.CompilerServices.Unsafe and I'd really like to understand how this change could have suddenly introduce so many failures. all may package version changes were upgrades, so how could things suddenly want a much older version of System.Runtime.CompilerServices.Unsafe.

[ermshiperete]

@tombogle No idea. Could it be related to updating some of our components/packages from net6 to net8?

[tombogle]

Wouldn't think so, since that has all been done and merged to master.

[imnasnainaec]

@tombogle You could try rolling back the "Updated other packages to latest bug fix patch version for current major/minor version" changes...

[tombogle]

Yeah, I can troubleshoot it by making the changes incrementally. I was just hoping someone would see the obvious answer and save me that trouble.

[tombogle]

Here's what I note:

• L10nSharp is being referenced as Version="8.0.0-beta*", but since 8.00 has been released, the stable version is the version it picks up. So I can try removing the -beta* manually. Should still build and not make any difference.
• If I try to upgrade SIL.ReleaseTasks to Version 3.1.0, it complains about a downgrade of Markdig.Signed. I think that stems from SIL.BuildTasks having a transitive dependency on v. 0.30.3, while SIL.ReleaseTasks has a top-level dependency on 0.37.0. So in order to upgrade that, it seems I have to upgrade Markdig.Signed explicitly. I have created a PR on SIL.BuildTasks to try to consolidate the version there: Consolidated SIL.BuildTasks to use same version of Markdig.Signed as SIL.ReleaseTasks SIL.BuildTasks#74
• After making the above changes, I get two errors building: Could not copy the file "C:\Projects\libpalaso\output\Debug\net8.0\SIL.WritingSystems.Tests.runtimeconfig.json" because it was not found. and Could not copy the file "C:\Projects\libpalaso\output\Debug\net8.0\SIL.WritingSystems.Tests.deps.json" because it was not found. If I clean and then rebuild, those errors go away. I am vaguely suspicious that those errors might be related to the Appveyor test failures, but I can't draw any obvious connection.

[tombogle]

#1410 demonstrates that removing -beta* for L10nsharp indeed is not the cause of the Appveyor problem. (That one can be merged independently.)

[imnasnainaec]

Reviewed 3 of 41 files at r1, 1 of 31 files at r3, 39 of 39 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @ermshiperete)