How to debug/fix 'An assembly with same simple name' has already been imported

Question

I've used nuget install-package to install a package (let's call it PackageA) into a project. After install, my project.json file looks like this:

{
  "dependencies": {
    "PackageA": "1.1.15"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

Now, PackageA has an indirect dependency on PackageC. Nuget successfully installs the package, but when I compile I get an error CS1704 "An assembly with the same simple name 'PackageC' has already been imported. Try removing one of the references (...\PackageC.dll) or sign them to enable side-by-side."

Strong signing is not an option, per the folks who tell me what to do.

If I delete the reference suggested by the CS1704 message, then I get a compilation error stating "Could not copy the file ...\PackageC.dll" because it was not found."

If I change the PackageA version to a floating version "*", then Nuget complains that it can't resolve a bunch of dependencies. (I eventually want to use floating versions.)

{
  "dependencies": {
    "PackageA": "*"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

If I then overspecify my project.json, that error goes away and the CS1704 returns.

{
  "dependencies": {
    "PackageA": "*",
    "PackageB": "*",
    "PackageC": "*"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

Some additional notes to make this more perplexing:

1. All package dependencies also use floating versions.
2. I've tried clearing the nuget cache (nuget locals all -clear) to no avail.
3. Package install and compilation works fine if I ditch project.json and nuget automatic restore. Unfortunately, this isn't an option either.
4. This was previously working. No idea what changed that broke it.

What can I do to debug / fix this?

Answer 1

Nuget was importing the non-latest version of a package (call it PackageX) which had PackageC as a dependency; in turn an older version of PackageC was imported. This was the source of the problem.

I debugged this issue by clearing the global nuget cache and rebuilding my solution. After doing so, I inspected each package cached in c:\users\<me>\.nuget\packages for which floating versions have been specified anywhere in my dependency chain. I compared each of these to the latest versions on my private feed, looking for discrepancies. In doing so, I discovered that an outdated version of PackageX had been cached together with the outdated version of PackageC.

To solve the issue, I did some additional overspecification of my project.json to include "PackageX": "*" as an additional dependency. Once I did so, the proper (latest) version of PackageX was installed from my private feed and compilation proceeded without issue.

Answer 2

What can I do to debug / fix this?

In some cases with older code (and no duplicate assembly references to be found) this error will happen in one version of Visual Studio but not another. If you have multiple versions of VS installed, launch a newer one and then from the File menu open the solution and build it. If the error goes away, you have a couple different options for making the change permanent:

If you're feeling particularly bold, you can manually edit the solution (.sln) file to have it always open the project in the working VS version. (To find the version number to use, create a throwaway project and examine the generated solution file.) For example:

VisualStudioVersion = 12.0.40629.0

might become

VisualStudioVersion = 15.0.28307.572

However, the above can be somewhat risky since file formats may have changed between VS versions. So the other approach would be to recreate your project in the working VS version and copy the code over.

Answer 3

What can I do to debug / fix this?

This error points out that two references have the same assembly identity because the assemblies in question lack strong names, they were not signed, and thus the compiler has no way of distinguishing between them in metadata. Thus, the run time ignores the version and culture assembly name properties. You can refer to Compiler Error CS1704 for more detail.

To resolve this issue, you can try to provide a strong name for them, if this option is not your choice, you can also try to remove the redundant reference or rename one of the references.

You can check the project file to make sure whether the "PackageC" has been imported (Right click project->Unload project->Edit project).

Answer 4

This just happened to me.
A project is part of a solution and then referenced in other projects also in the solution. The mistake was to add a reference via an absolute path, i.e. \debug\output.dll (for example) in the Add Reference dialog.
This caused problems in the compilation sequence because other projects had the 'output.dll' added as a project reference and the build config was set to 'Release'. Therefore, two different references of the same assembly during the build sequence.

To Solve, I went through the entire project list and removed 'Output.dll' reference and re-added it as a project reference. This allows the configuration to select the appropriate dll based on the configuration path. Any project referencing another project in a solution should be added via project reference instead of browsing a path.

Answer 5

A harder-to-diagnose situation when this error occurred for me is when:

• Project A generates this 'same-simple 'X' has already been imported' error
• Where X is being imported as with standard Reference tag
• Where A imports other projects B and C as ProjectReference tags
• Where B and/or C also import X as ProjectReference

Was able to see both assemblies referenced, one as an implicit reference (in rider) and the other a standard [explicit] assembly reference. They had same major/minor versions but different build #s (presumably bc the project reference for X in B/C was rebuilding everytime project A was built).

Fix is to either switch everything to ProjectReference, or what we did which is switch assemblies generating this error to assembly/dll using Reference tag. We then only use project references for projects co-located together, eg in the same solution.