2008-09-29 24 views
31

¿Mi aplicación .NET falla cuando se ejecuta desde una unidad de red incluso cuando el mismo ejecutable funciona perfectamente bien desde un disco duro local?¿Por qué mi aplicación .NET falla cuando se ejecuta desde una unidad de red?

me trataron comprobación de "confianza completa" de esta manera:

try 
{ 
    // Demand full trust permissions 
    PermissionSet fullTrust = new PermissionSet(PermissionState.Unrestricted); 
    fullTrust.Demand(); 

    // Perform normal application logic 

} 
catch(SecurityException) 
{ 
    // Report that permissions were not full trust 
    MessageBox.Show("This application requires full-trust security permissions to execute."); 
} 

Sin embargo, esto no está ayudando, y me refiero a la aplicación se inicia y el bloque catch no se introduce. Sin embargo, una compilación de depuración muestra que la excepción lanzada es una SecurityException causada por una InheritanceDemand. ¿Algunas ideas?

+0

Cuando usted dice que "no", ¿cómo es exactamente lo que falla? ¿Hay errores? – TheSoftwareJedi

+0

¿El código que escribe va en la captura? –

+0

acaba de obtener el mismo problema hoy y aún no ha encontrado una solución, estará viendo esta pregunta ... – Epaga

Respuesta

22

De hecho, tiene que ver con el hecho de que las aplicaciones en una ubicación de red son menos confiables que en su disco duro local (debido a la política predeterminada de .NET Framework).

Si no me equivoco, Microsoft finalmente corrigió esta molestia en .NET 3.5 SP1 (después de que muchos desarrolladores se quejaran).

I google'd que: .NET Framework 3.5 SP1 Allows managed code to be launched from a network share!

+0

Verificado esto haciendo que los usuarios afectados descarguen el Service Pack y todo está bien ¡Gracias! –

+0

¡Excelente! He tenido que usar CasPol antes con una utilidad que creamos para algunos de nuestros clientes. Es un dolor tener que crear un script y ejecutarlo antes de que se llame a su utilidad, simplemente porque se ejecuta desde una ubicación de red. –

+6

Actualización: el problema solucionado en .NET 3.5 SP1 parece reaparecer cuando se instala .NET 4.0. –

14

¿Has probado el uso de CasPol to Fully Trust a Share?

+0

Casi digno de votaciones, pero proporciona la solución sin explicar el problema. –

3

Si se trata de .NET 2.0 o superior, se creó ClickOnce para ayudar realmente con esta implementación. Solo despliego a redes compartidas usando eso.

0

Esta es la seguridad integrada por Microsoft en .NET Framework. Es una forma de evitar que el malware se ejecute localmente con privilegios completos, por lo que no puede cambiar esto programáticamente en el código.

Lo que necesita hacer es aumentar la confianza de conjuntos específicos. Lo hace en .NET Framework Configuration (Panel de control-> Herramientas administrativas) y debe hacerlo en cada computadora.

Al igual que con cualquier medida de seguridad, se trata de un dolor de culo-la-en-, pero ayudará a que el mundo sea menos infectados etc ...

+0

, pero ¿por qué no aparece su cuadro de mensaje? – Epaga

+2

... detención de malware ... ¿En cuántos programas maliciosos ha encontrado escritos?¿RED? Cualquier ejecutable que no sea .NET podrá ejecutarse desde la red utilizando todos los privilegios (de manera predeterminada). La única diferencia es que .NET no lo permitió por defecto, mientras que Windows sí lo permite. –

+3

bien, bloqueando el código administrado al tiempo que permite que se ejecuten los binarios de Win32 no es una medida de seguridad ... – user19871

11

Ya ha hecho esto, pero se puede usar caspol. exe para habilitar FullTrust para un recurso compartido de red específico.

Por ejemplo

cd c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 
CasPol.exe -m -ag 1.2 -url file:///N:/your/network/path/* FullTrust 

Más información here.

+0

¡Muy buena respuesta, funcionó para mí! – davidhq

+0

Lazy dev versión: '' C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319> CasPol.exe -m -ag 1.2 -zone Intranet FullTrust'' – mhvelplund

0

Todo lo que tenía que hacer era marcar los archivos de sólo lectura (posiblemente no relacionado) y dar todos los permisos excepto Control total a los usuarios autenticados. Me encontré con este problema antes de hacerlo, cuando solo tenía la red compartida para usuarios de dominio.

Descubrí esta solución porque ni los recursos compartidos de administrador (\ server \ C $) ni los recursos compartidos de mi propia PC tenían este problema.

Editar: aplicación se dirige a .NET 3.5, sin SP1 aquí (versión 3.5.7283)

Cuestiones relacionadas