Build error when one test project references another, redux

[vikukush]

Describe the bug

I have the same exact issue as in #3813, it is not solved for me by the PR, because my test assemblies use InternalsVisibleTo, so they can see autogenerated Internal classes, so they still get the conflict:

D:\dbs\sh\l23t\1010_175302_0\cmd\7\Test\UnitTests\BIAndReporting\Reports.Shared\obj\Debug\net48\TestPlatformEntryPoint.cs(13,9): warning CS0436: The type 'SelfRegisteredExtensions' in 'D:\dbs\sh\l23t\1010_175302_0\cmd\7\Test\UnitTests\BIAndReporting\Reports.Shared\obj\Debug\net48\AutoRegisteredExtensions.cs' conflicts with the imported type 'SelfRegisteredExtensions' in 'MS.Dynamics.Test.BIAndReporting.Common.UnitTests, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Using the type defined in 'D:\dbs\sh\l23t\1010_175302_0\cmd\7\Test\UnitTests\BIAndReporting\Reports.Shared\obj\Debug\net48\AutoRegisteredExtensions.cs'. [D:\dbs\sh\l23t\1010_175302_0\cmd\7\Test\UnitTests\BIAndReporting\Reports.Shared\Shared.UnitTests.csproj::TargetFramework=net48]

Steps To Reproduce

[assembly: InternalsVisibleTo("MS.Dynamics.Test.BIAndReporting.RunTime.UnitTests, PublicKey=blah")]

[MartyIX]

I think we are affected by this as well.

[MartyIX]

@Youssef1313 Is this issue hard to fix?

I think that quite a lot people can be affected by this once migrating from xUnit 2 to xUnit 3. If I understand the issue right, that is.

[Youssef1313]

@MartyIX In general, it's not really a good idea to have an executable referenced by another executable. Why would you need that in the first place?

We can investigate if we can make it work though.

[Evangelink]

Let's do a quick test by adding namespace isolation (I don't think we have one ATM)

[MartyIX]

@MartyIX In general, it's not really a good idea to have an executable referenced by another executable. Why would you need that in the first place?

So the answer is that: xUnit 2 was based on library projects and I think it is fairly common that people make their test projects depend on another test projects because there was no issue with that up to now. But now xUnit 3 was released and people need to change their test projects to executable ones... and then they hit this issue.

This does not of course justify "incorrect architecture" but for at least medium size C# projects, it's really a lot of work to "change architecture to add test helper projects which are libraries and not executables". So if migration to xUnit 3 or any other modern test framework is the goal, then this issue is a bit blocker¹.

I don't mind any gentle nudge "please don't this" from an analyzer which can be silenced to gradually fix the problem.

Footnotes

1. It can involve many days worth of work to fix that one issue and it's much more feasible to do it gradually. ↩