The type or namespace <blah> does not exist

Viewed 44062

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.

12 Answers

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.

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.

Related