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 oth

Answer 1

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).

Answer 2

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

Answer 3

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.

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."

Answer 5

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! :)

Answer 6

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.