Inherited [TestInitialize] from a base compiled against MSTest v3 does not run under v4

[nohwnd]

When a test class compiled against MSTest v4 inherits a [TestInitialize] from a base class that was compiled against MSTest v3, the inherited method does not run. There is no build error and no discovery error, the test just runs without the setup.

I am fairly sure this is because v4 renamed the framework assembly from Microsoft.VisualStudio.TestPlatform.TestFramework to MSTest.TestFramework, so the [TestInitialize] on the v3 compiled base is a different type identity than the one the v4 adapter looks for, and the adapter does not recognize it.

Repro

Two projects, the base compiled against v3, the test against v4.

BaseLibV3/BaseLibV3.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="MSTest.TestFramework" Version="3.6.0" />
  </ItemGroup>
</Project>

BaseLibV3/TestBase.cs

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Repro
{
    public abstract class TestBase
    {
        protected bool BaseInitializeRan;

        [TestInitialize]
        public void BaseInitialize() => BaseInitializeRan = true;
    }
}

TestsV4/TestsV4.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="MSTest.TestFramework" Version="4.3.3" />
    <PackageReference Include="MSTest.TestAdapter" Version="4.3.3" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.4.0" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\BaseLibV3\BaseLibV3.csproj" />
  </ItemGroup>
</Project>

TestsV4/SampleTests.cs

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Repro
{
    [TestClass]
    public class SampleTests : TestBase
    {
        [TestMethod]
        public void InheritedTestInitialize_ShouldHaveRun()
            => Assert.IsTrue(BaseInitializeRan, "Inherited [TestInitialize] from the v3 compiled base did not run.");
    }
}

Run:

dotnet test TestsV4/TestsV4.csproj

The test fails, BaseInitializeRan is still false, so the inherited [TestInitialize] did not run. If I change only the base to reference MSTest.TestFramework 4.3.3 and rebuild, nothing else in the test changes, and it passes.

A few things I checked

The framework assembly name is different between the two versions, which is where I think the type identity mismatch comes from:

MSTest	framework assembly
3.6.0	Microsoft.VisualStudio.TestPlatform.TestFramework
4.3.3	MSTest.TestFramework

It is not a missing assembly problem. If I co-locate the v3 Microsoft.VisualStudio.TestPlatform.TestFramework.dll next to the v4 MSTest.TestFramework.dll so both are present and loadable, the result is the same.

It is not only [TestInitialize]. An inherited [TestMethod] declared on the v3 base is not discovered at all under v4 (the derived class discovers one test instead of two). [TestCleanup], and by the same logic the class and assembly level fixtures, behave the same way.

The constructor and IDisposable.Dispose do run, because those are CLR mechanisms and not matched by an MSTest attribute type, so moving the setup into the constructor is a workaround.

Environment

• MSTest.TestFramework 3.6.0 (base), 4.3.3 (test)
• MSTest.TestAdapter 4.3.3
• Microsoft.NET.Test.Sdk 18.4.0
• net8.0, dotnet SDK 10.0.302
• classic VSTest runner (dotnet test)

Is this expected with the assembly rename? If it is, would it be feasible to warn when a test type inherits a lifecycle fixture, or a test method, that is declared in a type compiled against a different MSTest major, so it does not go unnoticed?

🤖

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• TestInitialize/TestCleanup methods on base class in other assembly no longer executed as of MSTest v4? #7339

[nohwnd]

You are correct MihuBot.

To add to the reasoning why I cannot just move all of the dlls to the same version. This is a large solution, with many distinct code owners.

Meaning that we cannot move it in one big bang PR, because getting approvals from all needed approvers at once is much harder than splitting the work in many smaller PRs each with changes relevant to the approver.

And the base library cannot move because then we would break all the MSTest v3 projects.

Proposal for solutions was:

1. introduce new project Base.v4, and move to that (permanently or temporarily).
2. possibly detect the problem with analyzers, so we don't have to rely on discovering problems ourselves (e.g. test counts don't match).
3. consider Provide a (limited/best-effort) compatibility shim from MsTest 2/3 to MsTest 4 #7293 compatibility layer or type forwarding

[Evangelink]

Thanks for the detailed repro. This behavior is expected: MSTest v4 is not binary compatible with MSTest v3, and libraries compiled against v3 need to be recompiled against v4. The framework assembly rename is one part of that incompatibility, but it is not the only one.

We investigated type forwarding as well. It can bridge an unchanged marker attribute such as TestInitializeAttribute in isolation, but it cannot provide safe general compatibility. For example, v3 TestMethodAttribute references constructors and the Execute contract that no longer exist in v4, which uses the caller-information constructor and ExecuteAsync. Other framework APIs also changed. Shipping a partial forwarding facade would therefore risk inconsistent or silently incomplete test execution. This is the same conclusion as #7293.

For a staged migration, the supported approach is to create a v4 build/package of the shared base library and move consuming projects to it incrementally. Moving initialization into a constructor (and cleanup into IDisposable/IAsyncDisposable) can be a temporary lifecycle workaround, but it does not restore inherited v3 test discovery.

Closing this as by design and won't fix.