The type or namespace does not exist

Question

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

Answer 1

Basically, this sounds like a missing reference.

Some sanity checks I can think of are:

1. Are you sure that the project that generates the error is C?
2. Are you sure you are did not make a spelling mistake in the namespace B in your using?
3. Can there have been some compilation error in B before compiling C? (That may cause the compiler to fail finding the namespace in B).
4. Do you have any other compilation error or warning?

Edit

Another suggestion: is the class in the B assembly defined as public?

Answer 2

In my case, I have to check where the "WorkFlow"¹ 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.

---

¹ "WorkFlow" comes from a legacy code using custom code for WorkFlows.

Answer 3

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.

Answer 4

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

Answer 5

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:

Answer 6

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.