Problema de Permisos (supongo...)

18/09/2006 - 18:11 por Consuelo | Informe spam

Hola,
Espero que podáis ayudarme a encontrar una pista que me ayude a solucionar
un problemilla que empieza a desesperarme...

He hecho una aplicación con Visual Studio .NET 2005 en VB. Esta aplicación
debe estar en un ordenador de la Intranet y poder ejecutarse desde cualquier
otro de la red (dando por supuesto que ese otro ordenador tiene las
librerías y el entorno correcto).

He hecho pruebas en el ordenador de desarrollo y funciona perfectamente,
pero cuando intento ejecutarlo desde otro ordenador, me da este error nada
más empezar:

"Error al crear el formulario. Consulte Exception.InnerException para
obtener más detalles. Error: Error de solicitud de permiso de tipo
'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Por si era un problema de que faltaban librerías, he copiado el ejecutable
en el otro ordenador y para mi sorpresa funcionaba correctamente !! pero si
intento ejecutar ese fichero desde el ordenador de desarrollo vuelve a
aparecer el mismo error.
resumiendo pues no sé si me ha quedado muy liado:

Tengo un ejecutable que solo puedo ejecutar en local, si intento ejecutarlo
desde otro ordenador se produce el error. (tengo permisos de administrador
en ambos ordenadores, eso no es el problema)

He probado a tocar permisos de ejecución del ordenador, pero tal vez no he
sabido encontrar el lugar adecuado

¿Puede alguien darme una pista?

Gracias!

Consuelo

Siga el debate

8 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 Consuelo

19/09/2006 - 13:16 | Informe spam

Gracias una vez más por tu respuesta...
Si, creo que lo he entendido bien, y hasta puedo llegar a entender que parte
de la gestión de la seguridad pase a los programas (aunque supongo que eso
será algo que los hará un poquito más lentos...) y en ese contexto es lógico
aplicar una directiva para que se confié en los programas que se descargan
de un ordenador concreto.
He hecho la prueba con el comando CASPOL y efectivamente ha funcionado,
pero...
... Cuando ya estaba dispuesta a pelearme con el jefe para que aceptara que
se ejecutara ese comando en todos los ordenadores de la red, me he dado
cuenta de que la norma de la casa es tener el Framework 1.1 y no el 2.0, y
que no está previsto cambiar en breve, por lo que me temo que tendré que
rehacer mi aplicación en .NET 2003... Yo que ya me había acostumbrado
demasiado bien a todas las ventajas que ofrece el 2005 (y además tengo la
Team Suite...)

Solo me queda la duda de si existe la posibilidad (aunque esté escondida y
solo al alcance de expertos) de decirle al entorno de compilación que no
incluya esa parte de gestión de seguridad en el ejecutable creado.

Gracias

Consuelo

"Alberto Poblacion"
escribió en el mensaje news:

"Consuelo" wrote in message
news:

Ya, sí que entiendo lo de modificar el framework, y ya vi ayer que el 2.0
no tiene el asistente que tenía el 1.1, pero mi problema es que por
motivos de política de empresa, debe existir una única copia del
ejecutable de mi aplicación en un único ordenador y todos los que quieran
utilizarlo deben acceder a ese ordenador.
Esto ya está funcionando así para una aplicación anterior hecha por mí en
VB6 que básicamente accede a las mismas cosas (una base de datos
SqlServer) y más de 50 personas acceden sin problemas.
Si yo le digo a mi jefe que por haberme pasado a VB.NET 2005 debo tocar
la configuración de todos los ordenadores que quieran utilizar el nuevo
programa, me va a decir que vuelva a VB6 y me olvide de estas
modernidades que solo aportan problemas... y la verdad es que no sé que
argumentos darle... Pues yo misma no entiendo qué es lo que hace que
ahora se necesiten permisos explícitos y antes no...
...Empiezo a estar desesperada...

Es un tema de seguridad. Antiguamente, si accidentalmente hacías
"click" sobre un .EXE de VB que estaba en cualquier máquina de tu red, ya
estabas perdida: El EXE se ponía a ajecutarse en tu ordenador y podía
hacer absolutamente de todo con él, incluyendo instalar virus, spyware,
reconfigurar el sistema operativo, etc.
Con .Net, Microsoft decidió embeber en la propia maquinaria de .Net
una serie de controles, de forma que un programa escrito en .Net no pueda
hacer "de todo" en una máquina, sino solo aquellas cosas que permita la
política de la empresa. Con .Net viene un editor de políticas que permite
decir qué cosas pueden hacer los ejecutables dependiendo de dónde vengan.
Por ejemplo, si tienes un servidor donde están los ejecutables que deben
ejecutar todos los puestos de la empresa, y el servidor es "de confianza"
(nadie instala ahi nada que no deba), entonces puedes conceder en .Net
permisos explícitos diciendo que todo el software que venga de ese
servidor reciba "full trust" (todos los permisos). Por desgracia, esta
operación (decirle a .Net que tal servidor es de confianza) debe repetirse
en cada puesto que deba confiar en ese servidor, pero esto solo hay que
hacerlo una vez, y a partir de ese momento puedes poner en el servidor
todos los ejecutables que quieras y todos los puestos podrán ejecutarlos
sin problemas. Lo más fácil es que hagas un fichero de comandos con una
sentencia CASPOL similar a la que te han indicado en otro mensaje, y
ejecutar ese fichero en cada uno de los puestos. Esto solo hay que hacerlo
una vez, y a partir de ese momento todo funcionará como deseas.

Responder a este mensaje

#7 Alberto Poblacion

19/09/2006 - 15:19 | Informe spam

"Consuelo" wrote in message
news:

Solo me queda la duda de si existe la posibilidad (aunque esté escondida y
solo al alcance de expertos) de decirle al entorno de compilación que no
incluya esa parte de gestión de seguridad en el ejecutable creado.

No, no forma parte del proceso de compilación. Todos los controles de
seguridad van dentro del CLR (el entorno comnún de ejecución), que forma
parte del las DLLs que se instalan al instalar el Framework.

Responder a este mensaje

#8 Consuelo

20/09/2006 - 18:07 | Informe spam

Gracias una vez más por aclararme las ideas.

Ahora ya me encaja todo: quien detecta la falta de permisos, no es algo
"añadido" a mi programa, es una parte del Framework quien lo detecta. Si mi
programa utiliza el Framework, mi programa debe pasar ese control.

(Además estoy contenta pues no tengo que pasar a 2003... Más de uno tenía
instalado el Framework 2.0 y sin problemas... Quien quiera utilizar mi
programa tiene permiso para instalar el nuevo Framework)

Hasta otra!
Consuelo

"Alberto Poblacion"
escribió en el mensaje news:%23w6RO5%

"Consuelo" wrote in message
news:

Solo me queda la duda de si existe la posibilidad (aunque esté escondida
y solo al alcance de expertos) de decirle al entorno de compilación que
no incluya esa parte de gestión de seguridad en el ejecutable creado.

No, no forma parte del proceso de compilación. Todos los controles de
seguridad van dentro del CLR (el entorno comnún de ejecución), que forma
parte del las DLLs que se instalan al instalar el Framework.

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida