Restore from nuget.org alone

[woksin]

Fixed

• Restoring failed for every project, because NuGet.config named a local feed by an absolute path that exists on one machine. An unreachable source is an error rather than a source to skip, so the restore never reached nuget.org
• Restoring failed as a package downgrade, because Testcontainers was pinned below the 4.13.0 that Cratis.Chronicle.XUnit.Integration requires
• Microsoft.NET.Test.Sdk was declared twice, differing only in the case of Sdk, so one package carried two pinned versions
• The console quickstart did not compile, because it reached Dialog, Window, Label, TextField and ListView directly under Terminal.Gui, where 2.x no longer keeps them

[woksin]

Found while looking at why #570 (an actions/cache bump that touches nothing but a workflow file) had a red build. The failure is not that pull request's — build has been failing on every Samples pull request for the same reason.

To keep using a local feed, add it per-machine instead: dotnet nuget add source <path> --name LocalFeed.

[woksin]

Four separate faults, found by pulling on the first. build has been failing on every Samples pull request — including #570, which changes nothing but a workflow file — and each fix only exposed the next one.

The Terminal.Gui pin is the one worth a second opinion: pinning back to 1.19.0 matches the sample as written, but migrating the sample to 2.x is the other direction and a larger change. I took the pin because it restores a green build without rewriting sample code.

[woksin]

Restore now works. build still fails, on something this pull request deliberately does not touch.

Chronicle/Quickstart/Console mixes two Terminal.Gui generations. The designer-generated files fully-qualify Terminal.Gui.Dialog, Terminal.Gui.Label, Terminal.Gui.TextField — names that 2.4.11 moved into sub-namespaces — while AddBook.cs uses Button.Accepting with CommandEventArgs, which is 2.x only. So the pin cannot be right in either direction: on 2.4.11 the designer files fail, and pinning back to 1.19.0 leaves exactly one error, CommandEventArgs.

That makes it a change to the sample, not to a version — either the designer files get the namespaces 2.4.11 actually uses, or the sample is regenerated against it. I left the pin at 2.4.11 and stopped there rather than guess at the library's current namespace layout.

Worth knowing this predates the pull request: the sample was added with a 2.x pin against code that does not compile on it, so build has been red on every Samples pull request since.

[woksin]

Took the Terminal.Gui fix after all, once I could stop guessing at it.

I pulled lib/net10.0/Terminal.Gui.xml out of the 2.4.11 package and read the namespaces off the type entries rather than inferring them: Terminal.Gui.Views for the widgets and ListViewItemEventArgs, Terminal.Gui.ViewBase for ViewArrangement and Alignment, Terminal.Gui.Input for CommandEventArgs, Terminal.Gui.App for Application. The designer files keep fully-qualifying their types, so those were rewritten in place; the hand-written files reach the same types through global usings instead of using Terminal.Gui;.

That is the direction the earlier comment left open, and the pin stays at 2.4.11 — the sample was always 2.x code, only pointed at 1.x namespaces.

[woksin]

The namespace layer is done — every CS0234/CS0246 is gone and restore is clean. What remains is four members 2.x removed or renamed, and this is where I stopped:

• Modal on the dialogs and Library — 2.4.11 has no Modal anywhere. Modality appears to be implied by how a view is run rather than set as a property.
• ListView.AllowsMarking and ListView.AllowsMultipleSelection — no successor properties. 2.x exposes MarkUnmarkSelectedItem, MarkAll, GetAllMarkedItems and IsSelectedOrMarked instead.
• ListView.OpenSelectedItem — gone; the closest are the Activated and ValueChanged events.

Each of those is a decision about what the sample should do, not a rename, and picking wrong changes runtime behaviour without failing the build. Worth someone deciding rather than me guessing.

Everything before that point is verified rather than assumed: the three restore fixes by a clean restore, the namespaces by reading them out of the package.