XMLUnit for Java builds using Apache Maven, mainly you want to run

$ mvn install

The tests of XMLUnit depend on JUnit 4.x (legacy uses JUnit 3.x and also depends on JUnit 3.x at runtime), the matchers depend on Hamcrest.

XMLUnit for .NET uses NuGet and msbuild/xbuild - or Visual Studio 2013+ - for the traditional .NET Framework 3.5 compatible version. The .NET Standard 2,0 version uses the dotnet CLI - or Visual Studio 2017+.

When using Visual Studio the build should automatically refresh the NuGet packages, build the core and constraints assemblies as well as the unit test projects and run all NUnit tests.

When not using Visual Studio you need to install nuget as well as msbuild or xbuild and run

$ nuget restore XMLUnit.NET.NetFramework.sln

once to download the packages used by XMLUnit during the build (really only NUnit right now). After that you can run msbuild or xbuild like

$ xbuild /p:Configuration=Debug XMLUnit.NET.sln

which compiles core and constraints, builds the assemblies and executes the NUnit tests.

Tests are run using NUnit 3.x and the constraints assemblies even have a runtime dependency on NUnit 2.x and 3.x respectively.

When using Visual Studio the build should automatically refresh the NuGet packages, build the core and constraints assemblies as well as the unit test projects.

When not using Visual Studio you need to run

$ dotnet restore XMLUnit.NET.sln

once to download the packages used by XMLUnit during the build (really only NUnit right now). After that you can run dotnet like

> dotnet build XMLUnit.NET.sln -c Debug

which compiles core, constraints and placeholder and builds the assemblies. In order to run the tests use

> dotnet test src/tests/net-core/XMLUnit.Core.Tests.csproj
> dotnet test src/tests/net-constraints-nunit3/XMLUnit.NUnit3.Constraints.Test.csproj
> dotnet test src/tests/net-placeholders/XMLUnit.Placeholders.Tests.csproj

API documentation is currently not published automatically to the website but created manually. The Java SNAPSHOTs contain javadocs jars.

$ mvn javadoc:aggregate

builds javadocs for all three modules and merges them into a single documentation tree.

API docs are based on XML comments and some external files for namespace level docs. Currently the API docs are generated using monodoc, the shell script run-monodoc.sh creates static HTML documentation in build/html.

The main requirement for the API docs is "static HTML". Experimenting with Sandcastle has only lead to formats that require an extra viewer or an interactive ASP.NET webapp, neither is acceptable. If anybody known about a better option, help is very much appreciated.