We Keep Coding

"Warning CS1684: Reference to type X claims it is defined in .. but it could not be found"

I'm getting this warning when building a test project we'll call PWTests.
Warning CS1684: Reference to type 'System.Windows.Input.ICommand' claims it is defined in 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.dll', but it could not be found
This project is supposed to test a class library which we'll call PW. I cannot determine why it thinks System.Windows.Input.ICommand is defined in System.dll. PresentationCore, where ICommand is actually defined, is properly referenced in the test project, and the class library project. I've tried removing the reference to PresentationCore, cleaning, and re-adding it (as mentioned in other questions) which did not work.
How can I determine what is causing it to think that ICommand is in System.dll?

We really need more information, but here is how I have solved this.
Tends to be when you've added something by nuget or something like that, if you look in your app.config you'll see some redirects in there (probably) check the assembly that ICommand is in (usually in your bin folder or directly referenced) and ensure that the versions line up in there.
It would help if you posted your app.config and state the assemblies you are using so I can be more accurate.

The following note might not be the issue here but i got this error when i referenced a DLL that was created with VB.NET. VB.NET is not case sensitive therefore it might be possible that in project settings the namespace is stated as lowercase whereas in source code it's written as uppercase. The compiler then gets confused. In this case just check for lowercase / uppercase issues and fix it.

How come I don't need to reference "System.dll" to use the "System" namespace?

I am working on an assignment that specified "Do not use any external libraries". So I created a c# application, and the first thing I did was remove all the dll's references by default... including "System.dll".
However, I can still add this to my code:
using System;
using System.IO;
I was just curious as to how come I do not need to have System.dll as a reference in my project to do this. Thanks!

mscorlib.dll includes items in both those namespaces.
You need to right-click your project > Properties > Build > Advanced... and check "Do not reference mscorlib.dll" to remove this reference.

Different assemblies can contribute to the same namespace.
Even if you don't reference System.dll, you are still referencing (implicitly) mscorlib.dll which contributes many types to the System namespace.

These references are probably defined in your Web.config or the Machine.config file so they're included by default.

These are the default libraries.I think your question is that "Dont use third party dlls"

Another thing to consider is, if you're compiling directly through the command line, a default set of switches, including default library references, is parsed by the compiler through the default response file (csc.rsp), located in the same directory as the compiler. The fact that you are able to import namespaces from the Base Class Library without explicitly referencing them at compile time is due to the fact that their containing assemblies are included in your program by default. To change this behavior at the command line, you can use the /nostdlib switch to force it not to include mscorlib.dll, or you can use /noconfig to have it ignore the entire default response file altogether. Also, I'm not too sure what you mean by system.dll, because the namespaces you mentioned are contained within mscorlib.dll. Also, I think by "external library", your instructor must have meant any 3rd party assemblies that would assist you in solving the problem. Anything that comes included with the .NET SDK would be more of a framework library. Unless your teacher is really harsh and wants you to reinvent the wheel :P

IKVM changes com.sun.org.apache.xerces.internal to com.sun.org.apache.xerces.#internal

I used the latest build of IKVM (7.0.4335.0) to convert the newest version of HtmlUnit (2.9) to .Net. However, when I attempt to create a WebClient object, it throws an error saying, "Provider 'com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl' not found" I thought this was strange because I had included all the needed assemblies in my project.
I then decided to try to see if I could reach this namespace/class and got as far as com.sun.org.apache.xerces, but then when I tried to type internal, the only option that I had via intellisense was '#internal'.
Therefore, com.sun.org.apache.xerces.#internal.jaxp.DocumentBuilderFactoryImpl exists, but com.sun.org.apache.xerces.internal.jaxp.DocuementBuilderFactoryImpl does not exist. This obviously poses a problem when it can't find the right namespace. Any suggestions?

You should not use packages with name internal directly. This are internal packages and can change in the future.
The # character is C# syntax to access names that are reserved keywords. The word "internal" is a keyword in the C# syntax. This means the C# compiler change com.sun.org.apache.xerces.#internal to com.sun.org.apache.xerces.internal.

The type or namespace <blah> does not exist

Ok, I have had this one a million times before and it's been answered 1 million +1 times before.
And yet, once again. I have 3 projects, A, B, and C, each a DLL. Each project is .Net 4.0 (not the client build, full 4.0). Project C references A and B. They are referenced as projects, and the output is set to copy locally.
In C, I have two using statements in my .cs file:
using A;
using B;
When I compile, I get the complaint that is cannot find B. A is fine. B depends on A.
What the heck should I do? I've removed and re-added, closed VS2010, re-opened it, looked at the .csproj file. And I just cannot get it. Again, for the millionth time.
Someone please slap enough sense into me that I learn the source of this once and for all!
And yes, this is probably answered somewhere in StackOverflow, but not in any of the top answers I've checked so far. The terms are just too generic to be of use, too many questions where the answer is "duh, add a reference". I'm past that point.
Here are the errors I get. There are 3 kinds, but from past experience, the last one is the true one.
Error 130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an assembly reference?)
Error 114 'object' does not contain a definition for <blah>
Error 59 The type or namespace name '<blah>' could not be found (are you missing a using directive or an assembly reference?)
Aha I looked at the warnings, not just the errors, and here is what I see:
Warning 69 The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist. AWI.WWG.EXPMRI.MriUpload.Objects
That .csproj file is the "B" in this case. Even though I remove and re-add the project reference I get this. But it feels like I'm getting closer!
Hmm, I just found another DLL, call it "D", which "A" references. When I add it to the project, I start to get the complaint:
----------------
The Add Reference Dialog could not be shown due to the error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------
Could this be related, or just another distraction?
Ok, I found the issue, though I do not understand it.
When I add the reference through the IDE, it adds this to the csproj file of "C":
<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">
This does not compile, it WARNS that it cannot find the referenced project, then all those ERRORs happen. But then I change the ProjectReference to the following:
<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">
... and it works just fine. Note that neither of those paths are anything close to 256 characters. The fully qualified one is only 135 characters. But perhaps the IDE is doing some silly decoration of the path.

The solution has to do with the file path limits in Windows, and they way the IDE translates relative paths into full ones, as explained in this blog.
The immediate solution is to edit the csproj file manually to use the absolute path. Until the reference is re-added, the absolute path will be valid. One day I may shorten my folders, but it's not top priority at the moment.
If you suspect you have this issue, look at the Warning messages from the compiler. I often have these turned off myself, only looking at errors. But the warning about "the referenced project does not exist" was the clue that solved this for me.
In case the other link disappears, here is the link to the MS article.
http://support.microsoft.com/kb/2516078
It is worth noting that this same error manifests for a variety of issues such as client-framework-targeting issues, and is logged as a warning when a reference fails to load. Presumably the reference error is only a warning because if the reference is not actually needed it doesn't matter.

I would make sure that your project has included the references to the assemblies.
I would check that the build order matches your dependencies
Finally, if everything is setup properly, you should see the following Build Order:
Doesn't look like this is your problem, but for completeness, I should add that another thing to check (if your project targets the .NET Framework 3.5 or above) is that the Target Framework for both projects match. If you are linking something that targets the Client Profile from a full version of the Framework, you will also get a 'not found' error:

Go to warning section and resolve all warning and you are done...
The warning section will tell you what all internal dlls dependencies are needed for the project you are referencing to.

I know this isn't the answer to your issue, but the error is quite similar when you are trying to reference a project with a higher .net version than the one you're using. IE: you can't reference something with .net 4.5 from .net 3.5

Basically, this sounds like a missing reference.
Some sanity checks I can think of are:
Are you sure that the project that generates the error is C?
Are you sure you are did not make a spelling mistake in the namespace B in your using?
Can there have been some compilation error in B before compiling C? (That may cause the compiler to fail finding the namespace in B).
Do you have any other compilation error or warning?
Edit
Another suggestion: is the class in the B assembly defined as public?

I got this when updating a project that we normally use via NuGet. I thought if I simply copied the updated built dll over to the packages folder I could test it without having to setup NuGet on my machine, but it wasn't that simple because my app was still looking for the old version number. Hope that helps someone out there.

After many hours of frustration, I discovered the following process to resolve this issue with a VS2017 solution:
Insure that all reference assemblies have been recognized and have current properties.
If assemblies do not show proper reference, right click the entry
and view properties. This action often resets the reference. This
action must be completed for each project in the solution.
After resolving all references, if the error continues, delete the
following:
-The Obj folder
-The Bin folder
-Reference to the offending assembly
-Clean and Rebuild the solution. Errors should occur.
-Re-reference the needed assembly.
The editor should no longer show the namespace error and build should succeed.

Create clean project and test minimal sets of assemblies you use in your project. This way you will be sure if there is something bad in your solution or if newly created project has same symptoms. If so, then maybe VS, .net etc is corrupted or something.

I started getting this error suddenly while trying to solve another problem
I solved this by going to Solution=>properties=>project dependencies and all the dependencies were off for the two projects I was getting a namespace error for. I checked the check boxes and rebuilt the solution with no errors.

I solved this using global::[namespace][type I want to use] in C# 6.0

With VS2017, this issue came up for me when the project in my solution was unloaded.

In my case, I have to check where the "WorkFlow"1 was implemented.
Hence, I compare the framework version of the projects/class libraries that uses this "WorkFlow".
After check that all projects/class libraries uses the same framework, I have to search ".WorkFlow" in the project/class library that was causing the builing error.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):
error : The type or namespace name 'WorkFlow' no exists in the
namespace 'Proyect_to_build' (are you missing a using directive or an
assembly reference?)
It turns out that the .dll that contains "WorkFlow" was missing in the "Reference" folder. Once added the .dll, the project/class library compiled successfully.
Again, in my case, I wasn't using this .dll and I only need compile the project/class library for enable breakpoints in a certain part of the program (where "WorkFlow" is not involved at all), but well, after add it (the .dll with the "WorkFlow" source code), it compiled.
1 "WorkFlow" comes from a legacy code using custom code for WorkFlows.

C# Compiler Warning 1685

So, (seemingly) out of the blue, my project starts getting compiler warning 1685:
The predefined type
'System.Runtime.CompilerServices.ExtensionAttribute'
is defined in multiple assemblies in
the global alias; using definition
from 'c:\Program Files\Reference
Assemblies\Microsoft\Framework\v3.5\System.Core.dll'
Perplexed, I researched the MSDN article to figure out its cause. Here's the information I found:
Visual C# Reference: Errors and
Warnings Compiler Warning (level 1)
CS1685
Error Message The predefined type
'System.type name' is defined in
multiple assemblies in the global
alias; using definition from 'File
Name'
This error occurs when a predefined
system type such as System.int32 is
found in two assemblies. One way this
can happen is if you are referencing
mscorlib from two different places,
such as trying to run the.Net
Framework versions 1.0 and 1.1
side-by-side.
The compiler will use the definition
from only one of the assemblies. The
compiler searches only global aliases,
does not search libraries defined
/reference. If you have specified
/nostdlib, the compiler will search
for Object, and in the future start
all searches for predefined types in
the file where it found Object.
Now I'm really scratching my head.
I'm not running two different
versions of the .NET Framework
(unless you count 2.0 and 3.5).
I'm not referencing any bizarre
assemblies that might make me
suspicious.
I don't recall making any changes to my application that would spur this change.
I've verified that all components target .NET Framework version v2.0.50727.
I'm open to suggestions, or ideas on how to correct this. I treat warnings as errors, and it's driving me crazy.
What really bugs me about it is that I don't know why it's occurring. Things that happen should have a discernable cause, and I should know why they happened. If I can't explain it, I can't accurately remedy it. Guesswork is never satisfactory.
The application is straightforward, consisting of a class library, and a windows forms application.
A C# class library DLL providing basic functionality encapsulating database access. This DLL references the following components:
System
System.Core
System.Core.Data
System.Data
System.Data.DataSetExtensions
System.Data.OracleClient
System.Drawing
System.Windows.Forms
System.Xml
System.Xml.Linq
A C# Windows Forms application providing the UI. This application references the following components:
CleanCode
CleanCodeControls (both of these provide syntax editor support, and are locally built against .NET 3.5).
LinqBridge
Roswell.Framework (the class library above)
System
System.Core
System.Data
System.Data.DataSetExtensions
System.Data.OracleClient
System.Deployment
System.Design
System.Drawing
System.Windows.Forms
System.Xml
System.Xml.Linq
Let me know if you need further information and I'll gladly provide it.

Another easy way to verify:
In your code, temporarily use the class somewhere.
Example:
System.Runtime.CompilerServices.ExtensionAttribute x = null;
When building, this will generate error:
The type 'System.Runtime.CompilerServices.ExtensionAttribute' exists
in both 'c:\Program Files\Reference
Assemblies\Microsoft\Framework\v3.5\System.Core.dll' and .....
And show you immediately the 2 sources causing the conflict.

LINQBridge makes me immediately suspicious. The entire intent of this is to provide extension attribute/methods etc for 2.0 users. If you have 3.5 (System.Core.dll), don't use LINQBridge. If you do need LINQBridge in 3.5 for some obscure reason (and I can't think of one), then you might have to use an extern alias. But I really doubt you need it!

Marc is almost certainly correct. Here's a way to verify
Open Reflector.exe
Add all of Non-System assemblies
F3 and search for ExtensionAttribute
If it pops up anywhere besides System.Core then you know where it's coming from.

Another solution for this issue is to use a global alias for the whole assembly:
Reference -> Properties -> Aliases -> Replace 'global' with something else

FYI: I had the same problem and was able to resolve it by using Resharper's "Optimize References" command, and then removing all unused references. Not completely sure why that worked, but it did.

My teams resolution for this CS1685 warning was removing the binding redirect for System.Text.Json.
<dependentAssembly>
<assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>

Another solution for this issue => Right click project -> Properties -> Build -> Treat warnings as errors -> None