Build error when one test project references another

[bdukes]

Describe the bug

Starting with MSTest 3.6.0, when one test project references another test project, warning CS0436 is emitted by the compiler because the same type is being compiled into two assemblies.

Steps To Reproduce

1. Pull build-error-on-reference branch from bdukes/mstest-demo
2. dotnet build

Expected behavior

The build command is successful.

Actual behavior

The build command fails with the following error:

I:\code\MSTestDemo\ProjectTwo.Tests\obj\Debug\net8.0\TestPlatformEntryPoint.cs(13,9): warning CS0436: The type 'SelfRegi
steredExtensions' in 'I:\code\MSTestDemo\ProjectTwo.Tests\obj\Debug\net8.0\AutoRegisteredExtensions.cs' conflicts with t
he imported type 'SelfRegisteredExtensions' in 'ProjectOne.Tests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
. Using the type defined in 'I:\code\MSTestDemo\ProjectTwo.Tests\obj\Debug\net8.0\AutoRegisteredExtensions.cs'. [I:\code
\MSTestDemo\ProjectTwo.Tests\ProjectTwo.Tests.csproj]

[Evangelink]

Hi @bdukes

Are you expecting to run tests from ProjectOne.Tests or is this a test helper project?

[bdukes]

I'm expecting to run tests from both ProjectOne.Tests and ProjectTwo.Tests.

[Evangelink]

I can reproduce the issue, I need a few more tests and investigation to suggest the proper fix.

[jbcutting]

I'm also seeing this issue. In my case, we have various test helper projects referenced by our test projects. We do also have a few test projects referencing each other, but it's primarily an issue with test helpers.

[Evangelink]

but it's primarily an issue with test helpers.

@jbcutting we do recommend to have test helper libraries as libraries and not executable.

[jbcutting]

but it's primarily an issue with test helpers.

@jbcutting we do recommend to have test helper libraries as libraries and not executable.

They are libraries. We're not using executables for any of our test projects currently. We're still on MSTest 3.0.4 currently because I've run into something each time I've tried to update. I was hoping 3.6 would be my upgrade point, but I'm now waiting for 3.7 due to this.

Is there a way to avoid this with test helpers if I override a setting in 3.6? If I avoid exe test outputs altogether, would it bypass this issue?

[Evangelink]

Fix will be ported to 3.6.1.

For your case, you don't even need the fix. In 3.6+ detecting if the project is library or application (through the OutputType).

If you are using MSTest.Sdk, by default we set <OutputType>Exe</OutputType> but for the test helpers, manually setting <OutputType>Library</OutputType> will solve the issue (you will see that among others MSTest.TestAdapter is not added).

If you are not using MSTest.Sdk, the default of .NET is <OutputType>Library</OutputType> and we ask to set it to <OutputType>Exe</OutputType> and add <EnableMSTestRunner>true</EnableMSTestRunner> on test applications but for helpers the default configuration is good.

I hope this helps.

[MarcoK80]

This issue is not resolved if you have two projects and internalsvisible used to reuse an internal class.
Example:
UnitTest Project A has a FakeImplementation class that you want to reuse. InternalsVisibleTo is set for Project B
UnitTest Project B wants to use the Fakeimplementation class of Project A.

[bdukes]

Upgrading to 3.6.1 resolved my issue, thanks @Evangelink!

[Evangelink]

This issue is not resolved if you have two projects and internalsvisible used to reuse an internal class.

I'll run a few more tests. @MarcoK80 I'd like to discuss a little more about your scenario. I am still not fully sold on the idea of having an exe referencing an exe.

[3s-ap]

This issue is not resolved if you have two projects and internalsvisible used to reuse an internal class.

I'll run a few more tests. @MarcoK80 I'd like to discuss a little more about your scenario. I am still not fully sold on the idea of having an exe referencing an exe.

@Evangelink I think it should not necessarily be two executables. I have two libraries where one has "internalsvisible" to the other and the issue is reproducible.

Update
I managed to fix it by adding this <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint> to projects that do not have any tests. But it perhaps not fixes the root cause and will not work for multiple test assemblies referencing each other with "internalsvisible" (not tested)