DEV Community: Gunjit Chhatwal

SQL Server Locks: A Performance and Deadlock Cheat Sheet

Gunjit Chhatwal — Tue, 10 Nov 2026 04:08:34 +0000

SQL Server uses locks to protect data while concurrent sessions read and modify it. Locks preserve transaction correctness, but they also create waiting, blocking, and deadlocks. When evaluating a slow query, ask: "Is it waiting for another transaction, and what resource does it need?"

This cheat sheet explains the lock types you are most likely to encounter, how they affect query execution, and how to diagnose locking problems quickly.

Locks are not latches. Locks protect logical data and transaction consistency. Latches are lightweight internal synchronization mechanisms that protect in-memory structures such as data pages. A lock problem commonly appears as an LCK_M_* wait; a latch problem uses waits such as PAGELATCH_*.

The basic locking flow

A lock request is granted when compatible with locks already held on the resource. Otherwise, the session waits. Lock duration depends on its mode, isolation level, statement, and transaction scope. A common issue is an application modifying data and then remaining idle before committing; the statement finished, but its locks remain.

Lock modes you should recognize

Lock	Name	Typical purpose	Performance implication
`S`	Shared	Reading data	Compatible with other shared locks, but blocked by exclusive locks
`U`	Update	Reading a row before updating it	Reduces conversion deadlocks; only one update lock can target a resource
`X`	Exclusive	Inserting, updating, or deleting data	Blocks both readers and writers under locking-based isolation
`IS`	Intent Shared	Signals shared locks at a lower level	Enables efficient compatibility checks
`IX`	Intent Exclusive	Signals exclusive or update locks below	Common while rows or pages are modified
`SIX`	Shared with Intent Exclusive	Reads the larger resource while modifying lower-level resources	Restrictive; can create broad blocking
`Sch-S`	Schema Stability	Compiling and executing queries	Compatible with normal data access, but conflicts with schema modification
`Sch-M`	Schema Modification	DDL and some metadata changes	Highly restrictive; can block nearly all access to the object
`BU`	Bulk Update	Bulk-loading data under qualifying options	Allows optimized bulk operations but restricts competing access
`Range*`	Key-range locks	Protects index ranges under `SERIALIZABLE`	Prevents phantom rows but can lock gaps and increase blocking

Shared, update, and exclusive locks

A shared lock allows concurrent readers. An exclusive lock prevents another session from reading or changing the resource under conventional READ COMMITTED locking. Update locks are an intermediate mode used when reading data that may be changed. They help avoid two sessions acquiring shared locks and both attempting to convert them to exclusive locks.

Intent locks

Intent locks describe activity lower in the lock hierarchy. An IX table lock usually means exclusive locks exist, or will exist, on pages, keys, or rows. It does not mean the whole table is exclusively locked. Intent modes quickly reveal whether a table-level request conflicts with lower-level activity.

Schema locks

Sch-S locks occur during query compilation and execution, even with NOLOCK. Sch-M locks occur during schema changes and conflict with Sch-S. A long query can delay DDL, while schema modification can block ordinary queries.

Key-range locks

Under SERIALIZABLE, SQL Server may lock index keys and gaps between them. This prevents inserts that would newly satisfy an earlier predicate. Key-range locks provide strong consistency but can greatly expand the protected area, especially without supporting indexes.

Lock granularity: what is being locked?

SQL Server can lock resources at several levels:

KEY locks protect index entries. Even queries described as "row locking" often show KEY resources.
RID locks protect rows in a heap, which is a table without a clustered index.
PAGE locks protect an 8 KB data or index page.
OBJECT locks protect a table or similar object.
HoBT locks protect a heap or B-tree, including an individual partition.
METADATA, DATABASE, and ALLOCATION_UNIT locks protect broader internal resources.

Fine-grained locks improve concurrency but consume memory. Coarser locks use fewer resources but block more operations.

Lock escalation

Lock escalation replaces many fine-grained locks with a coarser lock. SQL Server attempts escalation when a single statement acquires at least roughly 5,000 locks on one table or index reference, and it can also escalate under lock-memory pressure. Escalation is normally to a table lock; a partitioned table can escalate to a partition when LOCK_ESCALATION = AUTO. SQL Server does not escalate row or key locks to page locks.

If another session holds an incompatible lock that prevents escalation, the statement continues with fine-grained locks and SQL Server retries later. Escalation can turn a large modification into a whole-table blocker. Reduce its likelihood with shorter transactions, batched changes, and indexes that prevent unnecessary scans. Disabling escalation can exchange blocking for excessive lock memory.

Compatibility at a glance

The full compatibility matrix is extensive, but this reduced view covers common investigations:

Held \ Requested	`S`	`U`	`X`	`IS`	`IX`
`S`	Yes	Yes	No	Yes	No
`U`	Yes	No	No	Yes	No
`X`	No	No	No	No	No
`IS`	Yes	Yes	No	Yes	Yes
`IX`	No	No	No	Yes	Yes

Compatibility alone does not explain every wait. Locks may cover different resources, and a request can wait behind another waiter because SQL Server generally preserves queue fairness.

How isolation levels change locking

Isolation level	Important locking behavior
`READ UNCOMMITTED`	Allows dirty reads and usually avoids shared data locks; rows can be missing, duplicated, or inconsistent
`READ COMMITTED`	SQL Server default; shared row/page locks are generally released as data is read, allowing later rereads to change
`REPEATABLE READ`	Holds shared locks until transaction end, preventing changed or deleted rereads
`SERIALIZABLE`	Adds key-range protection and prevents phantoms; highest blocking risk
`SNAPSHOT`	Uses row versions for reads; update conflicts are possible; writes still use locks
`READ COMMITTED SNAPSHOT`	Changes `READ COMMITTED` reads to use row versions; writers still lock

SNAPSHOT requires ALLOW_SNAPSHOT_ISOLATION to be enabled. Azure SQL Database commonly enables READ_COMMITTED_SNAPSHOT by default, while boxed SQL Server does not. Row versioning reduces reader-writer blocking but does not eliminate writer-writer blocking, schema conflicts, or poor transaction design. It also adds version-store usage, and competing snapshot updates can fail with error 3960.

NOLOCK is not a performance fix. It uses READ UNCOMMITTED, permitting dirty, missing, or duplicated rows, and it still acquires schema-stability locks. Use it only when those correctness risks are explicitly acceptable.

Blocking versus deadlocks

Blocking is expected synchronization: one session waits until another releases an incompatible lock. A deadlock is a cycle in which sessions wait for one another and none can proceed.

SQL Server detects the cycle and chooses a victim, which receives error 1205 and is rolled back. Applications should use bounded retries for idempotent operations, but retries do not fix recurring deadlocks.

Typical fixes include consistent object access order, shorter transactions, indexes that reduce scanned rows, no user interaction inside transactions, and smaller batches. The deadlock graph identifies participating processes, resources, lock modes, and statements.

Reproducible locking labs

Run these examples only on a development SQL Server where you can create a disposable database. They were validated on SQL Server 2022 Developer Edition. Open two query windows and label them Session A and Session B. Run this setup once; DROP TABLE IF EXISTS requires SQL Server 2016 or later.

USE master;
GO

IF DB_ID(N'LockLab') IS NULL
    CREATE DATABASE LockLab;
GO

USE LockLab;
GO

DROP TABLE IF EXISTS dbo.LockDemo;

CREATE TABLE dbo.LockDemo
(
    Id int NOT NULL
        CONSTRAINT PK_LockDemo PRIMARY KEY,
    AccountName varchar(30) NOT NULL,
    Balance int NOT NULL,
    ReferenceCode int NOT NULL
);

CREATE INDEX IX_LockDemo_ReferenceCode
    ON dbo.LockDemo (ReferenceCode);

INSERT dbo.LockDemo (Id, AccountName, Balance, ReferenceCode)
VALUES
    (1, 'Alpha', 100, 10),
    (2, 'Beta', 200, 20),
    (3, 'Gamma', 300, 30);

SELECT
    name,
    is_read_committed_snapshot_on,
    snapshot_isolation_state_desc
FROM sys.databases
WHERE name = DB_NAME();

Lab 1: an exclusive lock blocks a reader

In Session A, update a row but leave the transaction open:

BEGIN TRANSACTION;

UPDATE dbo.LockDemo
SET Balance = Balance + 50
WHERE Id = 1;

-- Leave this transaction open while running Session B.

In Session B, run:

SELECT *
FROM dbo.LockDemo WITH (READCOMMITTEDLOCK)
WHERE Id = 1;

READCOMMITTEDLOCK makes the example deterministic even when READ_COMMITTED_SNAPSHOT is enabled. Session B waits with LCK_M_S because Session A holds an exclusive key lock. In a third window, run the diagnostic queries in the next section to see the waiter and blocker. Release the lock in Session A:

ROLLBACK TRANSACTION;

Session B then completes and returns the original balance of 100 because Session A rolled back. To demonstrate row versioning, remove READCOMMITTEDLOCK on a database with READ_COMMITTED_SNAPSHOT enabled; the reader can return the previously committed version without waiting.

Lab 2: create a two-row deadlock

Run the following in Session A:

SET XACT_ABORT ON;
BEGIN TRANSACTION;

UPDATE dbo.LockDemo SET Balance += 10 WHERE Id = 1;
WAITFOR DELAY '00:00:15';
UPDATE dbo.LockDemo SET Balance += 10 WHERE Id = 2;

COMMIT TRANSACTION;

Start this in Session B within 15 seconds:

SET XACT_ABORT ON;
BEGIN TRANSACTION;

UPDATE dbo.LockDemo SET Balance += 20 WHERE Id = 2;
WAITFOR DELAY '00:00:15';
UPDATE dbo.LockDemo SET Balance += 20 WHERE Id = 1;

COMMIT TRANSACTION;

Each session owns an exclusive lock needed by the other. SQL Server detects the cycle and terminates one session with error 1205; either session can be the victim. DEADLOCK_PRIORITY is considered first, followed by estimated rollback cost. The survivor commits. The primary fix is to access rows in the same order—for example, always update Id = 1 before Id = 2.

In a third window, inspect the newest graph from the built-in system_health session. This requires VIEW SERVER STATE and applies to SQL Server; Azure SQL Database exposes Extended Events through database-scoped targets.

SET QUOTED_IDENTIFIER ON;

;WITH DeadlockEvents AS
(
    SELECT CAST(st.target_data AS xml) AS target_data
    FROM sys.dm_xe_session_targets AS st
    INNER JOIN sys.dm_xe_sessions AS s
        ON s.address = st.event_session_address
    WHERE s.name = N'system_health'
      AND st.target_name = N'ring_buffer'
)
SELECT
    event_xml.value(N'(@timestamp)[1]', N'datetime2') AS event_time,
    event_xml.query(N'(data/value/deadlock)[1]') AS deadlock_graph
FROM DeadlockEvents
CROSS APPLY target_data.nodes(
    N'//RingBufferTarget/event[@name="xml_deadlock_report"]'
) AS events(event_xml)
ORDER BY event_time DESC;

Reset the data and connection setting in both windows before continuing:

IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
SET XACT_ABORT OFF;

UPDATE dbo.LockDemo
SET Balance = Id * 100;

Lab 3: a serializable range blocks an insert

In Session A, protect a range that currently contains one row:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;

SELECT *
FROM dbo.LockDemo
WHERE ReferenceCode BETWEEN 15 AND 25;

-- Leave the transaction open while running Session B.

In Session B, attempt to insert into the protected range:

INSERT dbo.LockDemo (Id, AccountName, Balance, ReferenceCode)
VALUES (4, 'Delta', 400, 18);

The insert waits on a range-insert lock. On SQL Server 2022 this appears as LCK_M_RIn_NL; older versions and tools may display related range-insert names differently. Session A holds a RangeS-S lock on the supporting index, protecting existing keys and gaps where qualifying rows could be inserted. Finish Session A:

COMMIT TRANSACTION;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

Session B can now insert the row. Remove it before repeating the lab:

DELETE dbo.LockDemo WHERE Id = 4;

These labs illustrate three different diagnoses: incompatible locks causing ordinary blocking, a circular wait causing a deadlock, and an isolation-level guarantee deliberately expanding the locked resource range.

After completing the labs, clean up:

USE LockLab;
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
DROP TABLE IF EXISTS dbo.LockDemo;

-- Optional, from a window connected to master:
-- USE master;
-- DROP DATABASE LockLab;

Quick diagnostic queries

The following server-scoped DMVs generally require VIEW SERVER STATE (VIEW SERVER PERFORMANCE STATE for some DMVs on SQL Server 2022+) or the corresponding Azure SQL database permission. wait_time is reported in milliseconds.

Find waiting requests and their blockers:

SELECT
    r.session_id,
    r.blocking_session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    DB_NAME(r.database_id) AS database_name,
    t.text AS current_sql
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.blocking_session_id <> 0
   OR r.wait_type LIKE N'LCK_M_%';

Inspect current locks:

SELECT
    l.request_session_id,
    l.resource_type,
    l.resource_description,
    OBJECT_NAME(p.object_id, l.resource_database_id) AS object_name,
    l.request_mode,
    l.request_status
FROM sys.dm_tran_locks AS l
LEFT JOIN sys.partitions AS p
    ON l.resource_type IN (N'KEY', N'PAGE', N'RID', N'HOBT')
   AND p.hobt_id = l.resource_associated_entity_id
WHERE l.resource_database_id = DB_ID()
ORDER BY l.request_session_id, l.resource_type;

The head blocker is often sleeping and therefore absent from sys.dm_exec_requests. Find its open transaction and most recent SQL:

SELECT
    s.session_id,
    s.status,
    s.login_name,
    s.host_name,
    s.program_name,
    s.open_transaction_count,
    at.transaction_begin_time,
    txt.text AS most_recent_sql
FROM sys.dm_exec_sessions AS s
LEFT JOIN sys.dm_tran_session_transactions AS st
    ON st.session_id = s.session_id
LEFT JOIN sys.dm_tran_active_transactions AS at
    ON at.transaction_id = st.transaction_id
LEFT JOIN sys.dm_exec_connections AS c
    ON c.session_id = s.session_id
OUTER APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) AS txt
WHERE s.session_id IN
(
    SELECT blocking_session_id
    FROM sys.dm_exec_requests
    WHERE blocking_session_id > 0
);

Common waits provide a fast clue:

Wait	Usually means
`LCK_M_S`	Waiting for a shared lock, often a reader behind a writer
`LCK_M_U` / `LCK_M_X`	Waiting to update or exclusively modify data
`LCK_M_SCH_M`	Waiting for a schema modification lock
`LCK_M_RS_S`	Waiting for a serializable range shared lock
`LCK_M_RIn_NL` and related `LCK_M_RI*` waits	Waiting to insert into a protected key range; the exact name varies by engine version

Use the results together. A granted lock is not automatically a problem; identify the waiter, head blocker, transaction age, and SQL. sys.dm_os_waiting_tasks provides another resource-level view. For historical deadlocks, use system_health or a dedicated Extended Events session capturing xml_deadlock_report.

Performance review checklist

Confirm waiting: Look for LCK_M_* waits rather than assuming high duration means blocking.
Find the head blocker: Follow blocking_session_id until reaching the session that is not itself blocked.
Check transaction scope: Determine whether the blocker has an old open transaction or is idle while holding locks.
Identify the resource and mode: Use wait_resource, sys.dm_tran_locks, and the execution plan.
Review access paths: Scans lock more rows and hold locks longer than selective seeks.
Check isolation requirements: Use stronger isolation only when the business invariant requires it.
Capture the deadlock graph: Do not diagnose recurring deadlocks from the victim statement alone.
Fix the cause, not the symptom: Prefer indexing, consistent access order, batching, and shorter transactions over NOLOCK or killing sessions.

Locks are necessary and waiting can be normal. Prolonged blocking usually reflects transaction scope, access paths, or concurrency design. Diagnose the wait chain, then reduce the locked resource set or the time locks are held.

Microsoft.Testing.Platform: How .NET Testing Evolved

Gunjit Chhatwal — Mon, 09 Nov 2026 20:35:04 +0000

For most .NET developers, running tests has long appeared simple: add MSTest, NUnit, or xUnit.net, write a few test methods, and run dotnet test. Under that command, however, sits a test platform responsible for discovering tests, loading adapters, starting processes, collecting results, and integrating with editors and CI systems.

That distinction matters:

A test framework defines how tests are written. Examples include MSTest, NUnit, xUnit.net, and TUnit.
A test platform discovers and executes those tests and connects them to command-line tools, IDEs, and build pipelines.

For many years, VSTest was the standard platform behind .NET testing. Microsoft.Testing.Platform (MTP) is its modern, lightweight alternative. It does not replace test frameworks; instead, it changes how their tests are hosted and executed.

How .NET testing reached this point

The earliest .NET test runners were closely associated with their frameworks or development environments. Tests often ran through a framework-specific console runner or directly inside Visual Studio. This worked well when applications primarily targeted the .NET Framework and ran on Windows.

VSTest brought valuable consistency. It gave Visual Studio, command-line tools, CI systems, and third-party frameworks a common execution platform. Test adapters allowed MSTest, NUnit, xUnit.net, and other frameworks to participate in the same workflow.

The arrival of .NET Core in 2016 changed the environment. .NET became cross-platform, side-by-side versioned, container-friendly, and increasingly optimized for deployment models such as trimming and Native AOT. Test projects could now target many runtimes and architectures, while runners had to handle more combinations of SDKs, hosts, adapters, extensions, and process boundaries.

VSTest continued to evolve, but its architecture came from a period when an external runner loading test adapters was the natural model. Supporting modern .NET form factors within that model added complexity. The result could be subtle differences between local, IDE, and CI execution, along with difficult assembly-loading or extension-discovery problems.

Microsoft introduced MTP through the MSTest Runner work and expanded it into a platform supported by the major .NET test frameworks. In .NET 10, dotnet test gained native MTP-aware orchestration, making the new platform feel increasingly like a first-class part of the SDK rather than a separate experiment.

The architectural shift: the test project becomes an application

The most important MTP idea is surprisingly simple: a test project is built as an executable test application.

With the traditional VSTest model, an external runner discovers an adapter, loads the test assembly, and coordinates execution. With MTP, the platform and framework runner are embedded into the test project. The resulting application can participate in dotnet test, but it can also be started with dotnet run or executed directly.

This design reduces the number of hidden decisions made at run time. Frameworks and extensions are normally registered at build time, so the application knows what it contains before execution begins. The same test artifact can run locally or in CI without depending on a separately installed console runner.

What improves with Microsoft.Testing.Platform?

1. More deterministic execution

MTP emphasizes compile-time registration instead of discovering arbitrary plugins through reflection at run time. This makes configuration errors visible earlier and reduces environment-dependent behavior. The test application carries its intended runner and extensions with it, improving the chance that the same build behaves consistently on a developer machine and a build agent.

2. A smaller and more transparent runtime

The MTP core is a single assembly with no dependencies beyond supported .NET runtimes. It avoids creating isolation mechanisms such as AppDomain or AssemblyLoadContext simply to coordinate a run, and it does not rely on custom assembly resolution for its core operation. That reduces interference between the platform and the framework executing the tests.

3. Executable-first workflows

Because an MTP test project behaves like a normal .NET application, it works naturally with familiar application workflows:

dotnet test
dotnet run --project tests/MyApp.Tests
./tests/MyApp.Tests/bin/Release/net8.0/MyApp.Tests

This is useful for containers, specialized devices, browser-like hosts, startup-project debugging, and environments where installing or locating an external runner is undesirable.

4. Better alignment with modern .NET

MTP was designed for current and future .NET form factors, including trimming and Native AOT scenarios. Its hostable architecture also allows the test runtime to run inside different application types rather than assuming every test must be controlled by a conventional console host.

5. Modular capabilities instead of a large default surface

The platform focuses on orchestration and adds capabilities through extensions. Available extensions cover TRX, HTML, JUnit, CTRF and CI-native reporting, code coverage, crash and hang dumps, retries, Hot Reload, OpenTelemetry, Microsoft Fakes, and more.

When standard MSBuild integration is enabled, installing an extension package is generally enough for it to be detected and registered. Teams can therefore include only the capabilities they need instead of paying for every feature in every test process.

6. Framework choice remains open

MTP is not limited to MSTest. MSTest, NUnit, xUnit.net, and TUnit all support it, while TUnit is built directly on top of MTP. This lets teams modernize test execution without necessarily rewriting their test suites or abandoning their preferred assertion and test-authoring model.

A practical before-and-after example

Consider a small pricing service. The production code applies a percentage discount:

public static class PriceCalculator
{
    public static decimal ApplyDiscount(decimal price, decimal percentage)
    {
        if (percentage is < 0 or > 100)
        {
            throw new ArgumentOutOfRangeException(nameof(percentage));
        }

        return price * (1 - percentage / 100);
    }
}

Its MSTest test is intentionally ordinary:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public sealed class PriceCalculatorTests
{
    [TestMethod]
    public void ApplyDiscount_ReducesPrice()
    {
        decimal result = PriceCalculator.ApplyDiscount(200m, 15m);

        Assert.AreEqual(170m, result);
    }
}

The test itself does not need to change when moving from VSTest to MTP. The difference is in how the test project is assembled and executed.

Before: a conventional VSTest project

A representative VSTest-based project explicitly combines the .NET SDK, the test platform package, the framework, and its adapter:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <IsTestProject>true</IsTestProject>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.11.0" />
    <PackageReference Include="MSTest.TestAdapter" Version="4.1.0" />
    <PackageReference Include="MSTest.TestFramework" Version="4.1.0" />
  </ItemGroup>
</Project>

The typical CI command asks VSTest to load a logger and a data collector:

dotnet test --configuration Release \
  --logger trx \
  --collect "Code Coverage;Format=cobertura"

This is a mature and widely supported workflow. However, the test artifact is primarily a library intended to be understood and launched by an external test platform. The runner must locate the adapter, interpret VSTest options, start a test host, and coordinate collection and reporting.

After: the same suite as an MTP application

MSTest.Sdk bundles the recommended MSTest setup and uses MTP by default:

<Project Sdk="MSTest.Sdk/4.1.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>
</Project>

For native MTP orchestration in .NET 10 or later, the repository selects the runner in global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

The equivalent CI command becomes:

dotnet test --configuration Release \
  --report-trx \
  --coverage \
  --coverage-output-format cobertura

The options now describe capabilities owned by the test application: TRX reporting and code coverage. With the default MSTest.Sdk profile, the required Microsoft extensions are already included. If a team uses a minimal profile, it can add only the extension packages it wants.

More importantly, the compiled test application is not limited to dotnet test:

# Familiar solution or project orchestration
dotnet test --project tests/Pricing.Tests/Pricing.Tests.csproj

# Launch it like another .NET application
dotnet run --project tests/Pricing.Tests/Pricing.Tests.csproj

# Build once, then run the produced test executable
dotnet build tests/Pricing.Tests -c Release
./tests/Pricing.Tests/bin/Release/net10.0/Pricing.Tests

On Windows, the final command uses Pricing.Tests.exe.

What improved in this example?

First, the project configuration has fewer independently managed test packages. The SDK supplies a coherent runner, framework, and default extension profile. Second, the test output is self-describing: the runner and registered extensions travel with the build instead of being discovered from a machine-specific adapter setup. Third, local debugging and CI execution are closer because both launch the same test application. Finally, stricter defaults expose mistakes sooner—for example, MTP returns a non-success exit code when a test application executes zero tests, while VSTest normally treats that situation as successful.

The improvement is primarily architectural and operational. A single Assert.AreEqual is not inherently faster because it runs on MTP. The gains appear around startup composition, predictable extension loading, artifact portability, parallel module orchestration, diagnostics, and reduced differences between execution environments. Actual performance still depends on the number of projects, framework behavior, test setup, I/O, and enabled extensions, so teams should benchmark their own suites rather than rely on a universal speed claim.

Retrying individual tests in a test pipeline

Consider a long-running test pipeline that exercises a deployed service, including authentication, data import, background processing, and persistence. Such pipelines are expensive to repeat because each test can involve network calls, external resources, and significant setup.

Before the migration, a task-level retry was used when a test failed. If one test failed near the end of the run, the pipeline repeated the entire task—including tests that had already passed:

After moving the test project to MTP, the suite can add the retry extension:

<PackageReference Include="Microsoft.Testing.Extensions.Retry" />

The pipeline could then request up to two retries for failed tests:

dotnet test \
  --retry-failed-tests 2 \
  --retry-failed-tests-max-percentage 10

The percentage limit prevents a broadly broken suite from repeatedly retrying a large number of failures. Smaller suites can choose a different policy because one failed test might already exceed a 10% threshold.

This changes the retry boundary from the pipeline task to the individual test. A transient failure no longer requires every successful test to run again, reducing wasted agent time and repeated calls to deployed resources. A pipeline can also merge the per-attempt TRX files into a final report, retaining the final outcome while identifying tests that failed initially and passed only on retry.

Per-test retries should not be used to normalize flaky tests. A test that passes on retry is still a reliability signal that should be visible and investigated. The value of the MTP extension is that retry behavior becomes an explicit, configurable part of the test application instead of a coarse pipeline-level rerun.

This improvement is specifically attributable to adopting the MTP retry extension. By contrast, building test projects once and reusing their artifacts was already possible with VSTest; MTP makes those artifacts directly executable and more self-describing, but it did not introduce the concept of prebuilt tests.

MTP compared with the common alternatives

Area	VSTest	Microsoft.Testing.Platform	Framework-specific/custom runner
Architecture	External platform plus adapters	Platform embedded in an executable test app	Varies by framework or vendor
Ecosystem maturity	Long-established and broadly integrated	Rapidly growing, with major .NET frameworks supported	Often strong within a narrower ecosystem
Runtime behavior	Compatibility-oriented and dynamic	Explicit, modular, and build-time registered	Depends on implementation
Modern deployment	Limited for Native AOT and trimming scenarios	Designed for modern .NET form factors	Varies
Mixed-language testing	Supports .NET and non-.NET adapter scenarios	Focused on .NET	Usually specialized
Direct execution	Normally driven by VSTest tooling	`dotnet run` or direct executable supported	Often supported by dedicated commands
CI migration cost	Usually lowest for existing pipelines	Requires checking arguments, reports, and extensions	May require vendor-specific integration

Tools such as ReSharper, Rider, NCrunch, and IDE test explorers should not always be viewed as competing platforms. They are developer experiences that may integrate with one or more underlying test technologies. The practical question is not only “Which button runs my tests?” but also “Which execution model produces and controls the test process?”

Should every project migrate now?

Not automatically. VSTest remains a sound choice when a repository depends on mature integrations, custom VSTest adapters, existing .runsettings behavior, or mixed-language test execution such as C++ and JavaScript alongside .NET. Some third-party tooling still has deeper VSTest integration.

MTP is especially compelling for new .NET test projects, teams targeting Native AOT or trimming, containerized test artifacts, or repositories experiencing VSTest-specific loading and extension problems. It is also attractive when reproducibility and explicit composition are more important than maximum backward compatibility.

Migration should be deliberate. Choose one platform consistently for a solution or run configuration, verify framework support, map command-line arguments, and replace VSTest loggers or collectors with the corresponding MTP extensions. Do not assume every VSTest switch has an identical MTP equivalent.

The larger improvement

Microsoft.Testing.Platform is not merely a faster command or a new adapter. Its real contribution is making test execution look like the rest of modern .NET development: build an application with known dependencies, run the same artifact in different environments, and add capabilities through explicit packages.

VSTest solved the earlier problem of unifying a fragmented testing ecosystem. MTP addresses the next problem: keeping that ecosystem predictable, portable, and extensible as .NET itself moves into more runtimes, deployment models, and development environments.

For most teams, that means evolution rather than revolution. Existing test frameworks remain useful, dotnet test remains familiar, and migration can happen project by project. What changes is the foundation underneath—and that foundation is now much closer to the application model .NET developers already understand.