Mantener proyectos de Visual Studio en una unidad de red

https://stackoverflow.com/questions/159627

03-07-2019
|

Pregunta

Acabamos de pasar de almacenar todos los archivos localmente a una unidad de red. El problema es que es donde mis proyectos VS también se almacenan ahora. (Todavía no hay un sistema de control de versiones, trabajando en eso). Sé que escuché problemas con hacer esto en el pasado, pero nunca escuché de una solución alternativa. ¿Hay alguna solución?

Entonces mi VS está instalado localmente. Los archivos están en una unidad de red. ¿Cómo puedo hacer que esto funcione?

EDITAR: Sé lo que DEBE hacerse, pero ¿hay una curita que pueda poner en este momento para arreglar esto y mantener la unidad de red?

EDIT 2: estoy seguro de que no entiendo algo, pero Bob King tiene la idea correcta. Trabajaré con el desarrollador web principal cuando regrese a la oficina para encontrar una solución temporal hasta que obtengamos algún tipo de configuración de control de versiones. Gracias por las ideas.

Solución

Si bien usamos Source Control, también ejecutamos todos nuestros proyectos desde Network Drives (no directorios compartidos, directorios privados en unidades de red). Las unidades de red se respaldan todas las noches y también usan Volume Shadow Copy, por lo que si necesita volver a algo antes se abrió camino a SC, entonces puede hacerlo.

Para que los proyectos se ejecuten correctamente con el permiso correcto, siga estos pasos .

Básicamente, solo tiene que asignar el directorio compartido a una unidad y luego otorgar permiso, en función de esa URL, a todo el código. Digamos que asigna a & Quot; N: \ & Quot ;, luego use & Quot; N: \ * & Quot; como su patrón de URL. No es obvio que necesite un comodín, pero lo necesita.

Otros consejos

La pregunta es bastante genérica, así que responderé a un problema que estaba enfrentando.

Ejecuto Visual Studio 2010 usando una máquina virtual Parallels en mi Mac mientras mantengo todos mis proyectos en el lado de Mac a través de un recurso compartido de red. Sin embargo, Visual Studio no cargaría los archivos de ensamblaje de proyectos desde allí. Intentando establecer los derechos usando & Quot; caspol & Quot; solo no ayudó en mi caso.

Lo que finalmente funcionó para mí para permitir que Visual Studio cargara ensamblados desde un recurso compartido de red fue editar el archivo " C: \ Archivos de programa (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe.config " (suponiendo una instalación predeterminada).

en el xml " < runtime > " sección que tienes que agregar

<loadFromRemoteSources enabled="true"/>

Puede que tenga que cambiar los permisos en ese archivo para permitir el acceso de escritura. Guarda el archivo. Reinicie Visual Studio.

En aras de responder la pregunta, copié este comentario de jcarle.com:

Confiar en recursos compartidos de red con Visual Studio 2010 / .NET Framework v4.0

20 de enero de 2011, 4:10 pm Si es como yo y almacena todo su código en un servidor, probablemente habrá aprendido a confiar en un recurso compartido de red con CasPol.exe. Sin embargo, al pasar de Visual Studio 2008 (.NET Framework 2.0 / 3.0 / 3.5) a Visual Studio 2010 (.NET Framework 4.0), es posible que se rasque la cabeza.

Si está acostumbrado a utilizar el símbolo del sistema de Visual Studio para llegar rápidamente a CasPol, es posible que algunos de sus proyectos no respeten su nueva configuración de FullTrust. La razón es que, a menos que esté prestando atención, el símbolo del sistema de Visual Studio por defecto agrega la carpeta .NET Framework 4.0 a su ruta. Si su proyecto todavía se está ejecutando bajo .NET Framework 2.0 / 3.0 / 3.5, también requerirá configurar CasPol para esas versiones. Solo una nota, también he tenido más éxito al usar 1 como grupo de código en lugar de 1.2.

Para confiar en un recurso compartido de red para todas las versiones de .NET Framework, simplemente llame a CasPol para cada versión utilizando la ruta completa como se muestra a continuación:

C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CasPol -m -ag 1 -url archivo: // YourSharePath * FullTrust
C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ CasPol -m -ag 1 -url archivo: // YourSharePath * FullTrust

No recomendaría hacerlo si tiene (o incluso si no tiene) varias personas que están trabajando en los proyectos. Solo estás pidiendo problemas.

Si eres el único que trabaja en ello, por otro lado, evitarás muchos de los problemas. Sin embargo, el rendimiento se va por la ventana. En cuanto a cómo hacer que funcione, simplemente abra el archivo de solución de VS. Es probable que tenga problemas de seguridad, pero puede corregirlo con CASPOL. Sin embargo, como dije, el rendimiento será terrible. Nuevamente, no se recomienda en absoluto.

Hágase un favor a usted y a su equipo e instale SVN o alguna otra forma de control de origen y coloque el código lo antes posible.

EDITAR: retractaré parcialmente mis comentarios. Bob King explica a continuación la razón por la que ejecutan proyectos VS desde una unidad de red y tiene sentido. Yo diría que a menos que lo estés haciendo por una razón específica como Bob, mantente alejado de eso. De lo contrario, ponga a sus patos en fila antes de configurar dicho entorno de desarrollo.

Entiendo que este es un hilo antiguo, pero este fue el mejor hilo que encontré cuando buscaba resolver un problema similar. Tenía Visual Studio 2013 en una caja virtual (usando Win 8.1) y el código en la máquina host (Win 7 ) Aunque pude abrir la solución, no pude compilar. Todas las otras respuestas sobre esto se relacionan con software anterior, por lo que agrego esta respuesta para actualizar esta pregunta que se encuentra con frecuencia con la solución que funcionó para mí.

Esto es lo que hice; Hizo una entrada de registro para poder usar una ruta UNC como el directorio actual.

ADVERTENCIA: El uso incorrecto del Editor del registro puede causar problemas graves en todo el sistema que pueden requerir que reinstale Windows NT para corregirlos. Microsoft no puede garantizar que se puedan resolver los problemas derivados del uso del Editor del Registro. Utilice esta herramienta bajo su propio riesgo.

Bajo la ruta de registro: HKEY_CURRENT_USER \Software \ Microsoft \ Procesador de comandos

agregue el valor DisableUNCCheck REG_DWORD y establezca el valor en 0 x 1 (Hex).

ADVERTENCIA: si habilita esta función e inicia una consola que tiene un directorio actual con un nombre UNC, inicia aplicaciones desde esa consola y luego cierra la consola, podría causar problemas en las aplicaciones iniciadas desde esa consola.

Encontré esta información en el enlace: http://support.microsoft.com/kb/156276

¿Qué tal si reformulamos esto en una pregunta que todos puedan responder? Tengo exactamente el mismo problema que el póster inicial.

Tengo una copia de VB 2008 (recientemente actualizado desde VB6). Si almaceno mis soluciones en la unidad de red con copia de seguridad, no funcionará nunca. Da & Quot; llamante de confianza parcial & Quot; errores para acceder a un módulo, incluso cuando " allowcarscallialtrustedcallers " se establece en la asamblea. Si almaceno los archivos en mi C (no respaldada), se ejecutará maravillosamente, hasta que lo coloque en la unidad compartida para que todos lo usen, y vuelva a mi mismo problema.

Esta no es una gran solicitud. Solo quiero poder poner una solución y un ejecutable en la unidad compartida y ejecutarlo sin una cantidad absurda de tonterías sobre seguridad. No debería tener que meter todo mi trabajo en archivos de formulario.

-Editar: Encontré el problema de por qué ignoraba el comando AllowPartialllyTrustedCallers. Estoy tratando de hacer referencia a ADODB, que no permite una confianza parcial. Entonces, ¿ningún ejecutable de red puede acceder a una base de datos? ¿Qué tiene Microsoft contra las intranets de todos modos?

No lo hagas. Si tiene control de fuente (control de versiones), no desea que sus archivos estén en una unidad de red. Omite totalmente todo lo que desea lograr mediante el uso del control de fuente, porque una vez que sus archivos están en una unidad de red, cualquiera puede modificarlos ... incluso mientras está construyendo su proyecto. Ka-boooom!

PD: esto me parece un caso típico de sobre ingeniería para mí.

¿Tiene algún problema específico?

Si permite que más de una persona abra la solución, su primer problema será que el archivo .NCB (Intellisense) se bloqueará exclusivamente y solo un usuario podrá explorar el árbol de clases. Y, por supuesto, tiene el potencial de que los cambios de un usuario sobrescriban los cambios del otro usuario.

Entonces estaba teniendo un problema similar. Visual Studio no reconocería una ubicación de red que había asignado para una letra de unidad para nada. Lo curioso es que funcionó por un día. Configuré mi proyecto y comencé a trabajar en él y no tuve problemas. Luego, apagué y al día siguiente nada funciona. No podía leer / escribir archivos en el código, generar mis ejecutables ni nada. Mi proyecto es local pero mi salida estaba destinada a ser lanzada en la red.

De todos modos, el problema probablemente se deba al contexto del administrador, pero una forma de solucionarlo que encontré al buscar en línea es hacer que Visual Studio navegue hasta la unidad en cuestión de alguna manera. Hay muchas maneras de hacerlo, pero VS podrá reconocer mágicamente las letras de unidad mapeadas. Mi solución es ir a la Ubicación de salida de depuración en las Propiedades del proyecto, hacer clic en Examinar e ir a mi ubicación de salida previamente realizada en mi unidad de red y ¡Voila!

Quería poner esto en práctica porque pasé medio día tratando de resolver esto y pensé que podría ahorrarle algo de tiempo a alguien más. ¡Muchas gracias y buena suerte!

Erik

Estaba enfrentando el mismo problema recientemente, así que esta respuesta es más por el seguimiento de mi propio conocimiento. De todos modos, si soumeone lo encuentra útil, a continuación se encuentra el problema y la solución.

Problema: Los proyectos NET 4.0, el repositorio SVN, las carpetas de pago están en unidades locales, los ensamblados a los que se hace referencia son compilados por el servidor de compilación y disponibles en una unidad de red. Visual Studio en W7 es capaz de agregar la referencia pero no puede construir proyectos.

Solución: Dado que NET 4.0 ya no proporciona automáticamente un entorno limitado para los ensamblados de red, debe hacer que estos sean totalmente confiables a través de la actualización machine.config. http://msdn.microsoft.com/en-us/library/dd409252.aspx

Si lo entiendo correctamente, sus archivos de proyecto de Visual Studio se almacenan en la unidad de red y los está ejecutando desde allí. Esto es lo que hago y no tengo ningún problema. Deberá asegurarse de haber establecido la política de seguridad. Puede usar Caspol para hacer esto, o a través del menú de herramientas de administración del panel de control.

Se le debe advertir que alguna característica de Visual Studio se negará a trabajar con la unidad de red.

Por ejemplo, el archivo mdf de la instancia de usuario de SQL Express debe ubicarse en la unidad local.

Para otro ejemplo, si usa la ruta UNC, debe asegurarse de que sean lo suficientemente cortos.

encontré esto útil al intentar usar vc11 con paralelos que se ejecutan en mac: http: //social.msdn .microsoft.com / Forums / es-ES / toolsforwinapps / thread / 2ffdcb01-c511-4961-834b-afd5f2fbb8e1 , y específicamente:

1) Puede cambiar de depuración local a depuración remota y establecer el nombre de la máquina como 'localhost'. Esto hará una implementación remota en su máquina local (por lo tanto, no usará el directorio del proyecto). No necesita instalar las herramientas de depurador remoto, ni iniciar msvsmon para que esto funcione en localhost.

En caso de que esto ayude a alguien más, tuve que seguir los pasos descritos aquí para agregar la ubicación del recurso compartido de red a Windows zona de intranet En particular, estaba teniendo problemas con Visual Studio colgando de la carga al abrir una solución en un recurso compartido de red (es decir, usando VMware Fusion y abriendo una solución desde el disco duro de mi Mac). También tuve problemas con PostSharp ejecutándose en este escenario.

Tuve un problema similar al abrir proyectos de Visual Studio en una unidad de red, y lo arreglé creando un enlace simbólico en mi unidad C: \ local que apunta al directorio UNC

por ejemplo

mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"

entonces puede abrir el proyecto usando la ruta C: \ Users \ Self \ Documents \, en lugar de la ruta UNC

(Debe tener cuidado, porque Visual Studio lo redirigirá automáticamente a la ruta '\\ domain.net ..' si hace doble clic en el enlace simbólico cuando está buscando el proyecto. Tuve que copiar y pegar el 'C: \ Users \' para que se abra con la ruta de la letra de unidad)

" ¿Cómo puedo hacer que esto funcione? " Tienes un par de opciones:

Opción A: 1. Mueva todos los archivos a su disco duro local 2. Implemente algún tipo de software de respaldo en su máquina 3. Pruebe dicha solución de respaldo 4. seguir codificando

Opción B: 1. Obtenga una copia de uno de los productos GRATUITOS de control de código fuente e impleméntelo. 2. Asegúrese de que esté siendo respaldado 3. Pruébalo

Opción C: Utilice uno de los muchos repositorios de control de fuente EN LÍNEA disponibles. Google, SourceForge, CodePlex, algo.

Bueno, mi pregunta sería por qué preguntas esto. ¿No funciona cuando lo está almacenando en una unidad de red? No lo he intentado yo mismo, y un problema que podría imaginar sería que el código .NET que se ejecuta desde una unidad de red (es decir, desde el directorio bin \ Debug, también ubicado en la unidad de red) se ejecute en modo sandbox, a menos que juegues con CASPOL (o utilices 3.5 SP1 que, según escuché, ha eliminado ese obstáculo).

Si tiene problemas específicos, pregunte por ellos. Nunca pregunte & Quot; ¿Por qué X no funciona? & Quot ;.

No está diciendo si solo es una persona o varias personas que acceden al mismo disco remoto, pero supongo que es solo uno para cada directorio de red. ¿Es esto correcto? Si no, no, no hay curita. Obtenga el control de versiones, mueva los archivos nuevamente a un disco local.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow