Es muy frecuente en empresas que los archivos de trabajo residan en un servidor, de forma que se mantengan centralizados (para copias de seguridad, versionamiento, etc...) y varias personas puedan trabajar al mismo tiempo sobre ellos.

En el caso de los programadores de Visual Studio esto puede suponer un problema.

Dicho problema viene dado porque, si ejecutamos Visual Studio con código que reside en un recurso compartido de la red (aunque sea una unidad "mapeada"), obtendremos advertencias a la hora de ejecutarlo e incluso errores en función del código que hayamos escrito, sobre todo en modo de depuración. Este problema se produce aunque tengamos control total para gestionar los archivos del recurso compartido.

Este comportamiento se debe a la configuración de seguridad por defecto de .NET, que trata de manera diferente al código según sea su procedencia. En el caso de código o programas ubicados en nuestra red local se usan los criterios de seguridad de "LocalIntranet", mientras que cuando ejecutamos un programa .NET en nuestro propio equipo el perfil de seguridad es "FullTrust" (es decir, confianza total).

Para evitar el problema sólo tenemos que cambiar la configuración de la seguridad .NET. Se utiliza la herramienta de configuración de la plataforma .NET, que podrás encontrar dentro de las Herramientas Administrativas del sistema. En ésta hay que buscar la directiva de seguridad para "LocalIntranet_Zone". En sus propiedades, dentro de la pestaña "Conjunto de permisos" cambia "LocalIntranet" por "FullTrust".

Ya está. A partir de ahora ya no habrá problemas para usar Visual Studio con proyectos guardados en la red local. Eso sí, habrá que tener especial cuidado con lo que ejecutamos desde ubicaciones remotas pues ahora todos los programas en recursos compartidos tienen los mismos permisos que si estuvieran en local y puede ser peligroso.

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor