It happened I am responsible for maintaining an older C# application. The application connects to a MySQL server and for some reason the MySql.Data.dll was included on disk and checked in.
So I thought on changing this to reference using a NuGET package. I removed the dependency on the checked in binary and added a package reference.
Now when I build the application I get the following error:
"path\myproject.csproj" (build target) (1) ->
(GenerateApplicationManifest target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3987,5): error MSB3113: Could not find file 'lib\MySql.Data.dll'.
I tried to find any occurrence of that dll but there seems to be no reference anymore.
How to stop the project referencing the non existing library?
The problem was, that even though I removed the dll within Rider the deployment reference (<Content ...) within the csproj file was not removed.
I am receiving an error when I try to compile my c# source code file on my Mac. Normally I compile my source code using the mcs command on a bash terminal window and it compiles fine. But, this one particular project requires the installation of the NuGet package 'MySql.Data'. This has resulted in the following error message:
error CS0246: The type or namespace name 'MySqlConnection' could not be found. Are you missing an assembly reference?
I have tried to follow numerous solutions online to try and add the assembly reference, but my IDE just does not look like the help documentation's screenshots.
I have tried to Edit References, but no references appear. I tried to manually download the MySql.Data.dll (v.6.3.5.0) but I think it is for an outdated version of the MySql.Data class library as it does not work. Even after cleaning the code and rebuilding it.
Edit: I have also tried to add the dll that was included in the project folder but it said it could not locate the assembly (even though they are both in the same project folder).
Could not resolve this reference. Could not locate the assembly "search_feature". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. (MSB3245) (search_feature)
Edit 2: I renamed the dll file from the project bin folder to MySql.Data.dll and I no longer get the error. But it still won't compile.
The code works fine when run in Visual Studios for Mac, but I just can't compile it. Any ideas how to add the assembly reference?
I am using the most up-to-date version of Visual Studios:
Visual Studios for Mac Community 7.5.4 (build 3)
I have tried uninstalling and reinstalling Visual Studios for Mac.
My code has the library reference at the top: Using MySql.Data.MySqlclient; and the project runs. It just won't compile.
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.
I have created a project library dll and it resides in the bin directory of the solution. I've got a second solution that references that dll. In the VS2013 IDE my 'Using' directive is happy and down n the code when I reference a class in the dll the code is happy. If I view the object reference in the object browser all look ok. I've also looked in the csproj file and the correct reference is in there. When I try to build the project I receive the type or namespace for my dll could not be found error message. I've tried cleaning first, I've also closed VS2013 and restarted all to no avail. I've also tried copying the dll to the local bin directory for this solution and re-referencing and still no joy
Ok, I found the solution. The project that I am referencing is targeting .net4.5.2 of the framework. THe project that was referencing it was only referencing .net4.5 I have set this to .net4.5.2 and it now builds.
Thanks
For all the input
Hej All,
I upgraded my solutions of a project from vs2008 to vs2010.
But right now I have a weird problem. I reference a project in multiple solutions (3 solutions)
In 2 of those solutions the referencing goes wrong.
I am able to add the reference (project reference) but when I build I got the warning the referenced project x does not exists. And errors that I have to add an reference.
I already deleted and added the project again, same with the references but no result.
Does anybody have any idea?
Greetz,
Jonathan
I had the a similar problem and the other solutions didn't help. What worked for me was opening the project file in a text editor. There were duplicate references to a library, one as a project reference and one as a dll reference. I deleted both. Then I opened the solution in Visual Studio, and re-added the reference as a project reference. Only one reference got added and I stopped getting the warning.
Make sure your project is not using the ".NET Framework 4 Client Profile" as target framework, this is the most common source of these problems.
You can check this in the project properties under Target Framework.
From MSDN:
If you are targeting the .NET
Framework 4 Client Profile, you cannot
reference an assembly that is not in
the .NET Framework 4 Client Profile.
Instead you must target the .NET
Framework 4. For more information, see
Troubleshooting .NET Framework
Targeting Errors.
I was experiencing the very same issue although I was correctly referencing .NET 3.5 in all the projects migrated from VS 2008 to VS 2010 (all references to System assemblies were using a runtime version v2.0).
Weird however, the error only occured if my solution (and the projects in this solution's subfolders) were located in certain path... I could "solve" the problem by moving the projects or renaming the projects (only the project file, not the output binaries) ?!
Double clicking the reference in the project opened correctly the Object Browser where I could find all the artifacts defined in the referenced project !
I did start to delete everything from the project (classes, resources, references, etc...). At the end, I had only two projects (A referencing B) without any other references and with only one empty class in each. I still had the message "referenced project '..\B\B.csproj' does not exist.". Suddenly, trying to copy the source to another PC and next back into the original path on my machine (kind of black magic to solve the problem), I did get the message "Cannot copy. Resulting file name is too long".
Wierd² !!! I did delete every thing on my PC and did copy back again the sources from the other PC. It passed successfully ! I did recopy again back from the other PC (overwriting now the existing local copy) and again I got the message "Cannot copy. Resulting file name is too long". So the problem occurred only when overwriting existing files.
I found that the error occurred only if the existing file was "readonly". Removing the flag readonly solved this issue. However, this error was the sign of something possibly at the root cause of my initial issue: "referenced project '..\B\B.csproj' does not exist."
So, I decided to check if the project path length was the issue by renaming one of the folder but not changing the total length! The error still occurred (reference not found).
Next (I knwow, you already think I am crazy or stupid. But all those steps were validated by various colleagues), I did copy the solution in a new folder (with a longer path). Surprise, the error did not occurred anymore !!!
But moving the solution back to a folder with the same length (possibly another name) was reintroducing the error (after a "Clean" of the solution otherwise the meta in obj helped to solved the reference).
I was also able to reproduce this by renaming the project file B instead of a folder in the path. A longer or shorter project filename was solving this issue.
The length of the project filepath is "195" :
D:\TFS_Builds\5\XXXX 1.1\Release 1.11\Sources\Release 1.11\Exception Repository\XXXXXX.Framework.ExceptionHandling.Repository.ServiceHost\XXXXXX.Framework.ExceptionHandling.Repository.ServiceHost
Also, as I can be very creative when trying to identify the root cause of a problem, I did create the very same path on C:\ and put the solution in there... Same error occurred.
I never found (until now) the reason of this and have posted a question on MSDN :http://social.msdn.microsoft.com/Forums/en/msbuild/thread/f0eb6aed-5854-4678-9546-09c1a7705e30
Here is what fixed my problem:
I had a refference to a project named "Utilities.Proxy3.5", which would give me a the following warning:
"The referenced project
'..\..\Utilities.Proxy3.5\Utilities.Proxy3.5.csproj' does not exist."
Renaming the project folder and the project files to "Utilities.Proxy35" and re-adding the reference solved the problem. Note: I have only removed a dot between the numbers 3 and 5.
I hope this will help someone.
I had the same issue.
What solved it for me was that i opened each of the reference projects on its own first. VS asks for a permission to fix some of the files. Allow it to do so.
Then open the top project and it will work.
Apparently it was issues with the version of VS that created the original project.
Good luck
Check the lengths of the following:
The path of the referencing project's directory
The relative path to the project it references
If those paths add up to exactly 259 characters, you will experience a bug in the .NET implementation of Path.GetFullPath that will cause VisualStudio 2010 to behave as if the referenced project does not exist.