System.ArgumentException: An item with the same key has already been added.

I'm seeing the following error when trying to run the tests for a solution:

```
NCrunch encountered an error while trying to construct an environment to execute this test: System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at nCrunch.Core.InlineModules.AspNetMvcTestHostModule..(SnapshotComponent , IList`1 , ProcessLoadParameters )
at nCrunch.Core.TestManagement.TestRunnerProcess.(Nullable`1 , FilePath , GridClientId , CustomVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.LoadTestRunnerProcessForProjectReturningProcessId(SnapshotComponent snapshotComponent, IList`1 componentsInProcess, TestFrameworkDescription[] testingFrameworks, Nullable`1 newProcessTag, FilePath solutionFilePath, GridClientId client, CustomVariable[] customEnvironmentVariables)
at nCrunch.Core.Processing.TestExecutionTaskLogic.DoProcessTaskAndReturnSuccessFlag()
```

NCrunch 3.22.0.1
Visual Studio 2017

Hi, thanks for sharing this issue.

This appears to be caused by two projects in your environment having the same assembly name. Does this appear to be the case with your solution?

Thanks for the quick reply, it appears that all the assemblies have unique names. I checked the AssemblyName element in the csproj.

```
grep AssemblyName . -R --include=*.csproj
```

EDIT: This is only occurring on a few projects.

Are any of your assemblies multi-targeted at all? Note that later versions of project files actually have an implicit AssemblyName (it doesn't need to be specified in the file), but I expect that if you had two files under the same name, you'd probably know about it. It's possible there's something more complicated happening here. Is there any chance you could submit a bug report?

Actually, kind of. The testing assembly having the issue is a .NetCoreApp application referencing a .NetStandard 2.0/.NetFull 3.5 project. I can submit a bug report, how would I do that?

I've double checked the file names, no duplicates.

Silvenga wrote:Actually, kind of. The testing assembly having the issue is a .NetCoreApp application referencing a .NetStandard 2.0/.NetFull 3.5 project. I can submit a bug report, how would I do that?

There's an option in the 'NCrunch' menu for 'Submit Bug Report'. This sends through a log file containing some interesting trace information including the error itself and some details leading up to it.

Thanks for sending through the bug report.

The problem here seems to be coming from a Common project that is being multi-targeted. Somehow, at least one of your test projects has a dependency chain that includes two different multi-targeted instances of this Common project. So in the actual test domain we have both a netstandard and a net35 assembly of the same project being included. Can you think of any reason why this might be the case? Are you using binding redirections or the NCrunch implicit project dependencies setting?

Thanks for the hint, that is really odd, I'll look into it.

I can definitely say there are no NCrunch settings being applied.

I didn't find what you mentioned, but I did find that a netcoreapp2.1 referenced a net451 project in the test project's dependency chain. Removing that reference prevents the problem from surfacing.

I have no idea how this netcoreapp even built - there wasn't even a warning... I was under the impression that netcoreapp can never reference a net4** project, yes netstandard2.0, but not netcoreapp.

Silvenga wrote:
I have no idea how this netcoreapp even built - there wasn't even a warning... I was under the impression that netcoreapp can never reference a net4** project, yes netstandard2.0, but not netcoreapp.

This is also puzzling for me. I suppose it's possible the reference was somehow introduced outside the toolchain (i.e. manual edit of the project file), then nothing in the build system raised it as a problem.

The assembly/project referencing system is just so complicated now that we have .NET Core and .NET Standard. I've made a note to address NCrunch's error here to try and improve the experience a bit, since it's clear that this sort of thing can actually happen and throwing an obscure downstream exception isn't going to help people solve it. Thanks for taking the time to report this.