Skip to content
A tool to test and validate server-side WOPI implementations
C# Dockerfile
Branch: master
Clone or download
tylerbutler Add gitattributes
Normalize the line endings!
Latest commit b9457ee Jul 8, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.vscode Initial commit of validator code Jul 11, 2018
src Add a Dockerfile and publish a Docker image Jul 3, 2019
test/WopiValidator.Core.Tests Add a Dockerfile and publish a Docker image Jul 3, 2019
.editorconfig Initial commit of validator code Jul 11, 2018
.gitattributes Add gitattributes Jul 12, 2019
.gitignore Update .gitignore Jul 12, 2019
.travis.yml Work around dotnet core 2.2 issue in Travis Jul 3, 2019
Dockerfile Add a Dockerfile and publish a Docker image Jul 3, 2019
FeatureTestCases.xml Target both .NET Core/Standard and Framework 4.5 Aug 3, 2018
LICENSE Initial commit of validator code Jul 11, 2018 Add tip about docker network config Jul 12, 2019
TestCases.xml files.PutFileReturnsDifferentVersion should check Unlock version Mar 7, 2019
TestCases.xsd files.PutFileReturnsDifferentVersion should check Unlock version Mar 7, 2019
WopiValidator.sln Add files from the repo root to the .sln Oct 5, 2018

WOPI Validator



Azure Pipelines

This project contains the core logic of the WOPI validator as well as a command-line interface to it.

Quick start using Docker

You can quickly run the validator using Docker. First, pull the Docker image:

docker pull tylerbutler/wopi-validator

Then run the validator using a command like the following:

docker run -it --rm tylerbutler/wopi-validator -- -w http://localhost:5000/wopi/files/1 -t myToken -l 0 -s

Note the --; parameters after the -- will be passed to the validator itself

Tip: Depending on your network configuration, you may also need to use the --add-host parameter to ensure the docker image can resolve your WOPI host domain name. Arguments to the --add-host parameter are of the form host:IP.

Building the project

The project can be built in Visual Studio 2017, Visual Studio Code, or using dotnet build:

dotnet build -c Release

The resulting build will be output to src\WopiValidator\bin\Release\netcoreapp2.0\. Omit the -c Release portion if you want to build the debug version instead.

Building a self-contained package

To build a self-contained package for Linux or macOS, use the dotnet publish command:

dotnet publish -c Release -f netcoreapp2.0 -r linux-x64
dotnet publish -c Release -f netcoreapp2.0 -r osx-x64
dotnet publish -c Release -f netcoreapp2.0 -r win-x64

Note: you may see an error on build like this:

error MSB3030: Could not copy the file "obj\Release\netcoreapp2.0\win-x64\Microsoft.Office.WopiValidator.dll"
because it was not found.

If you see this error, you should re-build the app using the same -r option used in the publish command. For example, if you were trying to package the Linux self-contained package, first build the app using dotnet build -c Release -r linux-x64, then publish it using dotnet publish -c Release -r linux-x64.

The output will be placed in src/WopiValidator/bin/Release/netcoreapp2.0/linux-x64/publish (replace linux-x64 with other platforms as needed).

Building a Docker image

You can build a Docker image locally from the Dockerfile in the root of the repository like so:

dotnet build -c Release
docker build -t wopi-validator:latest -f Dockerfile .

Running tests

Basic unit tests can be run using the dotnet test command:

dotnet test ./test/WopiValidator.Core.Tests/WopiValidator.Core.Tests.csproj -c Release

Packing the NuGet package

From the root of the project, use the following command:

dotnet pack -c Release

The package will be output to src\WopiValidator\bin\Release\WopiValidator.1.0.0-local.nupkg

Note: if you see any errors, you may need to build the project first, as described above.


There are several ways to run the validator.

Option 1: Docker

See the quick start.

Option 2: dotnet

After building the projects as described above, you can run the resulting Microsoft.Office.WopiValidator.dll using the dotnet command. For example:

dotnet Microsoft.Office.WopiValidator.dll --token MyAccessToken --token_ttl 0 --wopisrc http://localhost:5000/wopi/files/1 --testcategory OfficeOnline --ignore-skipped

Note: the Microsoft.Office.WopiValidator.dll file can be found in src\WopiValidator\bin\Release\netcoreapp2.0\.

Option 3: dotnet run --project

You can also use the dotnet run command, passing the path to the WopiValidator.csproj file using the --project option. Arguments to the validator itself can be passed in by separating them from the dotnet run arguments with a --. For example:

dotnet run --project ./src/WopiValidator/WopiValidator.csproj --framework netcoreapp2.0 -- -t MyAccessToken -l 0 -w http://localhost:5000/wopi/files/1 -e OfficeOnline -s

Option 4: self-contained package

Another option is to build a self-contained package for your OS (see above) and execute the resulting executable file, which be called Microsoft.Office.Validator.exe on Windows and Microsoft.Office.Validator on Linux and macOS. Arguments to the validator can be passed in directly. For example:

Microsoft.Office.Validator.exe -t MyAccessToken -l 0 -w http://localhost:5000/wopi/files/1 -e OfficeOnline -s

Full usage options

Microsoft.Office.WopiValidator 1.0.0
Copyright (C) 2018 Microsoft

  -w, --wopisrc           Required. WopiSrc URL for a wopitest file

  -t, --token             Required. WOPI access token

  -l, --token_ttl         Required. WOPI access token ttl

  -c, --config            (Default: runConfig.xml) Path to XML file with test definitions

  -g, --testgroup         Run only the tests in the specified group (cannot be used with testname)

  -n, --testname          Run only the test specified (cannot be used with testgroup)

  -e, --testcategory      (Default: All) Run only the tests in the specified category

  -s, --ignore-skipped    Don't output any info about skipped tests.

  --help                  Display this help screen.

  --version               Display version information.


This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact with any additional questions or comments.

You can’t perform that action at this time.