El nombre no existe en el error de espacio de nombres en XAML

Usando VS2012 trabajando en una aplicación VB.NET WPF. Tengo una sencilla aplicación tutorial MusicPlayer que estoy usando para aprender WPF. Estoy convirtiendo una versión C # del tutorial a VB.NET paso a paso.

Tiene 2 clases en la aplicación que están bajo el mismo espacio de nombres. Puedo hacer referencia al espacio de nombres en XAML pero cuando trato de hacer referencia al objeto de clase en XAML obtengo un error y no puedo compilar.

Lo extraño es que IntelliSense funciona bien al hacer referencia al espacio de nombres a través de la etiqueta xmlns: c = y también al escribir el objeto de clase usando <c: Pero el objeto está subrayado y se generan errores al intentar construir o trabajar en el diseñador.

Los archivos de clase .vb están en una carpeta llamada \ Controls. El espacio de nombres raíz del proyecto principal se deja en blanco intencionalmente. La clase está codificada así ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

El xaml se ve así

(espacio de nombres definido en la <Window >etiqueta

xmlns:c="clr-namespace:MusicPlayer.Controls"

(objeto definido en a <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(aparece el error) El nombre "UpdatingMediaElement" no existe en el espacio de nombres "clr-namespace: MusicPlayer.Controls".

¿No está seguro de qué está mal o cómo solucionarlo?

Cuando esté escribiendo su código wpf y VS diga que "El nombre ABCDE no existe en el espacio de nombres clr-namespace: ABC". Pero puede construir totalmente su proyecto con éxito, solo hay un pequeño inconveniente porque no puede ver el diseño de la interfaz de usuario (o simplemente quiere limpiar el código).

Intenta hacer esto:

• En VS, haga clic derecho en su Solución -> Propiedades -> Propiedades de configuración

• Se abre un nuevo cuadro de diálogo, intente cambiar las configuraciones del proyecto de Depurar a Liberar o viceversa.

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

Si el ensamblado es diferente del espacio de nombres en el que está contenida su clase, debe especificarlo explícitamente.

ex:-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

He visto que este problema desaparece al borrar la memoria caché de Xaml Design Shadow. Tuve el problema con Visual Studio 2015 Update 1.

En Visual Studio 2015, la caché se encuentra aquí:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

Proceso:

1. Haga clic derecho en la solución en el Explorador de soluciones y elija "Solución limpia"
2. Apagar Visual Studio
3. Eliminar la carpeta ShadowCache
4. Reabrió el proyecto de Visual Studio
5. Reconstruir la solución.

Y voila no más errores de espacio de nombres.

En mi caso fue por otros errores de compilación . Cuando se han resuelto otros errores, este error aparentemente relacionado también se eliminó de la lista. Especialmente los errores al final de la lista de errores y en las páginas que ha cambiado recientemente.

Por lo tanto, no preste atención a este error directamente y concéntrese en otros errores al principio.

Intente cambiar la plataforma de compilación de destino a x86 y compile el proyecto.

Noté a través de Subversion que aparentemente cambié el objetivo de la plataforma de compilación del proyecto a x64. Este fue el único cambio que hice. Después de hacer ese cambio, el código estuvo funcionando por un corto tiempo antes de comenzar a mostrar el mismo error que usted experimentó. Cambié el objetivo de la plataforma a x86 para probar y de repente mi diseñador estaba trabajando nuevamente. Posteriormente, lo cambié a x64 y el problema desapareció por completo. Sospecho que el diseñador construye algún tipo de código almacenado en caché en x32 y cambiar la plataforma de compilación x64 lo rompe cuando realiza cambios de código.

No sé si esto ayudará a alguien más

Soy nuevo en WPF y todavía soy un novato en VB.net, así que estaba asumiendo que este error estaba siendo causado por hacer una cumbre tonta ... ¡supongo que realmente lo era! Me las arreglé para deshacerme de él moviendo mi proyecto de una unidad compartida a una de mis unidades locales. El error desapareció, el proyecto se compila perfectamente sin problemas adicionales, todavía. Parece que VS2015 todavía tiene problemas con proyectos realizados en un disco compartido.

Quizás otra solución para cuando el proyecto se compila pero se muestra el error XAML:

1. En la solución explore, en el nodo del proyecto que contiene el xaml
2. Haga clic derecho en el proyecto y elija 'Descargar proyecto'
3. Haga clic con el botón derecho en el proyecto y elija 'Recargar proyecto'. Asegúrese de que su proyecto aún se elija como "proyecto de inicio". Si no :
4. Haga clic derecho en el proyecto y elija 'Establecer como proyecto de inicio'

No es necesario reconstruir o cerrar el estudio visual.

Jesús ... Esto sigue siendo un problema cinco años después en Visual Studio 2017. Como soy nuevo en WPF, estaba seguro de que el problema era yo, pero no, todo se compiló y funcionó correctamente.

Intenté reconstruir, limpiar y reconstruir, cambiar entre salida x86 / x64, reiniciar Windows, limpiar la carpeta ShadowCache, agregar "; assembling = {mi nombre de ensamblado principal}" a la declaración del espacio de nombres XML, ¡nada funcionó! Lo único que hizo:

Ponga mi clase estática de Comandos (en mi caso, el trato consistía en hacer que el diseño descubriera mis Comandos WPF) en su ensamblaje separado y cambiar el nombre del ensamblado a ese en su lugar.

Tuve el mismo problema y, en mi caso, la Vista de diseño de marcado me pidió que reconstruyera la solución y no me mostró el diseño del formulario con este mensaje: Design view is unavailable for x64 and ARM target platformso Build the Project to update Design view.

No se resuelve reconstruyendo la solución (ni la vista de diseño ni el error "El nombre no existe en el espacio de nombres")

Creo que fue porque había jugado con la configuración en Solución -> Propiedades> Propiedades de configuración

Finalmente resolví el problema con 2 trabajos:

1. Marcando todas las casillas de verificación en la columna Construir de la página: Solución -> Propiedades -> Propiedades de configuración
2. Cambiando las configuraciones de la solución de Debug a Release o viceversa.

Creo que es un error en Visual Studio2012 Update 2.

El mismo problema afecta a Visual Studios 2013, Service Pack 4. También lo probé con Visual Studios 2015 Preview con los mismos resultados.

Es solo una limitación del visualizador WPF que el equipo de Visual Studios no ha solucionado. Como prueba, construir en modo x86 habilita el visualizador y construir en modo x64 lo deshabilita.

Curiosamente, intellisense funciona para Visual Studios 2013, Service Pack 4.

Recientemente tuve este problema al usar VS 2015 Update 3 para mi proyecto WPF en .NET 4.6.2. La copia de mi proyecto estaba en una carpeta de red. , la moví localmente y eso resolvió el problema.

Esto puede resolver otro tipo de problemas, ya que parece que a VS 2015 no le gustan las rutas de red. Otro problema que es un gran problema para ellos es sincronizar repositorios git si mi proyecto está en una ruta de red, también resuelto moviéndolo localmente.

Parece que este problema puede resolverse mediante una variedad de "trucos".

En mi caso, había estado construyendo / reconstruyendo / limpiando toda la solución, en lugar de solo el proyecto en el que estaba trabajando dentro de la solución. Una vez que hice clic en "Construir [mi proyecto]", el mensaje de error desapareció.

Intente verificar sus referencias de ensamblaje. Si tiene un signo de exclamación amarillo en las referencias del proyecto, hay un problema allí y obtendrá todo tipo de errores.

Si sabe que la referencia del proyecto es correcta, verifique el Marco de destino. Por ejemplo, tener un proyecto usando el marco 4.5 hace referencia a un proyecto con el marco 4.5.2 no es una buena combinación.

La solución para mí fue desbloquear las DLL de ensamblado. Los mensajes de error que recibe no indican esto, pero el diseñador XAML se niega a cargar lo que llama ensambles "sandboxed". Puede ver esto en la ventana de salida cuando compila. Las DLL se bloquean si se descargan de Internet. Para desbloquear las DLL de ensamblado de terceros:

1. Haga clic derecho en el archivo DLL en el Explorador de Windows y seleccione Propiedades.
2. En la parte inferior de la pestaña General, haga clic en el botón o casilla de verificación "Desbloquear".

Nota: solo desbloquee archivos DLL si está seguro de que son seguros.

En mi caso, el control de usuario se agregó al proyecto principal. Probé varias soluciones anteriores en vano. O obtendría un marcado no válido pero la solución se compilaría y funcionaría, o agregaría los xmlns: c = "clr-namespace: MyProject; assembly = MyProject" y luego el marcado se mostraría, pero obtendría un error de compilación que la etiqueta no existe en el espacio de nombres XML.

Finalmente, agregué un nuevo proyecto de Biblioteca de Control de Usuario de WPF a la solución y moví mi control de usuario del proyecto principal a ese. Se agregó la referencia y se cambió el ensamblado para que apunte a la nueva biblioteca y finalmente el marcado funcionó y el proyecto se compiló sin error.

Revisé todas las respuestas y ninguna me ayudó. Finalmente pude resolverlo yo solo, así que presentar la respuesta ya que podría ayudar a otros.

En mi caso, la solución tenía dos proyectos, uno que contenía los modelos (digamos que el nombre del proyecto y del ensamblaje era Modelos ) y otro que contenía las vistas y los modelos de vista (según nuestra convención: el proyecto, el nombre del ensamblaje y el espacio de nombres predeterminado eran Modelos. Monitor ) . El proyecto Models.Monitor se refirió a Models.

En el proyecto Models.Monitor, en uno de los xaml incluí el siguiente espacio de nombres: xmlns: monitor = "clr-namespace: Models.Monitor"

Sospecho que MsBuild y Visual Studio estaban cometiendo un error al intentar encontrar un tipo de 'Monitor' en el ensamblaje 'Modelos' . Para resolver probé lo siguiente:

1. xmlns: monitor = "clr-namespace: Models.Monitor; assembly =" - que es válido si el espacio de nombres está en el mismo ensamblaje que por https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) .aspx
2. También probé la declaración explícita de espacio de nombres: xmlns: monitor = "clr-namespace: Models.Monitor; assembly = Models.Monitor"

Ninguno de los anteriores funcionó.

Finalmente me di por vencido y, mientras trabajaba, moví el UserControl que intentaba usar a otro espacio de nombres: 'ModelsMonitor' . Pude compilar bien después de eso.

En mi caso, tenía un espacio de nombres y una clase escritos exactamente igual, por ejemplo, uno de mis espacios de nombres era

firstDepth.secondDepth.Fubar

que contiene sus propias clases (por ejemplo, firstDepth.secondDepth.Fubar.someclass)

pero también tenía una clase ' Fubar ' en el espacio de nombres

firstDepth.secondDepth

que textualmente se resuelve igual que el espacio de nombres Fubar anterior.

No hagas esto

En mi caso, el problema se debió a algunos archivos fantasmas en el directorio obj del proyecto. Lo siguiente solucionó el problema para mí:

• Proyecto limpio
• Salir VS
• rm -rf / obj / *
• Invocar VS y reconstruir

¡También estoy teniendo muchos problemas con este! Intellisense me ayuda a completar el espacio de nombres y todo, pero el compilador llora. He intentado todo lo que encontré en este y otros hilos. Sin embargo, en mi caso, lo que ayudó al final fue escribir algo como esto:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

Dejando el nombre del ensamblaje vacío. No tengo idea de por qué. Pero fue mencionado aquí. Debo agregar que estoy desarrollando un ensamblado, por lo que el atributo de ensamblado podría tener sentido. Pero ingresar el nombre de la asamblea no funcionó. Tan raro.

VB.NET no agrega automáticamente la información del espacio de nombres en función de la estructura de carpetas como lo hace en C #. Creo que estoy pasando por el mismo tutorial que tú (Teach Yourself WPF in 24 Hours), y estoy haciendo la misma conversión a VB.

Descubrí que tienes que agregar manualmente la información del espacio de nombres tanto a la clase XAML como al código XAML.VB para poder usar los espacios de nombres como se describe en el libro. Incluso entonces, VB no asigna automáticamente el espacio de nombres a la Asamblea como lo hace en VB.

Hay otro artículo aquí que muestra cómo incluir esto en las plantillas de su proyecto para que genere la información del espacio de nombres automáticamente: agregue automáticamente el espacio de nombres al agregar un nuevo elemento

En la página de propiedades de la solución, verifique la plataforma del ensamblado que contiene "UpdatingMediaElement" y los conjuntos que contienen cualquiera de las superclases e interfaces desde las cuales se implementa "UpdatingMediaElement". Parece que la plataforma de todos estos ensamblajes debe ser "AnyCPU".

Otra posible causa: un evento posterior a la compilación está eliminando la DLL del proyecto de la carpeta de compilación.

Para aclarar: el diseñador de WPF puede informar "El nombre XXX no existe en el espacio de nombres ...", incluso cuando el nombre sí existe en el espacio de nombres y el proyecto se compila y ejecuta bien si un evento posterior a la compilación elimina la DLL del proyecto de la carpeta de compilación (bin \ Debug, bin \ Release, etc.). Tengo experiencia personal con esto en Visual Studio 2015.

Ok, desafortunadamente ninguno de estos consejos me funcionó. Finalmente pude resolver el problema. Parece que Visual Studio no funciona bien con las unidades de red. Resolví este problema moviendo el proyecto de la unidad compartida a mi local y recompilado. No mas errores.

Agregando a la pila.

El mío era el nombre del ensamblado de la aplicación WPF, era el mismo nombre del ensamblado que un dll referenciado. Así que asegúrese de no tener nombres de ensamblaje duplicados en ninguno de sus proyectos.

Tenía la solución almacenada en un recurso compartido de red y cada vez que la abría recibía la advertencia sobre fuentes no confiables. Lo moví a una unidad local y el error "el espacio de nombres no existe" también desapareció.

También intente hacer clic derecho en su proyecto-> propiedades y cambiar el objetivo de la plataforma a cualquier CPU y reconstruir, luego funcionará. Esto funciono para mi

Este problema también puede ser causado si el ensamblado al que hace referencia no está realmente construido. Por ejemplo, si su xaml está en Assembly1 y está haciendo referencia a una clase también en Assembly1, pero ese ensamblado tiene errores y no se está creando, se mostrará este error.

Me siento tonto al respecto, pero en mi caso estaba desgarrando un control de usuario y como resultado tuve todo tipo de errores en las clases relacionadas. Mientras intentaba solucionarlos, comencé con los errores en cuestión, sin darme cuenta de que xaml se basa en ensamblajes integrados para encontrar estas referencias (a diferencia del código c # / vb que puede solucionarlo incluso antes de compilar).

Agregué el ensamblado como un proyecto, primero eliminé el ddl que se agregó específicamente a las referencias al dll, eso lo hizo.

Tengo este problema todo el tiempo. Mis vistas están en un proyecto de la Biblioteca de control personalizado de WPF (una variante de la Biblioteca de clases). Puedo hacer referencia a ensamblados preconstruidos, pero no puedo hacer referencia a ningún código en otro proyecto de la misma solución. Tan pronto como muevo el código al mismo proyecto que el xaml, se reconoce.

En mi caso, este problema ocurrirá cuando la arquitectura del programa wpf no sea exactamente igual a la dependencia. Supongamos que tiene una dependencia que es x64, y otra es AnyCPU. Luego, si elige x64, el tipo en AnyCPU dll "no existe", de lo contrario, el tipo en x64 dll "no existe". Simplemente no puedes emularlos a ambos.