el nombre <…> no existe en el espacio de nombres clr-namespace <…>

Tengo una pequeña aplicación WPF que solía compilarse bien, pero ya no lo es. Realmente no puedo decir en qué momento dejó de construirse. Simplemente funcionó bien un día y al siguiente no.

Aquí está la estructura del proyecto:

No hay otros proyectos o referencias externas que no sean las DLL de .net estándar.

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

<UserControl x:Class="TimeRecorder.HistoryUserControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:local="clr-namespace:TimeRecorder.ViewModel"
         xmlns:framework="clr-namespace:TimeRecorder.Framework"
         mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
    <local:HistoryViewModel x:Key="ViewModel"/>
    <framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">

Y aquí está el error que obtengo:

Tenga en cuenta que este no es solo el archivo en la captura de pantalla, sino todas las referencias que agrego de manera similar en xaml en todos los archivos de ventana / control de 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. Obtengo intellisense cuando escribo el xaml para que encuentre los archivos bien, pero no cuando se compila.

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

Esto es lo que creo que me equivoqué: en el administrador de configuración, ambos proyectos tienen su Plataforma configurada en Cualquier CPU, pero en un momento cuando intentaba resolver esto, noté que el proyecto principal estaba configurado en x86 y el proyecto de prueba estaba configurado en Cualquiera UPC. Así que agregué Cualquier CPU manualmente para el proyecto principal en el administrador de configuración. Sin embargo, honestamente, 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? ¿Tendrá esto algo que decir sobre el problema principal? No sé si el proyecto principal siempre se configuró en x86 o no o si de alguna manera lo cambié a x86 y luego se rompió. Como se mencionó, este proyecto se compiló bien por un tiempo.

Cada vez que me sucedió, reinicié 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 de que no podía mostrar la ventana para los objetivos x64 y ARM.

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

Simplemente reconstruir la solución x64 no hizo nada.

Lo que encontré que ayudó (especialmente si se produce este error en App.xaml) es comentar las referencias que le causan problemas, reconstruir y luego descomentar. Yo creo que lo que esto hace es permite que todo el proyecto de construcción de realidad en lugar de detener la acumulación en el error.

Por lo que puedo recopilar, la aplicación está tratando de compilar los archivos en un orden determinado, por lo que cuando App.xamlo presumiblemente cualquier otro error de archivo de clase en una referencia, el archivo que está causando el error no se ha compilado correctamente, por lo tanto, por qué no lo hace. No encuentro el archivo en ese espacio de nombres.

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

• Reinicie Visual Studio
• Agregar ensamblado actual a la declaración del espacio de nombres xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
• Build -> Build Solution

Reconstruya su solución (a veces limpiar y luego construir funciona mejor). Luego, mire su lista de errores, desplácese hasta el final, y lo más probable es que indique un error que no permite que su ensamblado se compile, y el compilador XAML probablemente esté usando una versión en caché del ensamblado, no la nueva que usted significa construir.

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

• eliminar el marcado de referencia de xaml (en este ejemplo, <local:HistoryViewModel x:Key="ViewModel"/>)
• construir la clase (en este archivo de ejemplo que contiene la HistoryViewModelclase)
• 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

Encontré este problema hoy con Visual Studio 2017 Community Edition. Probé todas las sugerencias aquí (restablecer VS 2017, cambiar de x64 a x32 y viceversa, etc.) y de otras fuentes en vano. Intellisense sabe que todo está ahí, pero recibía el mismo error cada vez.

De todos modos, mi solución resultó ser muy simple ... ¿no es así siempre cuando has pasado un par de horas en el problema?

Básicamente, hice lo siguiente ...

1. Eliminar el código ofensivo del archivo xaml (solo 3 líneas en mi caso)
2. Construya el proyecto para obtener una construcción exitosa
3. En este punto, el diseño apareció mágicamente en la ventana del diseñador, ¡lo cual fue una buena señal!
4. Reinserté el código que eliminé en el punto 1, incluida la entrada xmlns:
5. En este punto, no debería tener ningún garabato azul ... con suerte
6. Vuelva a construir el proyecto

Parece que al obtener una compilación exitosa, debe restablecer 'algo' dentro de VS y / o el ensamblaje. Una vez que tenga una compilación exitosa, intente insertar su código nuevamente.

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

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

Tuve este problema dando vueltas en círculos perdiendo algunas horas. Moví una dll de control de usuario separada al proyecto para que se compilara en el proyecto y no se hiciera referencia a una 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. Apertura salvando todo, recompilar aún sin alegría.

Recuerde haber tenido un problema similar antes, el error marcado en VS2013 no estaba directamente relacionado con dónde tenía que modificar el XAML sino usando

x:Name="myControl"

en todos los controles, en lugar de

Name="myControl"

arreglado.

Cambié Target Framework Mi aplicación de ".Net Framework 4.5" a ".Net Framework 4.6" ¡y funcionó!

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

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent">
...
</UserControl>

compilará (VS2013).

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent"
         IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>

produce el error "tipo Ui no encontrado en Gtl.Ui.Gtl" (y les 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 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. Compilación -> Administrador de configuración -> Plataforma de solución activa -> Cambiado a x64 y x86 y cualquier CPU.
2. Cerró el VS y volvió a abrir.

3. Cambio

   xmlns:VM="clr-namespace:MyFirstAppViewModel"
   

   a

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

Este error suele ocurrir cuando el proyecto no se compiló correctamente durante la última compilación.

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

Paso 2) Agregue su código de causa de error en XAML uno por uno.

• Recomendaría cambiar el nombre, x:Key="ViewModel"tal vez haya un problema técnico
• y si local:escribes, ¿VS te muestra HistoryViewModel?
• también comprueba si tu Classespublic

Simplemente ejecute el análisis de código desde el menú Compilar

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

Probé todas las soluciones en este hilo pero ninguna funcionó. Resultó ser causado por la configuración de la solución. Mi aplicación WPF se configuró para compilarse para X64 debido a algunas dependencias nativas que lo requieren, pero la configuración de la solución aún se estableció en AnyCPU para el proyecto. La creación de una nueva configuración X64 para el proyecto en el administrador de configuración de la solución permitió que el diseñador XAML finalmente reconociera mi tipo y espacio de nombres.

Antes de agregar el espacio de nombre a su archivo .xaml, asegúrese de no tener ningún error de compilación debido al código existente.

Una vez que todas las comprobaciones de compilación estén bien, reconstruya su solución e intente agregar el espacio de nombres requerido para usar su clase o propiedades.

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

Advertencia 9 La referencia principal "myDll" no se pudo resolver porque se creó en el marco ".NETFramework, Version = v4.5.2". Ésta es una versión superior a la del marco actual ".NETFramework, Version = v4.0".

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

Estaba usando xmlns: local = "using: MyRootNamespace.ChildNamespace" en el encabezado del .xaml, y lo convertí en xmlns: local = "clr-namespace: MyRootNamespace.ChildNamespace" ... bueno, simplemente dejé que intellisense lo hiciera 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 Expression blend no le gusta esto en absoluto. Parece que solo le interesa lo que hay 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.

Estaba enfrentando el mismo problema. Obtiene este error, pero aún puede construir su proyecto con éxito. El inconveniente es que no puede ver el diseño de la interfaz de usuario (o simplemente desea limpiar el código y eliminar las molestas líneas onduladas). Leer muchas publicaciones se prueban varias cosas pero seguir funciona como un encanto.

Probé esto en Visual Studio 2019:

Haga clic derecho en su Solución -> Propiedades -> Propiedades de configuración, luego cambie las configuraciones del proyecto de Debug a Release o viceversa.

Después de eso, reconstruya su solución. Puede resolver tu problema.