Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

System.ArgumentException: An item with the same key has already been added.
Silvenga
#1 Posted : Monday, December 3, 2018 10:37:22 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/24/2016(UTC)
Posts: 14
Location: United States of America

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
Remco
#2 Posted : Monday, December 3, 2018 11:18:49 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,482

Thanks: 718 times
Was thanked: 899 time(s) in 855 post(s)
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?
Silvenga
#3 Posted : Monday, December 3, 2018 11:50:34 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/24/2016(UTC)
Posts: 14
Location: United States of America

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.
Remco
#4 Posted : Monday, December 3, 2018 11:53:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,482

Thanks: 718 times
Was thanked: 899 time(s) in 855 post(s)
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?
Silvenga
#5 Posted : Tuesday, December 4, 2018 1:00:22 AM(UTC)
Rank: Member

Groups: Registered
Joined: 1/24/2016(UTC)
Posts: 14
Location: United States of America

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.
Remco
#6 Posted : Tuesday, December 4, 2018 1:37:50 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,482

Thanks: 718 times
Was thanked: 899 time(s) in 855 post(s)
Silvenga;12876 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.

Remco
#7 Posted : Tuesday, December 4, 2018 10:30:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,482

Thanks: 718 times
Was thanked: 899 time(s) in 855 post(s)
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?
Silvenga
#8 Posted : Monday, December 10, 2018 2:49:06 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/24/2016(UTC)
Posts: 14
Location: United States of America

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

I can definitely say there are no NCrunch settings being applied.
Silvenga
#9 Posted : Monday, December 10, 2018 4:32:49 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/24/2016(UTC)
Posts: 14
Location: United States of America

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.
Remco
#10 Posted : Monday, December 10, 2018 10:37:14 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,482

Thanks: 718 times
Was thanked: 899 time(s) in 855 post(s)
Silvenga;12909 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.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.058 seconds.