Updated misc articles to fix up version numbers, and update text to …

docs/articles/nunit/getting-started/dotnet-core-and-dotnet-standard.md

@@ -1,22 +1,22 @@
-# .NET Core and .NET Standard
+# .NET Core
 
 More information and getting started tutorials are available for NUnit and .NET Core targeting
 [C#](https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-nunit),
 [F#](https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-fsharp-with-nunit) and [Visual
 Basic](https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-visual-basic-with-nunit) in the .NET Core
-documentation's [Unit Testing in .NET Core and .NET Standard](https://docs.microsoft.com/en-us/dotnet/core/testing/)
+documentation's [Unit Testing in .NET Core](https://docs.microsoft.com/en-us/dotnet/core/testing/)
 page.
 
 The other information on this page is older documentation. If you follow the instructions in the [Installation
-section](xref:installation) your project will work with .NET Core and .NET Standard.
+section](xref:installation) your project will work with .NET Core.
 
 The test projects have to be .NET (Core) or .NET Framework; .NET Standard can't be used as a test project, since it
 can't be run on its own, but any code in a .NET Standard library can be tested from a .NET (Core) or .NET Framework test
 project.
 
 ## TL;DR
 
-Adding the adapter and `Microsoft.NET.Test.Sdk` version `17.0.0` or greater to your NUnit test projects will also enable
+Adding the adapter and `Microsoft.NET.Test.Sdk` version `17.8.0` or greater to your NUnit test projects will also enable
 the `dotnet test` command for .NET Core projects.
 
 Any tests using the new style CSPROJ format, either .NET Core or .NET 4.x, need to add a `PackageReference` to the NuGet
@@ -27,10 +27,10 @@ the necessary references.
 
 ```xml
   <ItemGroup>
-    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.6.0" />
-    <PackageReference Include="NUnit" Version="3.13.3" />
-    <PackageReference Include="NUnit3TestAdapter" Version="4.2.1" />
-    <PackageReference Include="NUnit.Analyzers" Version="3.6.1" />
+    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
+    <PackageReference Include="NUnit" Version="4.0.1" />
+    <PackageReference Include="NUnit3TestAdapter" Version="4.5.0" />
+    <PackageReference Include="NUnit.Analyzers" Version="3.10.0" />
     <PackageReference Include="coverlet.collector" Version="6.0.0" />
   </ItemGroup>
 ```
@@ -80,20 +80,28 @@ Framework.
 
 This limitation is the same for all test adapters including xUnit and MSTest2.
 
-#### My tests aren't showing up in Visual Studio 2017 or later
+#### My tests aren't showing up in Visual Studio 2022 or later
 
 * Are you using the NuGet adapter package?
-* Are you using version 4.1.0 or newer of the NuGet package?
+* Are you using version 4.5.0 or newer of the NuGet package?
 * Do your tests target .NET Core or the full .NET Framework? (see above)
 * Have you added a Package Reference to `Microsoft.NET.Test.Sdk`?
 * Have you restarted Visual Studio? It is still a bit temperamental.
+* Are you doing integration testing with Asp.Net Core `WebApplicationFactory` and using minimal API, and it complains
+ about missing `testhost.deps.json`?  Then you're accessing the wrong Program class in your WebApplicationFactory. Fix
+ it by adding a code line at the end of the `Program.cs` file, and verify that your WebApplicationFactory is actually
+ using this Program class:
+
+```csharp
+  public partial class Program { }
+```
 
 #### My tests multi-target .NET Core and .NET Framework, why can't I run both in Visual Studio
 
-This is a limitation of Visual Studio, hopefully it will be fixed in a future release.
+This was a limitation in earlier versions of  Visual Studio, but is fixed in Visual Studio 2022.
 
-Meanwhile, you can run specific tests using the `--framework` command line option of [dotnet
-test](https://docs.microsoft.com/en-ca/dotnet/core/tools/dotnet-test?tabs=netcore2x)
+_If_ you must run an earlier version and have this issue, you can run specific tests using the `--framework` command
+line option of [dotnet test](https://docs.microsoft.com/en-ca/dotnet/core/tools/dotnet-test?tabs=netcore2x)
 
 ## How do I produce a test results file
 

docs/articles/nunit/getting-started/upgrading.md

@@ -1,15 +1,24 @@
 # Upgrading
 
-This document assumes you are upgrading to NUnit 3.0 from NUnit 2.6 or later. While it's possible to upgrade from an
+## Upgrading from NUnit 3.X to NUnit 4.X
+
+See the [Migration Guide](xref:migrationguidance) for information on upgrading from NUnit 3.x to NUnit 4.x.
+
+Also see the [Release Notes for version 4.0.0][def] for information on breaking and other changes to see if any of these
+may affect your tests.
+
+## Upgrading from NUnit 2.6.4 to NUnit 3.0
+
+This section assumes you are upgrading to NUnit 3.0 from NUnit 2.6 or later. While it's possible to upgrade from an
 earlier version, you will need to take into account many additional changes in NUnit, which are not described here. If
 this is your situation, be sure to check the release notes for earlier versions of NUnit as well.
 
-## Review Breaking Changes
+### Review Breaking Changes
 
 The [Breaking Changes](xref:breakingchanges) page lists missing and changed functionality in NUnit 3.0. You should
 review this page to see which items are likely to affect your own tests.
 
-## Update Your Code
+### Update Your Code
 
 In many cases, the items being removed have been deprecated for some time and an alternate approach may already be
 available in your current release of NUnit. If that is the case, it will probably save you time and effort if you modify
@@ -20,15 +29,17 @@ For example, NUnit 3.0 no longer supports **ExpectedExceptionAttribute**. Howeve
 your tests and use one of the alternatives instead, you can verify that they work in your present environment and they
 will continue to work after conversion.**
 
-## Switch to NUnit 3.0
+### Switch to NUnit 3.0
 
 Remove references to your old version of NUnit and replace them with references to NUnit 3.0. In the case of NUnitLite
 executable tests, you will need to reference both the nunit.framework and NUnitLite assemblies. Compile your code. It's
 possible that you will find compiler errors due to breaking changes in NUnit 3.0, which you missed in the prior step.
 Make the necessary changes until it all works.
 
-## Make the Tests Pass
+### Make the Tests Pass
 
 Hopefully, you aren't converting tests that were not passing when you started! If all goes well, they will continue to
 pass under NUnit 3.0. If not, investigate each case and make necessary changes. If something isn't working as
 advertised, please let us know.
+
+[def]: https://docs.nunit.org/articles/nunit/release-notes/framework.html#nunit-400---november-26-2023

docs/articles/nunit/release-notes/breaking-changes.md

@@ -6,7 +6,10 @@ uid: breakingchanges
 
 ## NUnit 4.0
 
-* The [Classic Asserts](../writing-tests/assertions/assertion-models/classic.md) have been moved to a separate library
+See the [Migration Guide](xref:migrationguidance) for moving your tests from NUnit 3.x to NUnit 4.0 if you are using any
+of the following features:
+
+* The [Classic Asserts][def] have been moved to a separate library
   and their namespace and their class name were renamed to: `NUnit.Framework.Legacy.ClassicAssert`.
 * The standalone assert classes have also been moved to the `NUnit.Framework.Legacy` namespace. These classes are:
   * [CollectionAssert](../writing-tests/assertions/classic-assertions/Collection-Assert.md)
@@ -154,3 +157,5 @@ runner supports.
 | `--noshadow`       | Disable shadow copy                     | No longer supported. The console runner now disables shadow copy by default. use `--shadowcopy` on the command-line to turn it on. |
 | `--nothread`        | Disable use of a separate thread for tests  | No longer supported. |
 | `--nodots`          | Do not display dots as a progress indicator | No longer supported. |
+
+[def]: ../writing-tests/assertions/assertion-models/classic.md

docs/articles/nunit/writing-tests/assertions/assertion-models/constraint.md

@@ -25,28 +25,26 @@ overloads...
 
 ```csharp
 Assert.That(bool condition);
-Assert.That(bool condition, string message, params object[] params);
+Assert.That(bool condition, string message);
 Assert.That(bool condition, Func<string> getExceptionMessage);
 
 Assert.That(Func<bool> condition);
-Assert.That(Func<bool> condition, string message, params object[] params);
+Assert.That(Func<bool> condition, string message);
 Assert.That(Func<bool> condition, Func<string> getExceptionMessage);
 
 Assert.That<TActual>(ActualValueDelegate<TActual> del, IResolveConstraint constraint)
 Assert.That<TActual>(ActualValueDelegate<TActual> del, IResolveConstraint constraint,
-    string message, object[] params)
+    string message)
 Assert.That<TActual>(ActualValueDelegate<TActual> del, IResolveConstraint expr,
     Func<string> getExceptionMessage)
 
 Assert.That<TActual>(TActual actual, IResolveConstraint constraint)
-Assert.That<TActual>(TActual actual, IResolveConstraint constraint, string message,
-    params object[] params)
+Assert.That<TActual>(TActual actual, IResolveConstraint constraint, string message)
 Assert.That<TActual>(TActual actual, IResolveConstraint expression,
     Func<string> getExceptionMessage)
 
 Assert.That(TestDelegate del, IResolveConstraint constraint)
-Assert.That(TestDelegate code, IResolveConstraint constraint, string message,
-    params object[] args)
+Assert.That(TestDelegate code, IResolveConstraint constraint, string message)
 Assert.That(TestDelegate code, IResolveConstraint constraint,
     Func<string> getExceptionMessage)
 ```
@@ -58,7 +56,7 @@ For overloads taking a constraint, the argument must be an object implementing t
 which supports performing a test on an actual value and generating appropriate messages. This interface is described in
 more detail under [Custom Constraints](xref:customconstraints).
 
-NUnit provides a number of constraint classes similar to the **EqualConstraint** used in the example above. Generally,
+NUnit provides a number of constraint classes similar to the **EqualConstraint** used in the examples above. Generally,
 these classes may be used directly or through a syntax helper. The valid forms are described on the pages related to
 each constraint.
 

docs/articles/nunit/writing-tests/assertions/assertions.md

@@ -35,14 +35,13 @@ approach have all been implemented internally using constraints. For example...
 ### Some notes on the Classic/Legacy asserts
 
 The classic/legacy asserts, like `ClassicAssert.AreEqual`, have now been moved into its own project (namespace), and
-will later be released as a separate package.  They are now in the namespace `NUnit.Framework.Legacy`, and the `Assert`
+may later be released as a separate package.  They are now in the namespace `NUnit.Framework.Legacy`, and the `Assert`
 have been renamed to `ClassicAssert`.
 
 If you're upgrading from NUnit 3.X to NUnit 4, you need to add a using for `NUnit.Framework.Legacy` to your test
 classes, and rename all classic asserts from `Assert` to `ClassicAssert`.
 
-You *can* freely mix the constraint model assertions and the classic asserts in the same test class, but we don't
-recommend it.
+You *can* freely mix the constraint model assertions and the classic asserts in the same test class.
 
 All assertions in the `ClassicAssert` class are rerouting to use the constraint model.
 

docs/articles/nunit/writing-tests/assertions/multiple-asserts.md

@@ -54,7 +54,7 @@ end of the block if any failures were encountered, but would continue otherwise.
 Multiple assertion failures per test are stored in the representation of the test result using new XML elements, which
 are not recognized by older runners. The following runners are known to support display of the new elements:
 
-* NUnit 3 Visual Studio Adapter 3.7++ (Used by Visual Studio and `dotnet test`)
+* NUnit3 Visual Studio Adapter 3.7++ (Used by Visual Studio and `dotnet test`)
 * NUnit Console Runner 3.6++
 
 #### Compatibility