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

Escrito por un humano, no por una IA