ITestRunner.Run() does not pass Activity.Current to underlying test

[DanielVuurboom]

We're calling specific tests programmatically through ITestRunner.Run(). In older versions of NUnit.Engine, the Activity.Current that was started before the Run() call was available in the test, and we use this to pass some data (a TraceId, to be specific).
In the current version, Activity.Current is set to null inside the test, which breaks our implementations.

Please see the attached zip file for a small C# project demonstrating the current, unexpected, behavior:
ActivityDebugging.zip

Replacing the packages with these older versions shows the Activity.Current set as expected:

    <PackageReference Include="NUnit.Engine" Version="3.15.2" />
    <PackageReference Include="NUnit.Engine.Api" Version="3.15.2" />
    <PackageReference Include="NUnit" Version="3.13.3" />

[CharliePoole]

What happens if you use the 3.19 engine and api but vary the version of NUnit?

[DanielVuurboom]

    <PackageReference Include="NUnit.Engine" Version="3.19.0" />
    <PackageReference Include="NUnit.Engine.Api" Version="3.19.0" />
    <PackageReference Include="NUnit" Version="3.13.3" />

results in a null Activity.Current, just like

    <PackageReference Include="NUnit.Engine" Version="3.19.0" />
    <PackageReference Include="NUnit.Engine.Api" Version="3.19.0" />
    <PackageReference Include="NUnit" Version="4.3.2" />

[veleek]

Just recording a few notes:

Change BOTH NUnit.Engine package versions to 3.18.3 (the release prior to 3.19.0) causes it to work properly.

   <PackageReference Include="NUnit.Engine" Version="3.18.3" />
   <PackageReference Include="NUnit.Engine.Api" Version="3.18.3" />

Changing EITHER package to 3.19.0 causes it to break.

[veleek]

There are not that many changes between 3.18.3...3.19.0 and there's nothing that sticks out obviously. This is removing support for a few things and changing the version of cake.tool from 4.0 to 5.0 so maybe there's a subtle difference in the versions that are loaded? Next step is to build a local copy of this with some additional logging because nothing stands out yet.

[CharliePoole]

@veleek Have you tried a git bisect to narrow it down?

[veleek]

Nope but that was my next plan. I’m a _little_ worried that it has something to do with the SDK that it was built with so I wanted to verify everything with released binaries first.

…

On Sun, Mar 2, 2025 at 05:43 CharliePoole ***@***.***> wrote: @veleek <https://github.com/veleek> Have you tried a git bisect to narrow it down? — Reply to this email directly, view it on GitHub <#1591 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIBSLJ7HOPAT6T4SX7RD7L2SMDI3AVCNFSM6AAAAABUR2O2YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJSG42DAMJZGY> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: CharliePoole]*CharliePoole* left a comment (nunit/nunit-console#1591) <#1591 (comment)> @veleek <https://github.com/veleek> Have you tried a git bisect to narrow it down? — Reply to this email directly, view it on GitHub <#1591 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIBSLJ7HOPAT6T4SX7RD7L2SMDI3AVCNFSM6AAAAABUR2O2YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJSG42DAMJZGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[veleek]

After FAR too much work into this I've determined that there's a difference between netcoreapp2.1 (and earlier, like netstandard2.0) and net6.0 and greater.

There were a lot of project/framework/versioning changes around when I was working so I basically needed to nuke and rebuild everything each step and update Assembly Reference paths because a bunch of assembly build path changes happened around the same time period I was investigating.

[veleek]

I've validated this as far back as 3.17.0 which produced both a netcoreapp3.1 binary (which fails) AND netcoreapp2.1 binary (which succeeds).