c# - que - un espacio de nombres no puede contener directamente miembros como campos o métodos

Espacio de nombres no reconocido(aunque esté allí)

Question

Estoy recibiendo este error:

No se pudo encontrar el tipo o el nombre del espacio de nombres ''AutoMapper'' (¿falta una directiva using o una referencia de ensamblado?)

Lo curioso es que ya tengo esa referencia en mi proyecto:

Y este es mi código:

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>();
}

La otra cosa extraña es que tengo dos proyectos más en mi solución que usan AutoMapper y hacen referencia al mismo archivo AutoMapper.dll exacto. Ambos funcionan perfectamente bien.

Aquí hay una captura de pantalla de uno:

y aquí está ese código (que compila bien):

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>();
}

Ambas referencias parecen tener los mismos datos en la página de propiedades.

¿Qué me estoy perdiendo?

Lo intenté:

1. Reiniciar Visual Studio
2. AutoMapper.Mapper.CreateMap referencia sin una instrucción using (es decir, AutoMapper.Mapper.CreateMap )
3. Limpiar y reconstruir

¿Alguna otra idea?

Answer 1

En mi caso, el dll referenciado fue compilado en la versión superior de .Net Framework. Después de agregar la referencia, podría usarla. Pero tan pronto como hice una compilación, aparecerá el error de "referencia faltante". Actualizo el dll, el error irá, pero nunca se compilará. Este post me hizo verificar la versión del framework y así pude resolverlo construyendo el proyecto referenciado en la misma versión.

Answer 2

En mi caso, había copiado una biblioteca de clases, y no había cambiado el "Nombre del ensamblado" en las propiedades del proyecto, por lo que una DLL sobrescribía a la otra ...

Answer 3

La pregunta ya ha sido adjudicada, pero hay detalles adicionales aún no descritos que deben verificarse.

Yo también estaba teniendo este comportamiento, donde se hizo referencia al proyecto B en el proyecto A, pero el espacio de nombres del proyecto B no se reconoció en el proyecto A. Después de algunas excavaciones, encontré que mi camino era demasiado largo. Al reducir la ruta de los proyectos (tanto A como B) las referencias se hicieron visibles y disponibles.

Probé esta teoría creando el proyecto C a una profundidad de ruta mucho menor. Hice referencia al proyecto C en el proyecto A. Las referencias funcionaron correctamente como se esperaba. Luego eliminé el proyecto C de la solución, simplemente moví el proyecto C a una ruta profunda, al igual que el proyecto B, y agregué el proyecto C a la solución y traté de compilar. Entonces no tenía visibilidad para proyectar objetos C por más tiempo.

Answer 4

Me enfrenté a un problema similar de espacio de nombres / método que no se encontró durante la ejecución aunque estuvo bien durante la compilación, y el motivo parece ser que el ensamblado al que hacía referencia se implementó en GAC y luego se modificó, por lo que cuando hice referencia al ensamblado en Visual Studion estaba usando el más reciente, pero durante el tiempo de ejecución se había usado la versión de fro GAC.

Answer 5

Pregunta estúpida: ¿Podría haber dos automapper.dll? ¿Uno con un espacio de nombres AutoMapper y otro sin? Confirme las rutas en ambos proyectos.

Estado allí...

También se ha notado que el orden de uso es diferente. No debería importar, pero ¿has intentado mezclarlos?

Answer 6

Quizás la tabla de tipos del proyecto está en un estado incorrecto. Intentaría eliminar / agregar la referencia y, si eso no funcionaba, crear otro proyecto, importar mi código y ver si funcionaba.

Me encontré con esto al usar VS 2005, uno esperaría que MS haya solucionado ese problema en particular por ahora ...

Answer 7

Resolví este problema haciendo clic con el botón derecho en la carpeta que contiene los archivos y seleccionando Excluir del proyecto y luego haciendo clic derecho nuevamente y seleccionando Incluir en proyecto

Answer 8

Si su clase no compila, incluso si está en el proyecto, verifique esto:

1. si el nombre de la clase es exactamente el mismo
2. si el espacio de nombre es exactamente el mismo
3. si las propiedades de clase muestran acción de compilación = compilar

Answer 9

Tengo un problema similar con las referencias que no se reconocen en VS2010 y las respuestas aquí no fueron capaces de corregirlo.

El problema en mi solución estaba relacionado con la extensión de la ruta donde estaba ubicado el proyecto al que se hace referencia. Como estoy trabajando con SVN, hice una rama de un repositorio para hacer algunas pruebas y esa rama aumentó dos niveles en la estructura de la ruta, por lo que la ruta se hizo demasiado larga para ser utilizable en Windows. Esto no arrojó ningún error, pero no reconoció el espacio de nombres de la referencia del proyecto. Cuando corrijo la ubicación del proyecto para tener un camino más pequeño todo fue bien.

Answer 10

Verifique que su proyecto no esté configurado para usar .NET Framework 4 Client Profile.

Puede verificar / cambiar esto haciendo clic con el botón derecho en su proyecto (no en la solución), seleccione Propiedades -> Aplicación -> Marco de destino . El marco objetivo es un menú desplegable en esa página.

Este es un problema en Visual Studio (incluso llegaría a llamarlo un error). AutoMapper requiere conjuntos que están excluidos de .NET Framework 4 Client Profile. Como su proyecto está usando esa versión del framework, se rompe.

Un error similar se propagará al proceso de compilación cuando la versión de .NET Framework para el proyecto al que se refiere es más alta que el proyecto que hace la referencia. es decir, un proyecto orientado a 4.5 que hace referencia a un proyecto que apunta a 4.5.1 le dará el mismo error.

Es necesario que haya un mensaje de error mejor cuando esto ocurra porque no hay una explicación racional de por qué no se compilará, ya que el mensaje de error le indica que haga referencia a un ensamblaje al que ha hecho referencia claramente.