Interlook.AspNetCore.Testing.IISExpress 1.0.0

.NET Core 3.1
dotnet add package Interlook.AspNetCore.Testing.IISExpress --version 1.0.0
NuGet\Install-Package Interlook.AspNetCore.Testing.IISExpress -Version 1.0.0
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Interlook.AspNetCore.Testing.IISExpress" Version="1.0.0" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Interlook.AspNetCore.Testing.IISExpress --version 1.0.0
#r "nuget: Interlook.AspNetCore.Testing.IISExpress, 1.0.0"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Interlook.AspNetCore.Testing.IISExpress as a Cake Addin
#addin nuget:?package=Interlook.AspNetCore.Testing.IISExpress&version=1.0.0

// Install Interlook.AspNetCore.Testing.IISExpress as a Cake Tool
#tool nuget:?package=Interlook.AspNetCore.Testing.IISExpress&version=1.0.0


Adds support for instances of IIS-Express server in integration tests of Asp .Net Core projects. This may be useful, when testing Windows/AD-authentication, for example, which is not supported by test servers like Microsoft.AspNetCore.Mvc.Testing.TestServer.


Testing ASP.NET Core projects (Web-API or MVC) is not sufficiently covered with unit tests, which is why integration tests exist. In Visual Studio you normally utilize testing frameworks like, NUnit or the builtin MS-Test. Because launching tests does not regularly start an instance of IIS-Express server with the project to be tested, those tests of use in-memory test servers, like the one in the Microsoft.AspNetCore.Mvc.Testing NuGet package.

But as these test server are designed to be lightweight, they lack special features/functionalities (e.g. windows authentication). Sometimes, however, one finds oneself in a situation where you have to test even those special functionalities. You could work around this by starting your project to be tests in debug mode with VS and this IIS-Express and launching your special integration tests separately, thus blindly depending on a running test instance of your server.

With this library it's possible to launch instances of IIS-Express inside your test classes and thereby control the settings of your test server.


Essentially, there are two ways of creating an IIS-Express instance: directly or via test fixture class.

Direct Launch

The relevant class is IISExpress.

You can it like this:

using Interlook.AspNetCore.Testing.IISExpress;

// ... //

// use the actual location of your responsible applicationhost.config file
var appHostConfigFile = $"{solutionDirectory}\\.vs\\{projectName}\\config\\applicationhost.config"

// file path of the executable of your ASP.NET Core system under test (with extension)
var launcherRelativePath = "bin\\Debug\\netcoreapp3.1\\{assemblyName}.exe";

// this site must be in your applicationhost.config file
var siteName = "MySite";

// name of the application pool used by the site above (again, look in applicationhost.config)
var applicationPool = "MyAppPool"

var result =  = IISExpress.Start(appHostConfigFilePath, siteName, applicationPool, launcherRelativePath);

if(result is IISExpress.Process.Started proc)
    // IIS-Express has been started, you can communicate with it now

    // ... //

    proc.Stop();    // shuts down your started IIS-Express instance
else if(result is IISExpress.Process.Failed error)

Note, that IISExpress.Start() also takes further optional parameters, for the environment name and the full path of the IIS-Express executable file.

Use IISExpressTestServerFixture

Testing frameworks may support fixture classes for test collections, which are objects being created once before executing a sequence of tests and disposed afterwards. For example, in xUnit you use IClassFixture<MyFixtureClass> for that purpose and the constructor of your test class receives an instance of MyFixtureClass.

To use the fixture for your IIS-Express instance, create fixture class deriving from 'IISExpressTestServerFixture'

public class MyProjectTestServerFixture : IISExpressTestServerFixture
    public override string AppHostConfigFilePath => $"{SuTSolutionDirectory}\\.vs\\{SuTProjectName}\\config\\applicationhost.config";

    public override string SiteName => "MySite";

    public override string AppPool => "MyAppPool";

    public override string LauncherRelativePath => "bin\\Debug\\netcoreapp3.1\\{SuTAssemblyName}.exe";

Then, you can use it in any of your test classes, using that special endpoint of IIS-Express.

public class MyTestClassOne : IClassFixture<MyProjectTestServerFixture> // example for xUnit
    public MyTestClassOne(MyProjectTestServerFixture fixture)

Those testclasses are expected to call IDisposable.Dispose() on fixture classes, when all contained test cases are finished. In this way the test server is automatically finished.

However, if, for whatever reason, the testing framework does not utilize this IDisposable scheme, you can implement it yourself, similar to this:

public class MyTestClassOne : IClassFixture<MyProjectTestServerFixture> // example for xUnit
    private MyProjectTestServerFixture _fixture

    public MyTestClassOne(MyProjectTestServerFixture fixture)
        _fixture = fixture;_


That's basically it, guys.

Product Versions
.NET net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows net7.0 net7.0-android net7.0-ios net7.0-maccatalyst net7.0-macos net7.0-tvos net7.0-windows
.NET Core netcoreapp3.1
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.
  • .NETCoreApp 3.1

    • No dependencies.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
1.0.0 363 7/17/2020