Namespace Not Recognized (Even Though It Is There)

Namespace not recognized (even though it is there)

Check to make sure that your project isn't set up to use the .NET Framework 4 Client Profile.

You can check/change this by right-clicking your project (not the solution), select Properties -> Application -> Target framework. The target framework is a dropdown on that page.

This is a problem in Visual Studio (I would even go so far as to call it a bug). AutoMapper requires assemblies that are excluded from the .NET Framework 4 Client Profile. Since your project is using that version of the framework it breaks.

A similar error will propagate to the build process when the .NET Framework version for the project you are referencing is higher than the project making the reference. i.e. A project targeting 4.5 that references a project targeting 4.5.1 will give you this same error.

There needs to be a better error message when this happens because there is no rational explanation as to why it would not build as the error message tells you to reference an assembly you have clearly referenced.

Reference added but Namespace is not recognized

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.

Visual Studio: 'using namespace' not being recognized

I renamed the Maintenance folder to Maintenance1, recreated the Maintenance folder, and dragged and dropped the SettlementAccountReconciliation class into the Maintenance folder, and it seems to have fixed the issue.

I am guessing there was some random property or setting stored in a temp folder somewhere in Timbuktu that was stored for the existing folder that was reset or deleted when the new folder was created.

Namespace not recognised in using statement. The type or namespace '#' does not exist in the namespace '#'. Are you missing an assembly reference?

OK, so I came up with a solution.

I thought I would try removing and recreating the references, and in a nutshell, this worked. Detail:

I right clicked on Argus.Web in the solution explorer, and then Build Dependencies > Project Dependencies. I tried deselecting Argus.Domain.Office.Command, but got the error 'This dependency was added by the project system and cannot be removed'. I'm not sure why this error appears, but I therefore tried right clicking on the references in Argus.Web, and selected 'Add Reference'. In the Projects section of the window that came up I was able to deselect Argus.Domain.Office.Command, so I did this, commented out the problematic using directive, cleaned and rebuilt my solution, added the reference back (right clicking on the references in Argus.Web, and selecting 'Add Reference'), and it all works again.

I guess that the original references must have been misconfigured, but at present I can't see how this came about. I will add to this post if I work out how this happened.

Many thanks to all respondees, all comments and answers were useful.

Getting type or namespace name could not be found but everything seems ok?

This can be the result of a .Net framework version incompatibility between two projects.

It can happen in two ways:

  1. a client profile project referencing a full framework project; or
  2. an older framework version targeting a newer framework version

For example it will happen when an application is set to target the .Net 4 Client Profile framework, and the project it references targets the full .Net 4 framework.

So to make that clearer:

  • Project A targets the Client Profile framework
  • Project A references Project B
  • Project B targets the full framework

The solution in this case is to either upgrade the framework target of the application (Project A), or downgrade the target of referenced assembly (Project B). It is okay for a full framework app to reference/consume a client profile framework assembly, but not the other way round (client profile cannot reference full framework targeted assembly).

Note that you can also get this error when you create a new project in VS2012 or VS2013 (which uses .Net 4.5 as the default framework) and:

  • the referencing project(s) use .Net 4.0 (this is common when you have migrated from VS2010 to VS2012 or VS2013 and you then add a new project)

  • the referenced projects use a greater version i.e. 4.5.1 or 4.5.3 (you've re-targeted your existing projects to the latest version, but VS still creates new projects targeting v4.5, and you then reference those older projects from the new project)

The type or namespace name could not be found

See this question.

Turns out this was a client profiling issue.

PrjForm was set to ".Net Framework 4 Client Profile"
I changed it to ".Net Framework 4", and now I have a successful build.

Thanks everyone!
I guess it figures that after all that time spent searching online, I find the solution minutes after posting, I guess the trick is knowing the right question to ask..

ASP.NET web application namespace not recognized

Have you more than a project in your solution?
If so, you should add a reference between the project where you want to use your DbContext and the project that contains it.

From the official documentation:

To add a reference, right click on the References or Dependencies node in Solution Explorer and choose Add Reference
Source

Also, make sure that the project that contains the DbContext is being compiled.



Related Topics



Leave a reply



Submit