[c#] Namespace not recognized (even though it is there)

I am getting this error:

The type or namespace name 'AutoMapper' could not be found (are you missing a using directive or an assembly reference?)

The funny thing is that I have that reference in my project already:

And this is my code:

using System.Collections.Generic;
using DataContract;
using SelectorDAL;
using AutoMapper;

namespace SpecimenSelect
{
    public class SpecimenSelect : ISpecimenSelect
    {
        public SpecimenSelect()
        {
            SetupMaps();
        }

        private static void SetupMaps()
        {
            Mapper.CreateMap<SpecimenDetail, SpecimenDetailContract>();
        }

The other weird thing is that I have two other projects in my solution that both use AutoMapper and are referencing the exact same AutoMapper.dll file. They both work perfectly fine.

Here is a screen shot of one:

and here is that code (that compiles fine):

using System.Collections.Generic;
using AutoMapper;
using DataContract;
using SelectorDAL;

namespace PatientSelect
{

    public class PatientSelect : IPatientSelect
    {
        public PatientSelect()
        {
            SetupMaps();
        }

        private void SetupMaps()
        {
            Mapper.CreateMap<Patient, PatientContract>();
            Mapper.CreateMap<OrderedTest, OrderedTestsContract>();
            Mapper.CreateMap<Gender, GenderContract>();
        }

Both references seem to have the same data on the properties page.

What am I missing?

I tried:

1. Restarting Visual Studio
2. Referencing without a using statement (ie AutoMapper.Mapper.CreateMap)
3. Clean and Rebuild

Any other ideas?

In my case removing/adding that assembly worked.

Let me ask a stupid question: Could there be two automapper.dll files? One with an AutoMapper namespace and one without? Confirm the paths in both projects.

I also noticed that the order of the using commands is different. It shouldn't matter, but have you tried to shuffle them?

Crazy. I know.

Tried all options here. Restarting, cleaning, manually checking in generated DLLs (this is invaluable to understanding if it's actually yourself that messed up).

I got it to work by setting the Verbosity of MSBuild to "Detailed" in Options.

This has to be the simplest solution if all the other answers does not help you

I was searching for what's wrong with my setup among the answers, Tried all of them - none worked, Then I realized Visual Studio 2018 was developed by Microsoft. So I did what most people do,

Restarted Visual Studio And It worked

I've had a similar issue, that took a bit to troubleshoot, so I thought to share it:

The namespace that could not be resolved in my case was Company.Project.Common.Models.EF. I had added a file in a new Company.Project.BusinessLogic.Common namespace.

The majority of the files were having a

using Company.Project;

And then referencing the models as Common.Models.EF. All the files that also had a

using Company.Project.BusinessLogic;

Were failing as VS could not determine which namespace to use.

The solution has been to change the second namespace to Company.Project.BusinessLogic.CommonServices

I was working on Xamarin project and as always, deleting obj folder and rebuilding solved my issue, the namespace my VS was not recognizing was a code in my own project BTW

Acknowledging this as an older post but still figured I'd add this suggestion to the list of responses since I hadn't seen it mentioned.

If the unresolved reference exists within context of another Project in the Solution:

Right-click the Project having the problem, select Build Dependencies --> Project Dependencies and ensure the desired Project is selected for reference.

I had the same issue as described in the post however none of the suggested manners for resolution worked. I'd never seen such a quirk in VS before (running VS 2019 at present)

I checked for potential namespace issues and a plethora of the more obvious causes and nothing made sense. Intellisense even acknowledged the existence of the other Project and suggested to a the using statement but even after having added the using reference; VS 2019 still wouldn't acknowledge the other project.

Forcing the dependency in the manner described resolved the issue.

Restarting Visual Studio 2019 - that did it.

The question has already been awarded, but there are additional details not yet described that need to be checked.

I too was having this behavior, where project B was referenced in project A, but the namespace of project B was not recognized in project A. After some digging, I found my path was too long. By reducing the path of the projects (both A and B) the references became visible and available.

I tested this theory by creating project C at a much lesser path depth. I referenced project C in project A. The references worked correctly as expected. I then removed project C from the solution, merely moved project C to a deep path, the same as project B, and added project C back to the solution, and tried to compile. I then had no visibility to project C objects any longer.

I faced similar problem of namespace/method not being found during execution although it was fine during compilation, and the reason for this appears to be that the assembly I was referencing was deployed to GAC and since then was changed, so when I referenced the assembly in Visual Studion it was using the most recent one, but during runtime the version fro GAC had been used.

I resolved this issue by right clicking on the folder containing the files and choosing Exclude From Project and then right clicking again and selecting Include In Project (you first have to enable Show All Files to make the excluded folder visible)

In my case i had copied a classlibrary, and not changed the "Assembly Name" in the project properties, so one DLL was overwriting the other...

This happened to me in Visual Studio 2019. For me, I was trying to reference another project in my solution. Here are the steps I took in case it helps anyone else:

1. Ensured the project I wanted to reference was listed under References
2. Ensured both projects were using the correct version of .NET Framework
3. Built the project (clicked green "Start" arrow)

I was confused because I was still getting the error after steps 1 and 2, but building the project seemed to resolve it.

I have a similar problem with references not being recognized in VS2010 and the answers herein were not able to correct it.

The problem in my solution was related to the extension of the path where the project referenced was located. As I am working with SVN, I made a branch of a repository to do some testing and that branch increased two levels in path structure, so the path became too long to be usable in windows. This did not throw any error but did not recognize the namespace of the project reference. When I correct the location of the project to have a smaller path everything went fine.

In my case, the referenced dll was build in higher version of .Net Framework. After I added the reference, I could use it. But as soon as I did a build, the 'missing reference' error will pop up. I refresh the dll the error will go but it would never build. This post made me check the framework version and thus I could resolve it by building the referenced project in same version.

Perhaps the project's type table is in an incorrect state. I would try to remove/add the reference and if that didn't work, create another project, import my code, and see if that works.

I ran into this while using VS 2005, one would expect MS to have fixed that particular problem by now though..

If your class does not compile, even if it is in the project check these:

1. whether class name is exactly the same
2. whether name space is exactly the same
3. whether class properties show build action = compile

This question has already been answered for the original poster, but in case someone encounters this in an MS-Test project:

from within Visual Studio, click the Test menu -> Test Settings -> Default Processor Architecture and ensure that the architecture matches that of the other assembly that you're referencing. If the other assembly is x64 and your test settings are x86, you may experience the symptoms that the original poster had.

In my case I got the error only in VS 2015. When opening the project in VS 2017 the error was gone.