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


126

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?


13
Reiniciar lo visual funcionó para mí. (nunca subestimes el poder de reiniciar)
Falaque

1
Un poco de ayuda para aquellos que están luchando con esto: asegúrese de que su clase sea pública.
Borzh

Respuestas:


234

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.


44
Esto todavía sucede en Visual Studio 2015 Update 1. Su solución funcionó, ¡gracias!
Simon Smith

44
Tal vez no, pero descubrí que simplemente cambiar entre el modo de depuración y lanzamiento en la barra de herramientas funcionó independientemente.
ketura

35
Confirmado en VS 2017 versión 15.2 (26430.15) en julio de 2017. Simplemente cambió en el menú desplegable de Debug a Release, compiló y el error desapareció, cambió de nuevo y compiló y el error aún desapareció.
Tedd Hansen

77
Parece que VS17 es especialmente terco: intenté cambiar Rel / Dbg, cambiar x64 / x86, eliminar las carpetas ShadowCache, ComponentCache, Bin / Obj, todavía tienen "errores" y el diseñador no funciona para esta aplicación muy pequeña (otras aplicaciones con como 50 vistas de WPF funcionan bien). Sucedió de repente y no puede irse. Tuve este problema antes muchas veces, pero la primera vez en VS17 y ahora no puedo solucionarlo. Aún así, esta es la mejor respuesta, ya que funcionó tantas veces antes.
bokibeg

77
Me encanta cómo vuelvo a esta respuesta, y ya la he votado ... hace 2.5 años.
Mathieu Guindon,

51

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"

1
Si bien parecía haber resuelto mi problema al principio, todavía arroja el mismo error. Sin embargo, ahora ni siquiera puedo construir la solución.
Bouke

66
@bouke Limpiar la solución y reconstruirla
Vasanth Sriram

Impresionante, gracias. Eso realmente ayudó
Keith

Esto lo hizo por mi. Lo extraño es que los convertidores estaban en el mismo ensamblaje que el archivo xaml ... Pero estaban en un espacio de nombres diferente.
Jonathan Alfaro

Gracias, faltaba la asamblea.
Bagerfahrer

31

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.


77
Lamentablemente, no cambió nada, para mí. Todavía estoy lidiando con esta molestia después de casi un año entero. : /
Khale_Kitha

3
¡Gracias! Esto terminó trabajando para mí. Es triste ver que estos trucos siguen siendo necesarios en VS15
Ocab19

44
Puede usar% localappdata% \ Microsoft \ VisualStudio \ 14.0 \ Designer \ para ir inmediatamente a la carpeta correcta
Maxence

1
Tener un diseñador que solo funciona si construyes la solución es terrible. Imagine decirle a un diseñador de automóviles que construya todo el automóvil antes de ver el diseño.
Paul McCarthy

26

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.


2
Tenga en cuenta que hacer una compilación / compilación resolvió este problema para mí, a pesar de que no tenía otros errores de compilación no relacionados. Parece que las ventanas XAML no siempre conocen nuevas clases hasta que hayas compilado.
HK1

1
Este fue el mejor consejo para mí, pero como @ HK1 a veces no hay otras entradas en la lista de errores del compilador ... no hay errores en la lista pero sí otros errores. Para verlos, comente o elimine las líneas marcadas con el error del espacio de nombres, compile nuevamente y luego verá los otros errores del compilador. Modifíquelos, y las líneas antes marcadas con el error de espacio de nombres estarán bien cuando las restaure.
SERWare

Había eliminado un método en el código detrás que todavía se hacía referencia en XAML. Una vez que eliminé la referencia, este error desapareció.
YarsRevenge13

23

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.


He tenido esta repetición y puedo confirmar que esto me soluciona el problema. Puede volver a x64 después de compilarlo en x86.
teynon

Esto también funcionó para mí en VS 2012 ... después de horas de tratar de descubrir algo lógico. Gracias Tom!
Bryan Greenway

Cambiar a x86 y volver a x64 solucionó el problema aquí, así que gracias por inspirarme a probar eso. Incluso había cerrado VS, borrado bin y obj, y reconstruido, junto con otras sugerencias, y nada ayudó hasta esto.
Grault

Sí, esto también funcionó para mí en la Actualización 2 de VS2015. Sin embargo, era necesario que volviera a cargar mis archivos dll externos y los reconstruyera también.
SezMe

Con VS2015U2, sigo teniendo este problema en x64. Funciona muy bien en cualquier CPU. Cambiar de un lado a otro no funciona para mí.
DaleyKD

7

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.


2
Este fue el caso para mí, lo trasladé a mi vm (en el que me desarrollo) y boom sin problemas. ¡Gracias!
Mario Tacke el

Este fue el caso para mí también parece. Pasarlos a estar en una unidad local (en lugar de un recurso compartido de red, como lo configuró Parallels para unir un poco el sistema de archivos Mac y Windows), solucionó el problema.
ckittel

7

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.


6

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.


2

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.


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.


2

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.


1

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ó.


1

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.


En otras palabras, la versión de .NET Framework del proyecto no puede ser anterior a la versión de .NET Framework del proyecto referenciado.
icernos

1

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.


Esto funcionó para mí: había descargado un proyecto de Dropbox y recibía el error. También tuve que eliminar ShadowCache
geometrikal

1

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.


1

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.


1

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


1

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

1

¡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.


0

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


0

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".


0

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.


0

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.


Esta respuesta se proporciona al menos dos veces arriba.
pdschuller

0

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.


0

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ó.


0

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


1
Su sugerencia es un cambio significativo que puede que ni siquiera sea una posibilidad para el OP si se dirigen a un entorno particular. De cualquier manera, es muy poco probable que sea la causa del problema, y ​​si resolvió el problema por usted, sugeriría que su problema real no coincidía con las configuraciones del proyecto, lo que se habría manifestado de muchas maneras diferentes al problema que se muestra aquí.
LordWilmore

0

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).


0

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


0

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.


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.