Building in Visual Studio causes some tasks to be run concurrently that
would be run in a specific order in MSBuild instead. The symptom would
look like this:

	MSB4044: The "GenerateWindowsAppManifest" task was not given a
	value for the required parameter "Version".

Let's help Visual Studio realize that there are certain dependencies
between the `GetVersion` and the `GenerateWindowsAppManifest` task.

Reported by Michael J. Lyons.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

There is actually v6.3.3 already, but it does not seem to have
propagated to nuget.org yet.

While at it, use a centrally-defined property instead of repeating the
version number several times.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Previously, we only required Windows 7, but that is not recommended by
InnoSetup. Let's do enforce at least SP1 of that Windows version, which
is past its end-of-life, anyway.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It has been renamed to `GetVersionComponents()` (leaving a deprecated
shim in place of the original name).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Under certain circumstances, it is possible for `[UninstallRun]` entries
to be run multiple times. To avoid that, we now use a `RunOnceId`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Visual Studio pointed out that a couple of dependencies were in need of
being updated.

After already upgrading InnoSetup over the preceding commits, this here
commit does _almost_ what Visual Studio suggested. The only exception is
that we continue to define the `System.Text.Json` version centrally, in
`Directory.Build.props`, which Visual Studio did not know how to update
(and therefore wanted to add the dependency individually to seven
`.csproj` files instead).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Pointed out by Visual Studio.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Visual Studio pointed out that this coding pattern is preferred to
`Assert.True(false, message)`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Visual Studio pointed out a couple of instances where `Assert.Equal(0,
X.Count)` was used instead of `Assert.Empty(X)`, and similarly
`Assert.Equal(1, X.Count)` instead of `Assert.Single(X)`.

Let's accept the suggested fixes and thereby address the last remaining
warnings when building in Visual Studio.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It seems that (probably due to updated dependencies), there is a problem
where the `Trace2Exception` no longer inherits from
`InvalidOperationException`. Let's use the former, then.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

We just upgraded XUnit to a newer version, which unfortunately no longer
works with the `PlatformFact()` constructs of `Xunit.SkippableFact` even
though we updated to the latest version, v1.4.13. It might have
something to do with the fact that that package has not been updated
since July 9th, 2024.

Happily, XUnit has grown equivalent features in the meantime that we can
use instead. So let's use those XUnit-native constructs instead.

Note that we still cannot drop the `SkippableFact` dependency
altogether because we need it in the `MacOSKeychain_ReadWriteDelete`
test case. It is needed to work around a flaky test that is caused by
semi-random broken states of macOS' key-chain, and that can only be
detected while the test case is running (and hence _needs_
`AssertEx.Skip()`, which in turn requires `Xunit.Skip.If()` that is
provided only via the `SkippableFact` package and there is no equivalent
native XUnit functionality).

Helped-by: Matthew Cheetham <mattche@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>