The Problem: Rider Fails on Test Discovery

It is a common and frustrating scenario: your unit tests run perfectly from the terminal using dotnet test, but JetBrains Rider's built-in test runner fails immediately during the test discovery phase with a System.IO.FileNotFoundException:

Last runner error: Could not load file or assembly 'MyCompany.MyProject.UnitTests, Culture=neutral, PublicKeyToken=null'.
System.IO.FileNotFoundException: The system cannot find the file specified.

Even though the DLL, .deps.json, and .runtimeconfig.json exist in your bin/Debug/net8.0/ directory, Rider simply refuses to load them. This guide explores the two most common root causes and how to fix them.

Cause 1: The Assembly Name Mismatch (Dynamic MSBuild Properties)

The most common culprit in this specific scenario lies in how the <AssemblyName> is defined in your .csproj file. Take a close look at this configuration:

<PropertyGroup>
  <AssemblyName>MyCompany.MyProject.$(MSBuildProjectName)</AssemblyName>
</PropertyGroup>

If your project file is named MyCompany.MyProject.UnitTests.csproj, MSBuild resolves $(MSBuildProjectName) to MyCompany.MyProject.UnitTests.

This means your actual output assembly name becomes MyCompany.MyProject.MyCompany.MyProject.UnitTests.dll.

While dotnet test is smart enough to resolve this because it builds and executes based on the project file directly, Rider's test runner often maps test suites based on the project name itself. It looks for MyCompany.MyProject.UnitTests.dll, cannot find it, and throws a FileNotFoundException.

The Solution

Ensure your <AssemblyName> matches your project name, or explicitly simplify it. If your project file is already named MyCompany.MyProject.UnitTests.csproj, you can safely remove the <AssemblyName> property entirely, as it defaults to the project file name:

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <IsTestProject>true</IsTestProject>
  <!-- Remove or correct the AssemblyName line -->
</PropertyGroup>

If you must define a custom assembly name, make sure it matches the .csproj file name exactly to prevent test runners from getting confused.

Cause 2: Platform Target Mismatch (x64 vs. ARM64 / AnyCPU)

Another frequent cause for this error is an architecture mismatch between Rider's test runner process and your test project's build target. In your project file, you have:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
  <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

If you are running Rider on an Apple Silicon Mac (ARM64) or a Windows ARM64 device, Rider might run its test runner process as an ARM64 process by default. When it tries to load an x64 assembly, the runtime fails with a loading exception that can bubble up as a FileNotFoundException or BadImageFormatException.

The Solution

  • Option A: Change Rider's Test Runner Architecture Go to Settings/Preferences | Build, Execution, Deployment | Unit Testing. Under the MSTest or .NET Core section, look for Default platform architecture and change it from Auto or ARM64 to x64 to match your project build target.
  • Option B: Target AnyCPU Unless you have a strict native dependency that requires x64, change your PlatformTarget to AnyCPU to make your test assembly cross-platform compatible: 
    <PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
  <PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>

Cause 3: MSBuild Toolset Path Mismatch

Sometimes Rider uses its own internal MSBuild or an older Mono MSBuild instead of the .NET SDK installed on your system. This can lead to silent build discrepancies where the output isn't placed where Rider expects it.

The Solution

  1. Go to Settings/Preferences | Build, Execution, Deployment | Toolset and Build.
  2. Ensure the Use MSBuild version is set to the correct .NET SDK MSBuild (e.g., the MSBuild bundled with your .NET 8 SDK) rather than an older Visual Studio or Mono version.
  3. Clean and rebuild the solution.

Summary

If Rider fails to run tests that pass in the CLI, the issue is almost always a configuration mismatch between Rider's expectations and the actual build output. Correcting duplicated <AssemblyName> properties and ensuring your Platform Target matches Rider's runner architecture will solve the vast majority of these FileNotFoundException issues.