Our public ConcurrentQueue causes type conflicts

[jnm2]

If you try to use NUnit on net35 with another library such as AsyncBridge which ships a ConcurrentQueue polyfill, the project won't compile because of the type collision between the two dependencies.

This began in 3.10. We should make sure all our polyfill classes are internal since they are sharing the System namespace.

The same problems occur with NUnit.System.Linq, and System.Action etc, but I'm not sure we can do anything about that because it has shipped with NUnit for so long. If we kept it in the nupkg copying to the test project output folder but kept the test project from referencing it, it would solve the problem but it might also break people who have come to rely on NUnit.System.Linq always coming with NUnit.

[rprouse]

Curious how you ran into this? I am fine to make it internal, but is it actually critical? Easy fix, so maybe a moot question 😄

[jnm2]

I tried to use AsyncBridge and NUnit in the same test project which targets net35. I got a workaround by doing this in the csproj:

  <Target Name="SetNUnitAlias" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
    <ItemGroup>
      <ReferencePath Condition="'%(FileName)' == 'NUnit.Framework' or '%(FileName)' == 'NUnit.System.Linq'">
        <Aliases>NUnit</Aliases>
      </ReferencePath>
    </ItemGroup>
  </Target>

And this at the top of every file that uses NUnit types:

extern alias NUnit;
using NUnit::NUnit.Framework;
using NUnit::NUnit.Framework.Constraints;

But it's not a nice thing to have to do. :D

[jnm2]

Maybe it should be pri:high or pri:normal? I'm always happy to change it. I guessed pri:critical because most people wouldn't be able to figure out the workaround, and they are effectively prevented from compiling their test project if they combine NUnit with any other library with a public System.Collections.Concurrent.ConcurrentQueue (including one defined in their own project). Maybe the rareness should demote it?

[CharliePoole]

Don't know if you have changed the definition but critical in the past meant stop everything, fix this and do an emergency release.

[jnm2]

I was extrapolating; I didn't know that. I doubt this needs an emergency release.

[CharliePoole]

I was just providing the history. I have no info as to whether that's what it means today.

[OmicronPersei]

I'm happy to work on this, just curious if there's any consensus on what the path forward should be? Making it internal seems simple enough.

[ChrisMaddock]

@OmicronPersei - I think making it internal is the way to go. 😄

[jnm2]

There are three such issues total:

• System.Collections.Concurrent.ConcurrentQueue
• System.Collections.Concurrent.IProducerConsumerCollection
• System.Threading.SpinWait

@rprouse, are you okay with @OmicronPersei making all of these internal? And would a test be interesting to assert that assembly.GetExportedTypes() are all non-System types?