wpf xaml tutorial

Las correlaciones personalizadas del espacio de nombres de WPF fallan en Visual Studio 2010

Question

Acabo de instalar Visual Studio 2010 y convertí uno de mis proyectos de Visual Studio 2008 WPF para probarlo. Mientras el proyecto se crea y se ejecuta correctamente, el Diseñador de VS no puede manejar las asignaciones personalizadas del espacio de nombre que he proporcionado.

El ensamblaje debe especificarse para los archivos XAML que no son parte de un proyecto. Vuelva a abrir este archivo XAML después de agregarlo a un proyecto, cierre este archivo y vuélvalo a abrir utilizando el proyecto al que está asociado, o modifique el espacio de nombres clr para incluir el nombre del ensamblaje.

Los espacios de nombres en cuestión son parte del proyecto. Visual Studio 2008 no tuvo problemas con XAML. Así que creé un nuevo proyecto WPF en blanco llamado Test1 con el espacio de nombres como Test1 . Luego edité MainWindow.xaml generado para agregar una sola asignación para local :

<Window x:Class="Test1.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:Test1"
    Title="MainWindow" Height="350" Width="525">
    <Grid />
</Window>

Esto da el mismo error. Y, sorprendentemente, ¡Google informa que no hay resultados para el error! ;assembly=Test1 algunas variaciones, como agregar ;assembly= o ;assembly=Test1 , pero eso no ayudó.

¿Alguien puede ver lo que estoy haciendo mal? Si nada, agradecería mucho las sugerencias de por qué esto puede estar fallando.

Editar: según los comentarios, resulta que esto solo ocurre cuando el proyecto se abre desde un recurso compartido en red. No ocurre si el proyecto se abre en una unidad local. Sin embargo, me gustaría poder abrirlo en la red compartida, así que voy a dejar la pregunta abierta.

Answer 1

Solo para resumir todas las respuestas en esta publicación porque este problema también fue un problema para mí, y logré resolverlo de la siguiente manera.

En primer lugar, el problema proviene del hecho de que el proyecto no está en una unidad local, lo que crea algunos problemas dentro del entorno de Visual Studio.

Para resolver el problema:

1. Asegúrese de que el proyecto se abra utilizando una unidad asignada (como P:/Projects/.../mySolution.sln ). Tenga cuidado, esto significa que mapear la unidad no es suficiente; tienes que abrirlo desde la ruta mapeada (desde una ventana del explorador de archivos usando la unidad mapeada). Si continúa cargando con el menú "proyectos recientes" en VS, la ruta seguirá siendo absoluta.

2. Modifique el archivo de configuración del entorno de desarrollo denominado devenv.exe.config y agregue <loadFromRemoteSources enabled="true" /> en la configuration/runtime la sección configuration/runtime . Este archivo se encuentra en la unidad VS está instalado.

Es muy probable que, si se encuentra con este problema, trabaje en un entorno empresarial en el que tenga acceso restringido al disco duro local, lo que significa que debe solicitar al departamento de infraestructura de TI que realice los cambios por usted.

Finalmente, me gustaría agregar que también encontrarías problemas con los proyectos de Prueba de unidad si no usas este ajuste.

Espero que esto ayude.

Answer 2

He tenido el mismo problema pero he encontrado que usar una letra de unidad asignada en lugar de la ruta UNC funciona para mí.

Saludos

Neil Allen

Answer 3

Neil Allen tiene razón. Asigna la carpeta como unidad y todo estará bien. Cómo mapear: http://www.online-tech-tips.com/computer-tips/how-to-map-a-drive-in-windows/

Answer 4

Hay un problema de conexión con respecto a esto. En las soluciones provisionales hay un enlace a algo que puede intentar hacer funcionar: http://connect.microsoft.com/VisualStudio/feedback/details/568464/wpf-project-on-a-network-share-with-clr- namespace # details

Este es un enlace directo a la solución; http://msdn.microsoft.com/en-us/library/dd409252.aspx

Answer 5

Un problema similar le sucedió a algunos en nuestra compañía porque estábamos usando un recurso compartido de red para cada desarrollador.

El problema no ocurrió con aquellos que usaban una unidad de red mapeada con una contraseña guardada para reiniciar.

Puede ser algo con el dominio o el medio ambiente ... y VS ¿mal manejo de eso?

Answer 6

La ruta de red fue la culpable en mi caso.