Develop Reference

Ambiguous domain with the same path

I am using Visual Studio 2013, with Resharper Ultimate 2015.2, developing a C# .NET 4.5 Console application whose solution space has multiple projects (DataAccessLayer, Domain, etc.)
All of a sudden (this has happened once in the last 3 months but I forgot how I fixed it), one of my C# files gives an Ambiguous Reference error and shows the exact same path.
Related Article: Ambiguous references with the exact same namespace provided the following solutions:
Delete .suo file.
Delete bin directories until all projects.
Resharper > Options > General > Delete Cache ( then restart VS)
Restart VS and rebuild solution
None of these seem to have any effect. I have checked that the references of the offending project only reference the "ambiguous reference" once.
EDIT:
Found another solution here: How to make ReSharper re-evaluate its assembly reference highlighting . Basically deleted Resharper Transient data. Did that. Still have the ambiguous reference. :(
I created another project with the same Includes, same references and same usages... just a subset and it works just fine !!!!!
EDIT 2:
The file compiles with no error!

In installed Resharper 10 and the ambiguous reference disappeared.

The type is defined in an assembly that is not referenced, how to find the cause?

I know the error message is common and there are plenty of questions on SO about this error, but no solutions have helped me so far, so I decided to ask the question. Difference to most of similar questions is me using App_Code directory.
Error message:
CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Source File:
c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs
Following suggestions here and here, I have deleted all instances of Project.Rights.dll inside C:\Windows\Microsoft.NET/*.*
According to this, I checked if .cs files in question have build action set to "Compile". They do.
I have also double checked that the .cs file containing the "Project.Rights.OperationsProvider" type is deployed to App_Code directory.
For some reason, application is not looking for the type in the App_Code directory. Since I've deleted all instances of Project.Rights.dll (that I know of), I don't know which assembly the error message is mentioning.

When you get this error it isn't always obvious what is going on, but as the error says - you are missing a reference. Take the following line of code as an example:
MyObjectType a = new MyObjectType("parameter");
It looks simple enough and you probably have referenced "MyObjectType" correctly. But lets say one of the overloads for the "MyObjectType" constructor takes a type that you don't have referenced. For example there is an overload defined as:
public MyObjectType(TypeFromOtherAssembly parameter) {
// ... normal constructor code ...
}
That is at least one case where you will get this error. So, look for this type of pattern where you have referenced the type but not all the types of the properties or method parameters that are possible for functions being called on that type.
Hopefully this at least gets you going in the right direction!

Check target framework in the projects.
In my case "You must add a reference to assembly" actually meant, that caller and reference projects didn't have the same target framework. The caller project had .Net 4.5 , but referenced library had target 4.6.1.
I am sure, that MS compiler can be smarter and log more meaningful error message. I've added a suggestion to https://github.com/dotnet/roslyn/issues/14756

In my case this was because doing a NuGet package update had only updated references to a dll dependency in some but not all projects in my solution - resulting in conflicting versions. Using a grep-style tool to search text within *.csproj files in my solution it was then easy to see the projects that still needed to be updated.

When you get this error, it means that code you are using makes a reference to a type that is in an assembly, but the assembly is not part of your project so it can't use it.
Deleting Project.Rights.dll is the opposite of what you want. You need to make sure your project can reference the assembly. So it must either be placed in the Global Assembly Cache or your web application's ~/Bin directory.
Edit-If you don't want to use the assembly, then deleting it is not the proper solution either. Instead, you must remove all references to it in your code. Since the assembly isn't directly needed by code you've written, but instead by something else you're referencing, you'll have to replace that referenced assembly with something that doesn't have Project.Rights.dll as a dependency.

In my case, I was referencing a library that was being built to the wrong Platform/Configuration (I had just created the referenced library).
Furthermore, I was unable to fix the problem in Visual Studio Configuration Manager -- unable to switch and create new Platforms and Configurations for this library. I fixed it by correcting the entries in the ProjectConfigurationPlatforms section of the .sln file for that project. All its permutations were set to Debug|Any CPU (I'm not sure how I did that). I overwrote the entries for the broken project with the ones for a working project and changed the GUID for each entry.
Entries for functioning project
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entries for corrupted project
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU
Corrupted entries now fixed
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64
I hope this helps someone.

It just happened to me that different projects were referencing different copies of the same dll.
I made sure all referenced the same file on disk, and the error disappeared as I expected.

Unloading and reloading the class library in Visual Studio solved this for me.

For me, this was caused by the project both directly and indirectly (through another dependency) referencing two different builds of Bouncy Castle that had different assembly names. One of the Bouncy Castle builds was the NuGet package, the other one was a debug build of the source downloaded from GitHub. Both were nominally version 1.8.1, but the project settings of the GitHub code set the assembly name to BouncyCastle whereas the NuGet package had the assembly name BouncyCastle.Crypto. Changing the project settings, thus aligning the assembly names, fixed the problem.

It didn't work for me when I've tried to add the reference from the .NET Assemblies tab.
It worked, though, when I've added the reference with BROWSE to C:\Windows\Microsoft.NET\Framework\v4.0.30319

I had this issue on a newly created solution that used existing projects. For some reason, one project could not "see" one other project, even though it had the same reference as every other project, and the referenced project was also building. I suspect that it was failing to detect something having to do with multiple target frameworks, because it was building in one framework but not the other.
Cleaning and rebuilding didn't work, and restarting VS didn't work.
What ended up working was opening a "Developer Command Prompt for VS 2019" and then issuing a msbuild MySolution.sln command. This completed successfully, and afterwards VS started building successfully also.

one of main reason can be the property of DLL
you must before do any thing to check the specific version property if it true make it false
Reason:
maybe the source code joined with other (old)version when you build it , but this Library upgraded with new update the version now different in the Assembly Cash and your application forbidden to get new DLL ,and after disable specific version property your applacaten will be free to get the new version of DLL references

Maybe a library (DLL file) you are using requires another library. In my case, I referenced a library that contained a database entity model - but I forgot to reference the entity framework library.

This can also mean you use a library, which exposes (public) types that are defined in a library. Even when you do not use these specifically in your library (the one that doesn't build).
What this probably prevents is you writing code that uses a class (which in its signature has the types from a library not referenced) that you cannot use.

For me the reason why the error appeared was that the WebForm where the error was reported has been moved from another folder, but the name of its codefile class remained unchanged and didn't correspond to the actual path.
Initial state:
Original file path: /Folder1/Subfolder1/MyWebForm.aspx.cs
Original codefile class name: Folder1_Subfolder1_MyWebForm
After the file was moved:
File path: /Folder1/MyWebForm.aspx.cs
Codefile class name (unchanged, with the error shown): Folder1_Subfolder1_MyWebForm
The solution:
Rename your codefile class Folder1_Subfolder1_MyWebForm
to one corresponding with the new path: Folder1_MyWebForm
All at once - problem solved, no errors reporting..

The type 'Domain.tblUser' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Domain,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
**Solved:**
Add reference of my domain library layer to my web app libary layer
Note: Make sure your references are correct according to you DI container

In my case this was because I used
Implicit Operator
between BLL and DAL classes.when I want to use BLL Layer In Application Layer I got this error.
I changed
implicit operator
to
explicit operator
it be OK.
Thanks

In my case the version of the dll referenced was actually newer than the one that I had before.
I just needed to roll back to the previous release and that fixed it.

I have a similar problem, and I remove the RuntimeFrameworkVersion, and the problem was fixed.
Try to remove 1.1.1 or

My problem was that the Output Type for one of my projects was set to Console Application. To fix this, I right-clicked the project, chose Properties, clicked the Application tab, and change Output Type (from Console Application) to Class Library. After I re-compiled, this error went away.

Clean your solution and rebuild worked for me (in Visual Studio, these are options you get when you right click in your solution explorer), the error is gone in my project.

Type or namespace name does not exist in the namespace - yet the namespaces do exist

A project that I've been working on for a long time without any problems suddenly started throwing errors such as
The type or namespace name 'xxx' does not exist in the namespace 'yyy' (are you missing an assembly reference)?
In this case, the namespaces were all core .Net libraries such as System.Data, Linq, and IO that I've been using without any problems.
I've worked through all of the issues in this question such as making sure all the projects in the workspace are using the same version of .Net for the Target Framework setting.
I removed all the libraries in question and re-added them but the problem persisted. I doubt they libraries themselves are corrupted as I reference them in other projects within the solution.

After rolling back through my work with TFS I managed to work out what I'd done that had created this error: I'd added a folder called "System" to my project and put a class file in it.
This is an easy issue to reproduce: create a project, add a folder called system to it (it will still compile at this point) and then create a .cs file in it, that's when all the fun errors will occur.
The problem stems from the name of the "System" folder which leads to any files created in it being under the namespace ".System".
I can understand why having a folder / namespace called "System" would cause problems now but I think it would help if Visual Studio warned when creating a folder / namespace of such a name to stop this problem happening in the first place. I've logged a bug with MS, at least having this logged might help any other people who have made the same mistake as me!

I had the same issue after my system shut down unexpectedly and even though VS tried to restore, the problem popped up.
I had two projects in my Solution Explorer. To solve this, I right-clicked the project that was associated with the error message and selected 'Build'.
After that, the issue was resolved.
Just to add that the problem was permanently solved after I added a reference to the 'project' from the other 'project'.

I renamed the namespace of the file I was referencing from myproject.shared.constants to myproject.SOMETHING.shared.constants
After that It suggested "use myproject.SOMETHING.shared.constants" as suggestion. I renamed it back to myproject.shared.constants and then it worked.

Try to Clean and Then Rebuild the dll file .I was experiencing the same problem tried different suggestions from internet but none of them work.But it will. In case you don't know how follow these steps:
open your dll project file.
2.click on solution Explorer Right click on Your Dll Project Name you will find Clean and Rebuild Option.

VS 2010: C# Project Cannot Open DLL

I'm having an issue building a project that references a DLL located in the project's bin folder, which up until yesterday was building and running without issue.
The error I'm getting is fatal error CS0009: Metadata file 'c:\MyProject\bin\myClient.dll' could not be opened -- 'Error importing module 'myClient.netmodule' of assembly 'c:\MyProject\bin\myClient.dll' -- The system cannot find the file specified.' Intellisense is similarly complaining that The type or namespace 'Api' does not exist in the namespace 'Client' since it can't find the DLL.
Let me know if you think this is a duplicate, but I've viewed several similar posts and the solutions did solve my problem. Here are some examples:
Visual Studio 2010 — are you missing a using directive or an assembly reference?
VS2010 - Getting “type or namespace name could not be found” but everything seems ok?
Stymied by ASP.NET Compilation Error CS0009
Metadata file '…\Release\project.dll' could not be found in Visual Studio
Visual Studio 2010: Metadata file “…/Debug/Graph.dll” could not be found
Metadata file … could not be found error when building projects
Specifically, I've tried the following solutions (and combinations of these):
Cleaned and rebuilt my project.
Made sure that the target framework is not a 'client profile' version of .NET
Verifyied that the dll has been added as a project reference
Removed and re-added the project reference
Verified that the project is showing the DLL in the References section in Visual Studio
Repaired .NET
Verified the location of the DLL (it is in the local project's bin folder as given by the error)
Tried other versions of .NET
Closed and restarted Visual Studio
Rebooted my machine
Verified there are no hidden characters surrounding the 'using' statement
Removed all code changes since the last working build
Verified the settings in Configuration manager, including that 'Build' is checked
The project calling the DLL is a small class library that resides in a solution with one other small project (a console application). The DLL is an external DLL that I've been using successfully for several weeks in this project/solution. The error arises regardless of whether I build the project from the solution or by itself.
Any ideas about what could be going on?

Have you included bin folder in your project accidentally? If yes that might cause the issue. You can't include bin folder in your project as the bin folder will be created by the VS. If you accidentally include bin folder in your project, the bin project will be set to Copy to output which when you compile, the file is deleted and copied to output by Visual Studio that trigger weird behavior that some file is missing.
Hopes this help

Well I'm not sure exactly what happened here, but here is what finally resolved the issue:
A good-old-fashioned delete every single file and rebuild the project from those files from scratch. I gave +1 to some of the responses because they were useful to consider, and because there was probably a messed-up reference some where as Jonathon Wood suggested.

"An assembly with the same simple name has already been imported" error without duplicate reference

I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.

So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.

In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.

In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.

If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps

I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.

For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.

For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)

In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.

Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project

In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.