el nombre no existe en el espacio de nombres clr-namespace

Tengo una pequeña aplicación WPF que solía comstackr muy bien, pero ya no es así. Realmente no puedo decir en qué punto dejó de construir. Funcionó bien un día, y al siguiente no.

Aquí está la estructura del proyecto:
enter image description here
No hay otros proyectos o referencias externas que no sean dll .net estándar.

Aquí está el control del usuario donde se originó el problema:

      

Y aquí está el error que recibo: http://i48.tinypic.com/5u1u8w.png

Tenga en cuenta que este no es solo el único archivo en la captura de pantalla, sino todas las referencias que agrego de manera similar en xaml en todos los archivos de control / ventana del usuario en este proyecto.

Entonces el archivo está allí, el espacio de nombres en el archivo es correcto, el espacio de nombres / nombre de clase en el archivo xaml es (a mi entender) correcto. Me pongo intellisense cuando escribo el xaml para que encuentre los archivos entonces correctos, pero no cuando comstack.

La solución más común para esto en otras publicaciones ha sido la versión de .NET Framework. Actualmente está configurado en .Net Framework 4 para mi proyecto principal y de prueba. La versión completa no es el perfil del cliente.

Esto es lo que creo que arruiné: en el administrador de configuración, ambos proyectos tienen su Plataforma configurada en Cualquier CPU, pero en un momento dado al tratar de resolver esto, noté que el proyecto principal se configuró en x86 y el proyecto de prueba se configuró en Cualquiera UPC. Así que agregué Any CPU manualmente para el proyecto principal en el administrador de configuración. Sin embargo, sinceramente, no sé si hice esto correctamente o incluso si debería hacerlo. Entonces, como pregunta adicional, ¿hay alguna manera de restablecer el administrador de configuración a su estado predeterminado? ¿Esto tendrá algo que decir para el problema principal? No sé si el proyecto principal siempre estaba configurado en x86 o no, o si de alguna manera lo cambié a x86 y luego se rompió. Como mencioné este proyecto estuvo comstackndo bien por un tiempo.

¿Alguna sugerencia? Voy a responder preguntas más detalladas sobre el código o lo que sea que les pregunte en lugar de divagar aquí 🙂

Cada vez que me sucedió acabo de reiniciar Visual Studio, reconstruí la solución y funcionó bien … no puedo decir por qué

Además del mensaje “no existe en el espacio de nombres”, también recibí un mensaje del diseñador que decía que no podía mostrar la ventana para los destinos x64 y ARM.

Acabo de descubrir que cambiar la construcción al modo x86, hacer una solución de reconstrucción, luego volver al modo x64 y luego reconstruir de nuevo corrige los problemas [ambos].

Simplemente reconstruir la solución x64 no hizo nada.

Esto es lo que funcionó para mí en Visual Studio 2012 (Actualización 3).

  • Reiniciar Visual Studio
  • Agregue el ensamblado actual a la statement del espacio de nombres xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
  • Build -> Build Solution

Lo que encontré que ayudó (especialmente si este error ocurre en App.xaml ) es comentar las referencias que le dan problemas, reconstruir, luego descomentar. Creo que lo que hace esto permite que todo el proyecto realmente se construya en lugar de detener la comstackción en el momento del error.

Por lo que puedo deducir, la aplicación está tratando de comstackr los archivos en un orden determinado, por lo que cuando App.xaml o presumiblemente cualquier otro archivo de clase App.xaml errores en una referencia, el archivo que está causando el error no se ha comstackdo correctamente, por lo tanto por qué no encuentra el archivo en ese espacio de nombres.

Reconstruya su solución (a veces limpia y luego funciona mejor). Luego observe su lista de errores, desplácese hasta la parte inferior, y lo más probable es que indique un error que no le permite comstackr su ensamblado, y es muy probable que el comstackdor XAML esté usando una versión en caché del ensamblado, no la nueva que significa construir.

Tuve el problema similar. En mi caso, tuve que hacer lo siguiente

  • eliminar el marcado de referencia de xaml (en este ejemplo, )
  • construir la clase (en este archivo de ejemplo que contiene la clase HistoryViewModel )
  • Una vez que esté construido, agregue el marcado de referencia en xaml
  • construir de nuevo

El método anterior funcionó para mí.

Lo que funcionó para mí: – Cambiar la configuración de la solución de Debug a Release – Cambiar la configuración de Release a Debug

Ninguna de las soluciones funcionó para mí. Lo arreglé de esta manera:

  • Elimina el dll de la biblioteca de las referencias
  • Descargue el código fuente de la biblioteca (en lugar de solo el archivo dll)
  • Construya el proyecto de la biblioteca para obtener un nuevo archivo dll
  • Agregue el nuevo archivo dll a las referencias del proyecto principal

Tenía este problema dando vueltas en círculos perdiendo unas horas. Moví un dll de control de usuario por separado en el proyecto, por lo que se compiló en el proyecto y no se hizo referencia a un dll. Esto rompió todo el proyecto, así que revisé meticulosamente todos los espacios de nombres, rutas y nombres de archivos. Intentó eliminar archivos obj, cambiando entre versión y depuración, entre x86 y AnyCPU. Al abrir guardando todo, recomstack todavía sin alegría.

Recuerde que antes tenía un problema similar, el error marcado en VS2013 no estaba directamente relacionado con el lugar donde tuve que modificar el XAML, pero al usar

 x:Name="myControl" 

en todos los controles, en lugar de

 Name="myControl" 

arreglado.

Aquí hay un extraño ejemplo de algo similar:

  ...  

comstackrá (VS2013).

  ...  

produce el error “tipo Ui no encontrado en Gtl.Ui.Gtl” (y le aseguro que el método del controlador existe en el código subyacente). La solución es agregar el controlador en el constructor de la clase, pero vamos a Microsoft, ¿qué sucede?

Enfrenté el mismo problema cuando intentaba llamar al espacio de nombres en xaml. estaba mostrando que la clase no está disponible en el espacio de nombres. Busqué mucho. Finalmente encontré que este problema era con VS. Estoy usando VS 2013. Intenté los siguientes pasos:

  1. Build -> Configuration Manager -> Active Solution Platform -> Cambiado a x64 y x86 y cualquier CPU.
  2. Cerré el VS y lo abrí nuevamente.
  3. Cambio

     xmlns:VM="clr-namespace:MyFirstAppViewModel" 

    a

     xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel" 

Cambié el marco de destino Mi aplicación de “.Net Framework 4.5” a “.Net Framework 4.6” ¡y funcionó!

  • x:Key="ViewModel" recomendaría Renombrar x:Key="ViewModel" tal vez haya una falla
  • y si escribe local: ¿VS le muestra HistoryViewModel ?
  • también verifique si su Class es public

Se topó con este problema hoy con Visual Studio 2017 Community Edition. Intenté todas las sugerencias aquí (restablecer VS 2017, cambiado de x64 a x32 y viceversa, etc.) y de otras fonts sin resultado. Intellisense sabe que todo está allí, pero estaba recibiendo el mismo error cada vez.

De todos modos, mi solución resultó ser muy simple … ¿no es así cuando pasaron un par de horas sobre el problema?

Básicamente, hice lo siguiente …

  1. Eliminar el código ofensivo del archivo xaml (solo 3 líneas en mi caso)
  2. Construye un proyecto para que obtengas una construcción exitosa
  3. En este punto, el diseño apareció mágicamente en la ventana del diseñador, lo que fue una buena señal.
  4. Reinserted el código que eliminé en el punto 1. incluyendo el xmlns: entrada
  5. En este punto, no deberías obtener ningún garabato azul … con suerte
  6. Construye el proyecto de nuevo

Parece que al obtener una comstackción exitosa, debe reiniciar ‘algo’ dentro de VS y / o el ensamblado. Una vez que tenga una comstackción exitosa intente insertar su código nuevamente.

Espero que esto ayude a alguien 🙂

Simplemente ejecuta el análisis de código desde el menú Comstackr

Este es un problema recurrente para mí. Una de las veces que encontré la solución mirando en la pestaña Advertencia . Era un problema de versión de .NET framework y decía lo siguiente:

Advertencia 9 La referencia primaria “myDll” no se pudo resolver porque se creó con el marco “.NETFramework, Version = v4.5.2”. Esta es una versión más alta que el marco actualmente orientado “.NETFramework, Version = v4.0”.

Hay un problema con su almacenamiento en búfer de los diseños de los objetos. Si algo cambia de nombre o se mueve, se pierde. Lo que generalmente funciona para mí es crear una clase completamente nueva y copiar todo el código antiguo, ponerlo en funcionamiento en la nueva clase y luego eliminar la clase original. A veces, después de que se activa y se ejecuta con el nuevo nombre de clase, puede intentar cambiarle el nombre al nombre original (pero normalmente no)

Estaba usando xmlns: local = “using: MyRootNamespace.ChildNamespace” en el encabezado de .xaml, y lo convertí en xmlns: local = “clr-namespace: MyRootNamespace.ChildNamespace” … bueno, dejé que intellisense do el trabajo, y funcionó.

El problema es que cuando crea el destino x86, la ruta de salida para el proyecto en particular se establece en bin \ x86 \ Debug. Parece que a la mezcla Expression no le gusta esto en absoluto. Parece que solo le interesa lo que está en bin \ Debug.

Si cambió su (s) ruta (s) de salida para el proyecto x86 a bin \ debug, por ejemplo, entonces estoy seguro de que encontrará que funcionará. Bueno, funciona para mí de todos modos 🙂

El marco de destino del archivo .dll que agregue debe ser el mismo que el marco de destino de su aplicación.

Este error generalmente ocurre cuando el proyecto no se compiló correctamente durante la última comstackción.

Paso-1) Primero elimine todo el código que causa el error del archivo XAML o .cs y cree e inicie el proyecto presionando F5.

Paso-2) Agregue agregue su error causando el código en XAML uno por uno.

Descubrí que al ejecutar el comando “Ejecutar análisis de código”, reconstruyo todo y casi siempre soluciona el problema (haga clic con el botón derecho en Proyecto> Analizar> Ejecutar análisis de código). Esto generalmente también vuelve a generar los archivos de recursos para que se puedan encontrar cadenas, etc.