Error building test project in VS2022

[elTRexx]

Hello.
I tried to get into unit testing via this new promising framework.
I am using Visual Studio 2022 17.14.29
I used the template project first. It WAS working on default written tests furnished with the templated newly created project.
I could see them in the VS embedded test explorer window
Then I tried to write my first test using the TUnit Mock library. I got a warning about test generator couldn't work without System.Memory 4.0.2.0. So I added the System.Memory Nuget package.

But since All my build(clean project - rebuild) fail on MSB6006 error "csc.exe" stopped with code 1, along with 4 CSC CS8032 warning :

• An instance of analyzer TUnit.Analyzers.ClassHooksAnalyzer cannot be created from
  C:\Users\XXXX\.nuget\packages\tunit.core\1.21.24\analyzers\dotnet\roslyn4.14\cs\TUnit.Analyzers.dll : Exception has been thrown by the target of an invocation..
• An instance of analyzer TUnit.Analyzers.GlobalTestHooksAnalyzer cannot be created from
  C:\Users\XXXX\.nuget\packages\tunit.core\1.21.24\analyzers\dotnet\roslyn4.14\cs\TUnit.Analyzers.dll : Exception has been thrown by the target of an invocation..
• An instance of analyzer TUnit.Analyzers.TestDataAnalyzer cannot be created from
  C:\Users\XXXX\.nuget\packages\tunit.core\1.21.24\analyzers\dotnet\roslyn4.14\cs\TUnit.Analyzers.dll : Exception has been thrown by the target of an invocation..
• An instance of analyzer TUnit.Analyzers.AssemblyTestHooksAnalyzer cannot be created from
  C:\Users\XXXX\.nuget\packages\tunit.core\1.21.24\analyzers\dotnet\roslyn4.14\cs\TUnit.Analyzers.dll : Exception has been thrown by the target of an invocation..

I even tried to removed all my nugets package, delete .vs, bin and obj folders. Create a new console project to turn it in a Tunit one manually instead. Even cerating a brand new solution with a console project, turned into a TUnit project manually, with a simple public class with a simple async test method but now all my builind fails.
Though running the testing project in CLI work fine ...
It is the MS build that fail inside VS 2022. I'm using .Net 9 as .net 10 isn't available in VS 2022. Using C# 13 or lastversion set into csproj too.

I think something is wrongly setted somewhere since it originally worked at first.

[thomhurst]

Hi, thanks for reporting this!

The issue is almost certainly caused by the System.Memory NuGet package you added manually. TUnit's analyzers run inside the Visual Studio Roslyn compiler process, and adding System.Memory as a direct package reference can cause assembly version conflicts in that host process — which is why you see the TargetInvocationException when VS tries to instantiate the analyzers. The CLI works fine because it uses a different host process with different assembly resolution.

To fix this:

1. Remove the System.Memory NuGet package from your project
2. Delete your bin, obj, and .vs folders
3. Rebuild

The warning you saw about System.Memory 4.0.2.0 was likely a red herring — TUnit's transitive dependencies already handle this correctly, so you shouldn't need to add it manually.

If you're still seeing issues after removing it, could you share your .csproj file contents? That would help us pinpoint anything else that might be off.

[elTRexx]

I will keep investigate around this. but yeah the issue is linked to System.Memory package. I rebuild the project with diagnostic level output and saw that :
CompilerServer: server failed - server rejected the request 'Exception during compilation: Impossible to load the file or assembly 'System.Memory, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependancies. The specified file cannot be found.' - TTT (net9.0)
But here I am on my new solution - 1 test simplest project only. So no System.Memory was added here. I suspect some cache conflict maybe ?
I'm still intriged about why a reference to an old 4.0.2.0 version is expected. I can't even list that version in Nuget (oldest available is 4.5.0)

[elTRexx]

I did full uninstall of VS 2022, along with all my previous .Net SDK / runtimes
I Installed Rider and embedded test explorer works in rider.
Then I installed a fresh VS 2022 (only removed copilot).
And the issue is still here. I don't know where is the wrong System.Memory.dll on my PC that TUnit try to load.

[elTRexx]

I Renamed all my System.Memory.dll, so now when attempting to build the test project I have an error pointing to the one it is looking for : C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.14\ref\net9.0.
After properly renamed it back, I get back to the original issue. So maybe I should hadoc change this .dll ?

[elTRexx]

I removed all cached nuget packages, removed .vs, bin and obj folders. Removed all temporary files (using bleachbit software) to be sure. Restarted PC, but still same issue.
As you requested my csproj :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <LangVersion>13</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="TUnit" Version="1.21.24" />
  </ItemGroup>

</Project>

[elTRexx]

All these binding redirect issues are .NET framework problems which you won't get in .NET 10

@elTRexx If this is a new project, can you not use .NET 10?

The .Net Framewok was purely for testing in any case it would change something (and indeed it exposed me the older System.Memory 4.0.1.2 which conflicted with 4.0.2.0). But yeah my original project was under .Net 8 and/or .Net 9. Unfortunatelly .Net 10 isn't available in VS 2022. And for now I despite VS 2026 because of AI being forced in this version.
I'll look if their is any tweak/workaround to make .Net 10 working unofficially in VS 2022 though.
Is there a difference between .Net 9 and .Net 10 regarding this version conflict ?

For now my suppositions are that somehow VS (MSBuild I think) lost the reference to System.Memory 4.0.2.0, that can be re-established manually by adding the corresponding Nuget package 4.6.0 (+?). But as you originally stated, it work only for "main" test project, not for the source generated (?) analyzer, that seems to fallback to default assemblies references of VS (MSBuild ?) that lack of System.Memory 4.0.2.0.

I'll try to look into your code of how your analyzer are created since there is an Exception I want to understand :
TUnit.Analyzers.dll : Exception has been thrown by the target of an invocation..

[elTRexx]

For future reference, digging into your code, I saw that issue seems to raise up from those 4 specifics analyzers (ClassHooksAnalyzer, GlobalTestHooksAnalyzer, TestDataAnalyzer and AssemblyTestHooksAnalyzer) because, contrary to the other analyzers, they initialize their SupportedDiagnostics property with an ImmutableArray.Create() with more than 4 parameters, that will fallback to calling the params overload of this method (that I suppose will in turn convert theses parameters to a ReadOnlySpan, hence the System.Memory dependency, before calling the corresponding overload too).

[thomhurst]

Ah interesting! Strange as the analysers are net standard so should still work with framework 🤔

[elTRexx]

For the update, I'm still lost in this rabbit hole for now.
I did try to fully uninstall Visual Studio, this time more aggressively, using the InstallCleanup.exe -f utility, removing all possible related .Net application (A bunch of SDKs) from add/remove application in system, doing a full search on every named files / folders containing visual and nuget to hard delete them from C: disk. Run a BleachBit cleanup. did a fresh VS 2022 community install again, created a new console app project, manually deleting Program.cs, adding a new MyTest.cs class with the same simple testing code than earlier adding the last TUnit Nuget package, and still exactly the same compile error.

Somehow Roslyn analyzer fail to load System.Memory.dll version 4.0.2.0, and don't understand why since I hard remove everything, so should not be some leftover older version on my PC !?,
The System.Memory grabbed by MSBuild is the .Net 9.0 that come with VS 2022 install (version 9.0.0.0).
I look into all downloaded .dll in the C:\Users\XXXX\.nuget\packages folder, and indeed all the one that target .NetStandard2.0 and that require System.Memory look for 4.0.2.0 version.
Since, to my understanding, all Roslyn Analyzer are targetting .NetStandard2.0 this is why the issue come from the TUnit analyzers especially.
I don't know how Roslyn analyzer try to resolve this dependency internally. All I got from output log is for MSBuild Test Project building, not the Roslyn one.
If I add manually the System.Memory 4.6.x Nuget Package then MSBuild look for this System.Memory instead.
But it doesn't change the fact Roslyn analyzer on its own compilation process (the CSC.exe I suppose ?) still miss System.Memory version 4.0.2.0.

I saw that you opened and closed an issue 4 days ago revolving around System.Memory.

Looked into that I saw you explicitly forced using System.Memory 4.6.3 when targetting .NetFramework.
So I did try to target again .NetFramework 4.6.2+ for my simple test project hoping it will solve it somehow but no.

[elTRexx]

I still don't understand. I have created my own simple roslyn (4.14?) analyzer to better know how that work.
I have 2 analyzer, one with a single rule, the other with 5 rules to force using the ImmutableArray.Create(params ...) behind the hood that I suspect will cause calling System.Memory, in version 4.0.2.0 I suppose since my analyzer is targetting .NetStandard2.0

=> Edit : NO ! Looking into my dll inside the nuget depackaged
C:\User\XXXX\.nuget\packages\name\1.0.0\analyzers\dotnet\cs\name.dll with DotPeek, it show my analyzer require System.Memory version 4.0.1.2 even though it target .NetStandard2.0 !! Why ?

But after creating a nuget package of this simple analyzer, and using it afterward in a simple ConsoleApp, it work without any CSC error.

[elTRexx]

I'm still stuck on this. Understanding a little bit more on how Analyzer works, but still missing knowledge on how (what environment) they compile trying to understand this CSC error ....

But I did find out something, should have tested that before : Trying to go back in TUnit package version, and yeah it work for older ones !
Trying and testing to sort this out I found that TUnit 1.19.22 is the last version that work and starting with TUnit 1.19.57 it fail with the same errors i got originally.

Does it talk to you ? Do you remember what change may cause this discrepancy between version 1.19.22 and 1.19.57 ?

[elTRexx]

@thomhurst Hi again.
I patiently tested via trial and error to check what was the culprit differences, turns out either

• Removing

<GlobalPackageReference Include="GitVersion.MsBuild" Version="6.6.0">
     <PrivateAssets>all</PrivateAssets>
     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
   </GlobalPackageReference>

from Directory.Packages.props or

• Setting the .git/refs/heads/main content back to 1.19.22 commit ID (393e26c7eecaefa4bf0800fb1ea3049d7207b0dd)

make 1.19.57 and further version to work again.
But it doesn't seems to matter as latest TUnit version work again (see my other response).

[elTRexx]

@thomhurst
As I was testing what may cause the CSC error, by compiling my own TUnit version from yours at different commit history, I was surpised that trying with latest version (was 1.39.0 at that time) result in no error anymore !

So I again look for when it seems to have been resolved and fould out that 1.35.0 was the last not working version and since 1.35.2 it work again ! I'll check what have change between this 2 versions.

[thomhurst]

Must've been SourceLink breaking it for you then?

[thomhurst]

I removed the explicit GitHub SourceLink package, because it's included in the .NET SDK by default now, and it fixed "deterministic" builds

[elTRexx]

It is what I saw from your commit diffs.

That surprised me a little as what prevented the error was by removing

<GlobalPackageReference Include="GitVersion.MsBuild" Version="6.6.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </GlobalPackageReference>

not

<GlobalPackageReference Include="Microsoft.SourceLink.GitHub" Version="10.0.103" />

from Directory.Packages.props.

So I was expecting the diffs from TUnit 1.35.0 to 1.35.2 would revolve around GitVersion.MsBuild not Microsoft.SourceLink.GitHub.

So now looking to see when GitVersion.MsBuild was removed, I found out it was in this commit, actually more moving from a GlobalPackageReference to a PackageVersion one in TUnit 1.28.0. A version that still produce the CSC error.

I will test again to check if removing SourceLink package, at least as a GlobalPackageReference, might resolve also the issue like removing GitVersion.MsBuild did from TUnit 1.19.22 to 1.19.57.

[elTRexx]

So I tested different combination between Microsoft.SourceLink.GitHub (referred as SourceLink) and GitVersion.MsBuild (referred as GitVersion) and found out that, on TUnit 1.19.57 Directory.Packages.props file :

SourceLink	GitVersion	Build result
∅	∅	✔
∅	PackageVersion	✔
∅	GlobalPackageReference	❌
PackageVersion	∅	✔
PackageVersion	PackageVersion	✔
PackageVersion	GlobalPackageReference	❌
GlobalPackageReference	∅	✔
GlobalPackageReference	PackageVersion	✔
GlobalPackageReference	GlobalPackageReference	❌

So yeah, it seems the culprit is GitVersion as a GlobalPackageReference, still doesn't explain why TUnit 1.28.0 -> 1.35.0 keep failing then as they are version without GitVersion as a GlobalPackageReference, and we have to wait until TUnit 1.35.2 with SourceLink set as a PackageVersion, unrelated to GitVersion (or does it ?)