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 aplicación tutorial simple de MusicPlayer que estoy usando para aprender WPF. Estoy convirtiendo paso a paso una versión de C # del tutorial a VB.NET.

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

Lo extraño es que IntelliSense funciona bien con referenciar el 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 se encuentran en una carpeta llamada \ Controls. El espacio de nombres raíz del proyecto se deja intencionalmente en blanco. 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 etiqueta

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

(objeto definido en una )

   

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

¿No está seguro de lo que 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 Versión o viceversa.

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

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

ex:-

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

Intente cambiar la plataforma de destino de comstackción a x86 y comstackr el proyecto.

Observé a través de Subversion que aparentemente cambié el objective de la plataforma de comstackció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 tiempo breve antes de que comenzara a mostrar el mismo error que experimentó. Cambié el objective de la plataforma a x86 para probar y de repente mi diseñador estaba trabajando de nuevo. Posteriormente, lo cambié a x64, y el problema ha desaparecido por completo. Sospecho que el diseñador construye algún tipo de código en caché en x32 y el cambio de la plataforma de construcción x64 lo rompe cuando realiza cambios de código.

He visto desaparecer este problema al borrar el Xaml Design Shadow Cache. Tuve el problema con Visual Studio 2015 Actualización 1.

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

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

Proceso:

  1. Haga clic con el botón derecho en la solución en el Explorador de soluciones y elija “Solución limpia”
  2. Shutdown 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 debido a otros errores de comstackción . Cuando se han resuelto otros errores, este error aparentemente relacionado también se eliminó de la lista. Especialmente los errores en la parte inferior 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.

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

Soy nuevo en WPF y todavía soy un novato con VB.net, así que asumí que obtener este error era causado por hacer tonterías … supongo que realmente lo era. Logré deshacerme de él moviendo mi proyecto de una unidad compartida a una de mis unidades locales. El error desapareció, el proyecto comstack perfectamente sin problemas adicionales. Parece que VS2015 todavía tiene problemas con proyectos en una unidad compartida.

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

  1. En 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 derecho en el proyecto y seleccione ‘Recargar proyecto’ Asegúrese de que su proyecto todavía 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 de alguna manera yo, pero no, todo se compiló y ejecutó correctamente.

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

Coloqué mi clase estática de Comandos (en mi caso, el trato fue sobre hacer que el diseño descubriera mis Comandos de WPF) en su ensamblaje por separado y cambiando el nombre del ensamble por el de esa persona.

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 platforms , o Build the Project to update Design view

No se soluciona reconstruyendo la solución (ni el diseño ni el error “El nombre no existe en el espacio de nombres”)

Creo que fue porque jugué con la configuración de Solución -> Propiedades> Propiedades de configuración

Finalmente resolví el problema con 2 trabajos:

  1. Verificando todas las casillas de verificación en Columna de comstackción de la página: Solución -> Propiedades -> Propiedades de configuración
  2. Cambiar 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 Studio 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, la construcción en modo x86 permite que el visualizador y la construcción en modo x64 lo deshabilite.

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

Tuve este problema recientemente usando VS 2015 Actualización 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 la sincronización de repositorys de git si mi proyecto está en una ruta de red, también se resuelve moviéndolo localmente.

Parece que este problema se puede resolver a través de 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 “Crear [mi proyecto]”, el mensaje de error desapareció.

La solución para mí fue desbloquear las DLL de ensamblaje. Los mensajes de error que recibe no indican esto, pero el diseñador XAML se niega a cargar lo que llama ensamblajes “sandboxed”. Puedes ver esto en la ventana de salida cuando construyes. 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 “Desbloquear” o en la checkbox.

Nota: solo desbloquea las DLL si está seguro de que son seguras.

En mi caso, el control del usuario se agregó al proyecto principal. Intenté varias soluciones anteriores sin ningún resultado. O obtendría un Marcado Invalido pero la solución se comstackría y funcionaría, o agregaría los xmlns: c = “clr-namespace: MyProject; assembly = MyProject” y luego se mostraría el marcado, pero obtendría un error de comstackción que 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 transferí mi control de usuario del proyecto principal a ese. Se agregó la referencia y se cambió el ensamblaje 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, por lo que presenté 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 proyecto y el nombre del ensamblado eran Modelos ) y otro que contenía las vistas y los modelos de vista (según nuestra convención: proyecto, nombre de ensamblado y espacio de nombre predeterminado eran Models.Monitor ) . El proyecto Models.Monitor references Models.

En el proyecto Models.Monitor, en una de las xaml incluí el siguiente espacio de nombres: xmlns: monitor = “clr-namespace: Models.Monitor”

Sospecho que MsBuild y Visual Studio estaban extrayendo el error, ya que estaban tratando de encontrar un tipo de ‘Monitor’ en el conjunto ‘Modelos’ . Para resolver intenté lo siguiente:

  1. xmlns: monitor = “clr-namespace: Models.Monitor; assembly =” – que es válido si el espacio de nombres está en el mismo ensamblado que https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) .aspx
  2. también intenté la statement explícita del 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 comstackr bien después de eso.

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

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

Hay otro artículo aquí que muestra cómo incluir esto en sus plantillas de proyecto para que construya 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 assmeblies que contienen cualquiera de las superclases e interfaces de las subclases o implementaciones de “UpdatingMediaElement”. Parece que la plataforma de todos estos conjuntos debe ser “AnyCPU”.

Otra causa posible: un evento posterior a la creación elimina la DLL del proyecto de la carpeta de comstackción.

Para aclarar: el diseñador de WPF puede informar “El nombre XXX no existe en el espacio de nombres …”, incluso cuando el nombre existe en el espacio de nombres y el proyecto se comstack y funciona perfectamente si un evento posterior a la creación elimina la DLL del proyecto la carpeta de comstackción (bin \ Debug, bin \ Release, etc.). Tengo experiencia personal con esto en Visual Studio 2015.

Ok, ninguno de estos consejos funcionó para mí, desafortunadamente. 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 recomstackda. No más errores

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, consulte el marco de trabajo de Target. Por ejemplo, tener un proyecto que utiliza el marco de referencia 4.5 un proyecto con el marco 4.5.2 no es una buena combinación.

Agregando a la stack.

El mío era que el nombre del ensamblado de la aplicación WPF era el mismo nombre de ensamblaje que el dll al que se hace referencia. Así que asegúrese de no tener nombres de conjuntos 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 una advertencia sobre fonts que no confiaban. Lo moví a un disco local y el error de “espacio de nombres no existe” también desapareció.

También intente hacer clic derecho en su proyecto-> propiedades y cambiar el objective de la plataforma a cualquier CPU y reconstruir, luego funcionará. Esto funcionó para mí

Agregue un constructor vacío para su modelo de vista y reconstruya la solución. Intenté que muchas soluciones no funcionaran, pero esto fue resuelto por mí.