¿Cómo puedo depurar soluciones en Visual Studio 2010 desde un recurso compartido de red?

Recientemente obtuve una nueva computadora Mac y estoy ejecutando VS2010 en una máquina virtual Parallels. En general, me está yendo bien, pero tengo algunos problemas para depurar tipos de proyectos específicos, relacionados con el hecho de que se accede a los proyectos a través de un recurso compartido de red. Los proyectos de prueba no se ejecutan porque el corrector de prueba no puede cargar la DLL de las pruebas. proyectos web no se ejecutan en el servidor web de mini Visual Studio, lanzando la siguiente excepción:¿Cómo puedo depurar soluciones en Visual Studio 2010 desde un recurso compartido de red?

'An error occurred loading a configuration file: Failed to start monitoring changes to path\to\web.config'.

he pasado la noche pesca de arrastre de la web con poca suerte en esto. Después de leer these two publicaciones, probé los cambios habituales de CasPol, pero luego encontré this post de uno de los primeros beta de VS2010 indicando que CasPol ya no es necesario/no está soportado en .NET 4.0 y VS2010.

Se puede acceder al recurso compartido de red a través de una unidad mapeada y la ruta UNC. El host para la ruta UNC es .pfs; de acuerdo con this post Windows trata los nombres de host que comienzan con un punto como originados en la Zona de Internet.

La máquina virtual ejecuta sus aplicaciones en la cuenta de administrador, que parece tener todos los permisos necesarios en el recurso compartido de red para crear, leer, escribir y eliminar archivos y carpetas. Digo "parece que tiene", ya que no puedo ver las Propiedades de seguridad de la carpeta adecuada mediante el Explorador: la pestaña Seguridad simplemente no está presente.

¿Alguien ha logrado cargar y depurar con éxito proyectos web y de prueba desde un recurso compartido de red en VS2010?

ACTUALIZACIÓN: Intenté cargar las soluciones en VS2010 en una máquina nativa de Windows usando la dirección IP de mi MacBook, con resultados mixtos. El proyecto de prueba una vez más no pudo funcionar con el error:

Error loading \\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll: Could not load file or assembly 'file://\\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

Sin embargo, el proyecto de ASP.NET MVC se ejecuta correctamente como se esperaba en este escenario, y me da exactamente los mismos resultados aquí si uso el nombre de NetBIOS de la MacBook.

Por supuesto, para poder hacer esto, tuve que habilitar el intercambio de SMB en Snow Leopard, que no era necesario para acceder a la ubicación en mi Parallels VM. Tal vez hay alguna configuración en Parallels que necesito modificar para cambiar los permisos en el recurso compartido.

También he marcado esta pregunta para que los moderadores soliciten que se mueva a StackOverflow; Creo que podría ser un foro más apropiado que SuperUser.

Fuente

2010-06-09 alastairs

@alastairs: lo siento, vi la bandera antes de mi respuesta, pero no me di cuenta de que la bandera era de OP. migrando en breve. –

¿Has resuelto tu problema? Tengo el mismo problema. thx – ema

La corrección devenv.exe.config en la respuesta aceptada a continuación parece haber resuelto el problema. Gracias @Daniel Plaisted! – alastairs

establecer <loadFromRemoteSources enabled="true"/> bajo el elemento de tiempo de ejecución de Devenv.exe.config, como se sugiere en la respuesta a this question intento. Me arregló el problema ... Visual Studio todavía me advierte al cargar un proyecto desde el recurso compartido, pero ejecutar las pruebas ahora funciona.

Fuente

2010-07-15 23:46:11

¡Oh, esto suena interesante! Gracias por el consejo, ¡me aseguraré de verificarlo cuando llegue a casa! – alastairs

Eso funcionó bien para mí. Pero tuve algunos problemas importantes para poder editar el devenv.exe.config ... El acceso denegado me dio la bienvenida. Mi solución fue abrir Notepad.exe "como administrador" y luego pude editar el archivo y ponerlo en funcionamiento –

Esto asume que el problema es realmente con Windows "tratar los nombres de host comenzando con un punto como originario de la Zona de Internet". Puede ser otra cosa, pero la opción (3) a continuación debe ser un medio rápido para (des) probar esto como parte del problema.

El período (.) no es un carácter utilizado frecuentemente en un nombre de host DNS; generalmente se interpreta como un separador entre el nombre de host y el nombre de dominio (por ejemplo, localhost.localdomain). Los nombres de host DNS generalmente están restringidos a "LDH": letras, dígitos y guiones.

Las rutas UNC y los nombres de red de Windows (NetBIOS) pueden sufrir problemas similares.De acuerdo con RFC3696, los períodos son legales, pero debe escapar de los períodos utilizados en un nombre de host de acuerdo con RFC1035. Si estoy leyendo RFC1035 correctamente, su nombre de host debe ser \.pfs en lugar de .pfs.

Me pregunto si sus problemas funcionarían bien si

cambiado el nombre de host (en el servidor acción) a algo que no incluyendo un punto (y actualizada al cliente en consecuencia),
cambió la ruta UNC al recurso compartido (en el cliente) para usar la secuencia de escape adecuada para los períodos, o
cambió la ruta UNC al recurso compartido (en el cliente) para usar la dirección IP en lugar del nombre de host.

Fuente

2010-06-10 19:16:22

Gracias por la respuesta. He actualizado mi pregunta con mi respuesta, que fue un poco larga para un comentario. – alastairs

¿Cómo puedo depurar soluciones en Visual Studio 2010 desde un recurso compartido de red?

Respuesta

Cuestiones relacionadas