Reference added but Namespace is not recognized

Question

I added a DLL to my project. The DLL contains the namespace test.security. Now, test.security is not recognized. Why is this?

I am using this DLL in other projects and I have no other problems.

Stapleton

Did you add a reference to the DLL ? – Zapata

Answer 1

It often depends on what is in that namespace; for example, if nothing is in there then the namespace doesn't really exist.

It is also possible that you are missing some other dependency which means that the compiler can't use (until the reference is added) any of the types in that namespace (for example, if the types in that namespace all depend on some type from Another.dll, and you haven't referenced Another.dll).

It is possible you have referenced the wrong version of the dll, and the version you are referencing doesn't have that namespace.

It is possible the compiler is already telling you about a reference problem, meaning it can't use it - look in the errors/warnings list. For example, it could be a physically missing file, or a .NET version mismatch, or a strong-naming issue, that means it can't use the reference.

Sounder

In my case I simply did not have the public access modifier on my class. – Franco

Answer 2

Are you using Client Profile as a project target? Consider this scenario:

Project A -> Project targets .NET Framework 4.0

Project B -> Project targets .NET Framework 4.0 Client Profile

Project A is referenced by Project B. Namespaces in Project A are not recognised in Project B.

If ths scenario matches, this is due to a target mismatch. Client Profile supports a subset of the BCL of the full framework. If an assembly is dependent on using the full framework (like requiring types from System.Web, etc.) then it won't be useable from an assenbly that only supports Client Profile.

Easy solution, change Project B to .NET Framework 4.0 (not Client Profile).

Cordey

Got the same issue here... Default project was targeted with .net 4 Client Profile... – Feral

Answer 3

1.remove the reference and add it again 2.Close the solution and re-open it 3.Create a new solution and add all old ones in it

Illjudged

It is so stupid that this actually worked for me – Glori

Just removing the project reference and adding again seemed to work for me. – Mcalpin

Answer 4

Way late to the party, but obviously this came up in a recent search, so this is to help the newbie who lands here. Here's one more thing to verify.

As quoted from Dummy01's comment to his answer to this question:

Pack C# project to dll or another library

"DLL is in your project's bin or release folder. If it looks empty is because your classes are defined as private or internal. You should change the names you need to see outside your dll to public."

Kamala

Answer 5

Check your DLL,s .NET version and your host project's . NET version. Most probabbly there are different and somehow it creates problems in your specific case.

Regards.

Koodoo

Answer 6

I also faced this problem. In my case I tried removing the reference, rebuilding the referenced project, and then adding it again, but the problem still persisted.

The problem in my case was the classes in the targeted project's namespace were not public. This meant there was nothing accessible in that namespace, so it didn't really exist.

Setting them to a public access level solved the problem. Hope it helps someone! :)

Daphie

Answer 7

I had the same problem. I changed a console application to a class library in the project properties. That fixed it.

Modestine

Answer 8

I would like to add a cause for this, found in VB.NET (Visual Studio 2010, in my case; yours may vary).

As an example, I have two projects: P1 and P2.

P1 is an Application, and P2 is a Class Library.

Stipulations:

• There is a reference in P1 to P2
• Both P1 and P2 are targeting .NET 4.0 (full, not Client)
• Both P1 and P2 target x86 (not that it likely matters)
• There are 0 errors and 0 warnings

However, in P1, it is not possible to declare an 'Imports P2...' expression, nor to use any Shared methods found in P2. It exactly as if the Namespace P2 does not exist, though the reference is there.

Cause: P2 was converted to a separate assembly from code in which all methods were contained in a VB.NET Public Module. However, the 'Module' was not re-typed as a Public Class.

No errors whatsoever, but the P2 Namespace was entirely unavailable to P1 until a Public Class was created.

Of note, it was not actually necessary to convert the original Module to a Class. It was only necessary to declare some Public Class (even if it is empty) within the P2 Namespace, and then all methods found in that Public Module were available.

Pirzada

Answer 9

i added a console app on my project and couldn't access it. removed the exe section from csprojec file and is working now

Gerah