Search code examples
c#.netvisual-studionugetproject.json

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


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?


Solution

  • 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.