none
Duda para ejecutar instalación en servidor RRS feed

  • Pregunta

  • Hola a todos, buenos días:

    Desearía por favor saber si tengo que realizar algún cambio en mi aplicación para que se puedan conectar varios usuarios a la misma. La aplicación estaría instalada en un servidor y accederían a ella mediante carpeta compartida, que creo que es lo más fácil, ahora bien, el problema también radica en el control de usuarios, eso ya lo he hecho, pero no se si un mismo usuario (haciendo trampas) se podría conectar al mismo tiempo desde diversos ordenadores.

    Querría conocer si no es mucho trabajo un poco este proceso de aplicación instalada en servidor y acceso, ya que siempre el programa lo he tenido instalado en uno o varios pc y en el servidor solamente estaba la base de datos, en este caso Access.

    Ya controlo el acceso del número de usuarios mediante un método, que me indica la cantidad de usuarios que pueden acceder a la aplicación, para ello, les entrego una clave que indica el número de usuarios autorizados.

    Un cordial aludo a todos.

    sábado, 28 de mayo de 2016 7:28

Respuestas

  • "gemma_campillo" preguntó:

    > Desearía por favor saber si tengo que realizar algún cambio en mi aplicación para que
    > se puedan conectar varios usuarios a la misma. La aplicación estaría instalada en un
    > servidor y accederían a ella mediante carpeta compartida, ...

    Siempre y cuando los usuarios tengan los preceptivos permisos para acceder a esa carpeta compartida, y sobre todo que tengan permisos de escritura, si van a escribir datos en la base de datos, en principio no tendrías que hacer ningún cambio en tu aplicación, aunque como te ha comentado Williams Morales, no sé yo si hacer eso es una buena idea.

    > ... el problema también radica en el control de usuarios, eso ya lo he hecho, pero
    > no se si un mismo usuario (haciendo trampas) se podría conectar al mismo tiempo
    > desde diversos ordenadores.

    ¡Bueno! Habría que ver qué control de usuarios has implementado, porque si dicho control se basa en los campos de la tabla Usuarios de tu base de datos que estoy observando en estos momentos, me vas a disculpar pero no me queda más remedio que decirte que deja mucho que desear, porque lo único que estás registrando son los datos del usuario (IdUsuario, Nombre, Contraseña, NombreUsuario, Apellidos) y nada más. Imagina que algún cliente tuyo quiere hacer una auditoría para averiguar quién ha sido el "capullo" que ha fastidiado el trabajo de 5 meses. ¿Cómo lo averigua sin conocer las fechas y horas que los usuarios han iniciado y cerrado sesión en la aplicación? Y ya no voy a decirte que registres también el usuario y fecha en la que se ha insertado, modificado o eliminado un registro de cualquier tabla. Esa tabla de Usuarios tienes que ampliarla.

    Para comenzar, elimina el Autonumérico que tienes como tipo de dato del campo IdUsuario, ya que debería de ser un Identificador Único Global (GUID), que para insertarlo en una base de datos de Access, tendrías que hacerlo en un campo de tipo Texto. Para una base de datos de SQL Server podrías definir la columna con el tipo de dato UniqueIdentifier, de tal manera que el identificador de usuario sea único, aunque se trate de usuarios de diferentes organizaciones. Pero vamos a dejar que sea un valor numérico sin llegar a ser Autonumérico.

    Para conocer si un usuario está conectado, tienes que añadir a la tabla un campo que te diga si el usuario está o no activo actualmente. Para eso, simplemente tienes que añadir un campo de tipo Si/No, de tal manera que cuando se autentifique le asignas el valor 1 y cuando cierre sesión le asignas el valor 0. Suponiendo que dicho campo se llama IsActive, tan solo tendrías que llamar al siguiente procedimiento o consulta almacenada llamada en el ejemplo IsActiveUser:

        PARAMETERS [@idUser] Text ( 50 );
        SELECT IIf(IsActive,1,0) AS IsActive
        FROM Usuarios
        WHERE (IdUsuario=[@idUser]);

    Y en tu capa de negocio llamarías a dicho procedimiento utilizando algo parecido a la siguiente función:

        ''' <summary>
        ''' Indica si un usuario está actualmente activo en la base de datos.
        ''' </summary>
        ''' <param name="idUser">Identificador único del usuario.</param>
        ''' <returns></returns>
        Friend Shared Function IsActiveUser(idUser As String) As Boolean
    
            If (String.IsNullOrWhiteSpace(idUser)) Then
                Throw New ArgumentNullException("idUser", "Identificador de usuario no válido.")
            End If
    
            Dim isActive As Integer
    
            Using cmd As New OleDbCommand()
                cmd.CommandText = "IsActiveUser"
                cmd.CommandType = CommandType.StoredProcedure
                cmd.Parameters.AddWithValue("@idUser", idUser)
                isActive = CInt(CapaAccesoDatos.ExecuteScalar(cmd))
            End Using
    
            Return (isActive = 1)
    
        End Function

    Cuando desees conocer si usuario con unas credenciales concretas (IdUsuario y Contraseña) está activo (True) o no (False), simplemente tendrías que consultar el valor devuelto por la función IsActiveUser:

        Private Sub btnLogin_Click(sender As Object, e As EventArgs) Handles btnLogin.Click
    
            If (CapaNegocio.IsActiveUser(txtId.Text)) Then
                MessageBox.Show("El usuario ya se encuentra identificado en el sistema.")
    
                ' Ejecutar aquí lo que proceda.
                '
    
            Else
                ' El usuario no está activo.
                '
                ' Proceder a efectuar la autenticación del usuario, y en caso
                ' de ser satisfactoria, registrar el inicio de sesión.
                '
                IdUsuario = txtId.Text
    
            End If
    
        End Sub

    Lógicamente, cuando el usuario finalize la sesión tendrás también que registrar dicha circunstancia para que deje de estar activo, y de camino, registrar la fecha y hora en que ha cerrado la sesión, por lo que también necesitarás un campo del tipo Fecha/Hora (DateTime) y el siguiente procedimiento almacenado llamado UserLogOff:

        PARAMETERS [@idUser] Text ( 50 ), [@fecha] DateTime;
        UPDATE Usuarios SET Usuarios.IsActive = 0, Usuarios.FechaCierreSesion = [@fecha]
        WHERE (Usuarios.[IdUsuario]=[@idUser]);

    Y en la capa de negocio su correspondiente procedimiento llamador:

        ''' <summary>
        ''' Cierra la sesión del usuario.
        ''' </summary>
        ''' <param name="idUser">Identificador único del usuario.</param>
        ''' <param name="fechaCierreSesion">Fecha y hora en la que el
        ''' usuario ha cerrado la sesión.</param>
        Friend Shared Sub UserLogOff(idUser As String, fechaCierreSesion As DateTime)
    
            If (String.IsNullOrWhiteSpace(idUser)) Then
                Throw New ArgumentNullException("idUser", "Identificador de usuario no válido.")
            End If
    
            Using cmd As New OleDbCommand()
                cmd.CommandText = "UserLogOff"
                cmd.CommandType = CommandType.StoredProcedure
                cmd.Parameters.AddWithValue("@idUser", idUser)
                cmd.Parameters.AddWithValue("@fecha", fechaCierreSesion)
                CapaAccesoDatos.ExecuteAction(cmd)
            End Using
    
        End Sub

    Me imagino que conocerás lo que hacen los procedimientos llamados CapaAccesoDatos.ExecuteScalar() y CapaAccesoDatos.ExecuteAction(). ;-)

    Y cuando el usuario finalice la aplicación tendrás que registrar dicho suceso llamando al procedimiento UserLogOff:

            Try
                ' Cuando el usuario cierre la aplicación, registrar
                ' el cierre de la sesión.
                '
                CapaNegocio.UserLogOff(IdUsuario, DateTime.Now)
    
            Catch ex As Exception
                MessageBox.Show(ex.Message)
    
            End Try

    Como observarás, como mínimo tienes que añadir dos campos más a tu tabla Usuarios: uno que nos indica si el usuario está o no actualmente activo, y otro para registrar el último cierre de sesión que ha efectuado el usuario. Pero te digo que reces para que tu cliente no te pida que quiere realizar una auditoría para conocer las veces que "fulanito" o "menganita" han entrado a la aplicación y qué modificaciones han efectuado en la misma. ;-)

    > Para comenzar, elimina el Autonumérico que tienes como tipo de dato del campo IdUsuario,
    > ya que debería de ser un Identificador Único Global (GUID), ...

    Quiero aclararte que el hecho que como valor del campo IdUsuario especifiques un GUID, no quiere decir que el usuario cuando se autentifique tenga que escribir un valor como 0abdba70-fd77-4254-88d4-4b637da9e5be. El usuario se tendrá que autentificar con su Nombre (Pepito) y Contraseña (*******). El valor GUID serviría para identificar de manera única en otras tablas relacionadas el registro de la tabla Usuarios.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 28 de mayo de 2016 16:42
    Moderador
  • gemma_campillo,

    Tener la aplicación instalada en un servidor y que todos los usuarios accedan a ella no es lo correcto, ¿qué ventajas obtiene?. Todas las instancias de la aplicación estarían ejecutándose en el servidor, por tanto consumiendo recursos que deberían estar dirigidos al servidor de datos -en caso tengas en el mismo servidor el servidor de datos-.

    Veo más desventajas que ventajas, quizá la "única ventaja" sea evitar el despliegue de la solución en todos las terminales pero aún así no es lo correcto, para evitar ese coste existen soluciones como clickOnce que permite realizar actualizaciones automáticas con interacción mínima por parte del usuario, ClickOnce.

    En caso tenga una fuerte razón para instalar la aplicación en un servidor sería bueno lo exponga para ver si hay un mejor camino que tomar.

    • Marcado como respuesta gemma_campillo sábado, 28 de mayo de 2016 16:12
    sábado, 28 de mayo de 2016 16:07
  • gemma_campillo,

    Respecto a la instalación te sugiero leas el artículo que te adjunte de ClickOnce, creo que te ayudará al despliegue del producto sobre todo si quieres evitar la asistencia del usuario.

    Pienso que debes separar dos cosas: la ejecución -en términos normales- de la aplicación dentro de la infraestructura de la empresa y los casos eventuales en que un usuario desee conectarse a la empresa para desarrollar su trabajo. En el primer caso se recomienda que cada puesto de trabajo tenga una copia de la aplicación instalada en su equipo, para el segundo caso va a depender mucho de las normas de seguridad que tenga la empresa y de la infraestructura que disponga, lo que no estoy de acuerdo es que se acceda remotamente al servidor y básicamente por temas de seguridad, a menos que sea un equipo dedicado a servir la aplicación y que este aislado de otros servicios como el de datos, en este tipo de circunstancias he visto el uso de TS "La función de servidor Terminal Services de Windows Server proporciona tecnologías que permiten a los usuarios obtener acceso a programas basados en Windows que están instalados en un servidor de Terminal Server u obtener acceso a todo el escritorio de Windows. Con Terminal Services, los usuarios pueden obtener acceso a un servidor de Terminal Server desde dentro de una red corporativa o desde Internet.". Los temas de seguridad es para tomarlos a toda regla, hacerlo simple es acceder remotamente al equipo con aplicaciones como TeamViewer, VNC, etc.


    • Marcado como respuesta gemma_campillo sábado, 28 de mayo de 2016 17:01
    sábado, 28 de mayo de 2016 16:57
  • "gemma_campillo" escribió:

    > Es que es una situación que ahora el cliente con la moda de la nube, los ipads, etc.,
    > quieren conectarse desde cualquier sitio con su nombre de usuario y tal.
    >

    ¡Vamos a ver! ¡Que tu aplicación es de escritorio! ¡Que no es una aplicación web ni menos aún para dispositivos móviles!

    Está bien que se descargen las actualizaciones vía Internet, pero entiendo que lo correcto sería instalar la aplicación en los equipos individuales y tener la base de datos en una carpeta compartida por todos ellos.

    > Entiendo que no sea la manera más correcta de funcionar, pero si lo quieren así,
    > algo tengo que hacer.

    Si hablamos de una organización pequeña, con dos o tres puestos de trabajo, lo mismo hasta la aplicación puede que funcione con unos tiempos de respuesta óptimos. Pero como el servidor que contiene la carpeta compartida tenga que ejecutar 50 instancias de la aplicación a la misma vez, no sé yo si tu cliente va a estar muy satisfecho con tu aplicación, y piensa que los "palos" van a ir a tí. ;-)

    > ... y para dar permisos a la carpeta que esté el programa en el servidor,
    > solamente tendrá que dar permisos a esa carpeta y en principio tendrá que
    > funcionar, es así Enrique.?

    En teoría debería de funcionar aunque no sea lo más recomendable de hacer. Eso sí, antes de distribuir la aplicación asegurate que funciona correctamente, vaya a ser que haya algún contratiempo con Crystal Reports, o cualquier otro componente de terceras partes que utilices, cuestión que ignoro.

    Pero si han aplicado algún tipo de directiva de seguridad concreta, tanto al servidor como a los equipos individuales, que impida que se pueda ejecutar un ensamblado existente en un servidor de red, pues lo mismo no se va a poder ejecutar hasta que no se modifique dicha directiva.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 28 de mayo de 2016 17:17
    Moderador

Todas las respuestas

  • gemma_campillo,

    Tener la aplicación instalada en un servidor y que todos los usuarios accedan a ella no es lo correcto, ¿qué ventajas obtiene?. Todas las instancias de la aplicación estarían ejecutándose en el servidor, por tanto consumiendo recursos que deberían estar dirigidos al servidor de datos -en caso tengas en el mismo servidor el servidor de datos-.

    Veo más desventajas que ventajas, quizá la "única ventaja" sea evitar el despliegue de la solución en todos las terminales pero aún así no es lo correcto, para evitar ese coste existen soluciones como clickOnce que permite realizar actualizaciones automáticas con interacción mínima por parte del usuario, ClickOnce.

    En caso tenga una fuerte razón para instalar la aplicación en un servidor sería bueno lo exponga para ver si hay un mejor camino que tomar.

    • Marcado como respuesta gemma_campillo sábado, 28 de mayo de 2016 16:12
    sábado, 28 de mayo de 2016 16:07
  • Hola Williams:

    Muchas gracias por responder.

    El tema es que es una aplicación que se distribuye por Internet, por lo que nunca se hace la instalación en "casa del cliente". Bueno, entonces hay algunos que quieren poder conectarse remotamente desde su casa a la oficina y me dicen que todos los programas que tienen lo hacen así, instalan la aplicación en el servidor y comparten la carpeta desde cualquier ordenador local o remotamente.

    Entonces yo nunca he trabajado con instalaciones en servidores, pero no veo otra forma de que se puedan conectar remo0tamente a la aplicación. No se que otra técnica sería correcta debido a mi inexperiencia con este tema.

    Muchas gracias por tu ayuda como siempre.

    Gemma

    sábado, 28 de mayo de 2016 16:12
  • "gemma_campillo" preguntó:

    > Desearía por favor saber si tengo que realizar algún cambio en mi aplicación para que
    > se puedan conectar varios usuarios a la misma. La aplicación estaría instalada en un
    > servidor y accederían a ella mediante carpeta compartida, ...

    Siempre y cuando los usuarios tengan los preceptivos permisos para acceder a esa carpeta compartida, y sobre todo que tengan permisos de escritura, si van a escribir datos en la base de datos, en principio no tendrías que hacer ningún cambio en tu aplicación, aunque como te ha comentado Williams Morales, no sé yo si hacer eso es una buena idea.

    > ... el problema también radica en el control de usuarios, eso ya lo he hecho, pero
    > no se si un mismo usuario (haciendo trampas) se podría conectar al mismo tiempo
    > desde diversos ordenadores.

    ¡Bueno! Habría que ver qué control de usuarios has implementado, porque si dicho control se basa en los campos de la tabla Usuarios de tu base de datos que estoy observando en estos momentos, me vas a disculpar pero no me queda más remedio que decirte que deja mucho que desear, porque lo único que estás registrando son los datos del usuario (IdUsuario, Nombre, Contraseña, NombreUsuario, Apellidos) y nada más. Imagina que algún cliente tuyo quiere hacer una auditoría para averiguar quién ha sido el "capullo" que ha fastidiado el trabajo de 5 meses. ¿Cómo lo averigua sin conocer las fechas y horas que los usuarios han iniciado y cerrado sesión en la aplicación? Y ya no voy a decirte que registres también el usuario y fecha en la que se ha insertado, modificado o eliminado un registro de cualquier tabla. Esa tabla de Usuarios tienes que ampliarla.

    Para comenzar, elimina el Autonumérico que tienes como tipo de dato del campo IdUsuario, ya que debería de ser un Identificador Único Global (GUID), que para insertarlo en una base de datos de Access, tendrías que hacerlo en un campo de tipo Texto. Para una base de datos de SQL Server podrías definir la columna con el tipo de dato UniqueIdentifier, de tal manera que el identificador de usuario sea único, aunque se trate de usuarios de diferentes organizaciones. Pero vamos a dejar que sea un valor numérico sin llegar a ser Autonumérico.

    Para conocer si un usuario está conectado, tienes que añadir a la tabla un campo que te diga si el usuario está o no activo actualmente. Para eso, simplemente tienes que añadir un campo de tipo Si/No, de tal manera que cuando se autentifique le asignas el valor 1 y cuando cierre sesión le asignas el valor 0. Suponiendo que dicho campo se llama IsActive, tan solo tendrías que llamar al siguiente procedimiento o consulta almacenada llamada en el ejemplo IsActiveUser:

        PARAMETERS [@idUser] Text ( 50 );
        SELECT IIf(IsActive,1,0) AS IsActive
        FROM Usuarios
        WHERE (IdUsuario=[@idUser]);

    Y en tu capa de negocio llamarías a dicho procedimiento utilizando algo parecido a la siguiente función:

        ''' <summary>
        ''' Indica si un usuario está actualmente activo en la base de datos.
        ''' </summary>
        ''' <param name="idUser">Identificador único del usuario.</param>
        ''' <returns></returns>
        Friend Shared Function IsActiveUser(idUser As String) As Boolean
    
            If (String.IsNullOrWhiteSpace(idUser)) Then
                Throw New ArgumentNullException("idUser", "Identificador de usuario no válido.")
            End If
    
            Dim isActive As Integer
    
            Using cmd As New OleDbCommand()
                cmd.CommandText = "IsActiveUser"
                cmd.CommandType = CommandType.StoredProcedure
                cmd.Parameters.AddWithValue("@idUser", idUser)
                isActive = CInt(CapaAccesoDatos.ExecuteScalar(cmd))
            End Using
    
            Return (isActive = 1)
    
        End Function

    Cuando desees conocer si usuario con unas credenciales concretas (IdUsuario y Contraseña) está activo (True) o no (False), simplemente tendrías que consultar el valor devuelto por la función IsActiveUser:

        Private Sub btnLogin_Click(sender As Object, e As EventArgs) Handles btnLogin.Click
    
            If (CapaNegocio.IsActiveUser(txtId.Text)) Then
                MessageBox.Show("El usuario ya se encuentra identificado en el sistema.")
    
                ' Ejecutar aquí lo que proceda.
                '
    
            Else
                ' El usuario no está activo.
                '
                ' Proceder a efectuar la autenticación del usuario, y en caso
                ' de ser satisfactoria, registrar el inicio de sesión.
                '
                IdUsuario = txtId.Text
    
            End If
    
        End Sub

    Lógicamente, cuando el usuario finalize la sesión tendrás también que registrar dicha circunstancia para que deje de estar activo, y de camino, registrar la fecha y hora en que ha cerrado la sesión, por lo que también necesitarás un campo del tipo Fecha/Hora (DateTime) y el siguiente procedimiento almacenado llamado UserLogOff:

        PARAMETERS [@idUser] Text ( 50 ), [@fecha] DateTime;
        UPDATE Usuarios SET Usuarios.IsActive = 0, Usuarios.FechaCierreSesion = [@fecha]
        WHERE (Usuarios.[IdUsuario]=[@idUser]);

    Y en la capa de negocio su correspondiente procedimiento llamador:

        ''' <summary>
        ''' Cierra la sesión del usuario.
        ''' </summary>
        ''' <param name="idUser">Identificador único del usuario.</param>
        ''' <param name="fechaCierreSesion">Fecha y hora en la que el
        ''' usuario ha cerrado la sesión.</param>
        Friend Shared Sub UserLogOff(idUser As String, fechaCierreSesion As DateTime)
    
            If (String.IsNullOrWhiteSpace(idUser)) Then
                Throw New ArgumentNullException("idUser", "Identificador de usuario no válido.")
            End If
    
            Using cmd As New OleDbCommand()
                cmd.CommandText = "UserLogOff"
                cmd.CommandType = CommandType.StoredProcedure
                cmd.Parameters.AddWithValue("@idUser", idUser)
                cmd.Parameters.AddWithValue("@fecha", fechaCierreSesion)
                CapaAccesoDatos.ExecuteAction(cmd)
            End Using
    
        End Sub

    Me imagino que conocerás lo que hacen los procedimientos llamados CapaAccesoDatos.ExecuteScalar() y CapaAccesoDatos.ExecuteAction(). ;-)

    Y cuando el usuario finalice la aplicación tendrás que registrar dicho suceso llamando al procedimiento UserLogOff:

            Try
                ' Cuando el usuario cierre la aplicación, registrar
                ' el cierre de la sesión.
                '
                CapaNegocio.UserLogOff(IdUsuario, DateTime.Now)
    
            Catch ex As Exception
                MessageBox.Show(ex.Message)
    
            End Try

    Como observarás, como mínimo tienes que añadir dos campos más a tu tabla Usuarios: uno que nos indica si el usuario está o no actualmente activo, y otro para registrar el último cierre de sesión que ha efectuado el usuario. Pero te digo que reces para que tu cliente no te pida que quiere realizar una auditoría para conocer las veces que "fulanito" o "menganita" han entrado a la aplicación y qué modificaciones han efectuado en la misma. ;-)

    > Para comenzar, elimina el Autonumérico que tienes como tipo de dato del campo IdUsuario,
    > ya que debería de ser un Identificador Único Global (GUID), ...

    Quiero aclararte que el hecho que como valor del campo IdUsuario especifiques un GUID, no quiere decir que el usuario cuando se autentifique tenga que escribir un valor como 0abdba70-fd77-4254-88d4-4b637da9e5be. El usuario se tendrá que autentificar con su Nombre (Pepito) y Contraseña (*******). El valor GUID serviría para identificar de manera única en otras tablas relacionadas el registro de la tabla Usuarios.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 28 de mayo de 2016 16:42
    Moderador
  • gemma_campillo,

    Respecto a la instalación te sugiero leas el artículo que te adjunte de ClickOnce, creo que te ayudará al despliegue del producto sobre todo si quieres evitar la asistencia del usuario.

    Pienso que debes separar dos cosas: la ejecución -en términos normales- de la aplicación dentro de la infraestructura de la empresa y los casos eventuales en que un usuario desee conectarse a la empresa para desarrollar su trabajo. En el primer caso se recomienda que cada puesto de trabajo tenga una copia de la aplicación instalada en su equipo, para el segundo caso va a depender mucho de las normas de seguridad que tenga la empresa y de la infraestructura que disponga, lo que no estoy de acuerdo es que se acceda remotamente al servidor y básicamente por temas de seguridad, a menos que sea un equipo dedicado a servir la aplicación y que este aislado de otros servicios como el de datos, en este tipo de circunstancias he visto el uso de TS "La función de servidor Terminal Services de Windows Server proporciona tecnologías que permiten a los usuarios obtener acceso a programas basados en Windows que están instalados en un servidor de Terminal Server u obtener acceso a todo el escritorio de Windows. Con Terminal Services, los usuarios pueden obtener acceso a un servidor de Terminal Server desde dentro de una red corporativa o desde Internet.". Los temas de seguridad es para tomarlos a toda regla, hacerlo simple es acceder remotamente al equipo con aplicaciones como TeamViewer, VNC, etc.


    • Marcado como respuesta gemma_campillo sábado, 28 de mayo de 2016 17:01
    sábado, 28 de mayo de 2016 16:57
  • Hola maestro, buenas tardes.

    Te estaba esperando, lo entiendes, verdad?.

    Es que es una situación que ahora el cliente con la moda de la nube, los ipads, etc., quieren conectarse desde cualquier sitio con su nombre de usuario y tal.

    Entiendo que no sea la manera más correcta de funcionar, pero si lo quieren así, algo tengo que hacer. Desde luego voy a montar lo que me has indicado como hago siempre y para dar permisos a la carpeta que esté el programa en el servidor, solamente tendrá que dar permisos a esa carpeta y en principio tendrá que funcionar, es así Enrique.?

    Te vuelvo a decir como indicaba antes, que no he trabajado con servidores y me he comprado un libro esta mañana pero bueno, lo de siempre, el tiempo es el tiempo y tengo que darle a esto una solución.

    Bueno maestro, muchas gracias otra vez como siempre, voy a acabar una cosa de los informes y me pongo a añadir lo que me has indicado.

    Un fuerte abrazo querido maestro.

    Gemma

    sábado, 28 de mayo de 2016 16:59
  • Hola Williams:

    Voy a mirar información de lo que me indicado.

    Siempre salen problemas a última hora.

    Bueno, muchas gracias y voy a ver si con lo que me dices me aclaro.

    Un abrazo.

    Gemma

    sábado, 28 de mayo de 2016 17:01
  • "gemma_campillo" escribió:

    > Es que es una situación que ahora el cliente con la moda de la nube, los ipads, etc.,
    > quieren conectarse desde cualquier sitio con su nombre de usuario y tal.
    >

    ¡Vamos a ver! ¡Que tu aplicación es de escritorio! ¡Que no es una aplicación web ni menos aún para dispositivos móviles!

    Está bien que se descargen las actualizaciones vía Internet, pero entiendo que lo correcto sería instalar la aplicación en los equipos individuales y tener la base de datos en una carpeta compartida por todos ellos.

    > Entiendo que no sea la manera más correcta de funcionar, pero si lo quieren así,
    > algo tengo que hacer.

    Si hablamos de una organización pequeña, con dos o tres puestos de trabajo, lo mismo hasta la aplicación puede que funcione con unos tiempos de respuesta óptimos. Pero como el servidor que contiene la carpeta compartida tenga que ejecutar 50 instancias de la aplicación a la misma vez, no sé yo si tu cliente va a estar muy satisfecho con tu aplicación, y piensa que los "palos" van a ir a tí. ;-)

    > ... y para dar permisos a la carpeta que esté el programa en el servidor,
    > solamente tendrá que dar permisos a esa carpeta y en principio tendrá que
    > funcionar, es así Enrique.?

    En teoría debería de funcionar aunque no sea lo más recomendable de hacer. Eso sí, antes de distribuir la aplicación asegurate que funciona correctamente, vaya a ser que haya algún contratiempo con Crystal Reports, o cualquier otro componente de terceras partes que utilices, cuestión que ignoro.

    Pero si han aplicado algún tipo de directiva de seguridad concreta, tanto al servidor como a los equipos individuales, que impida que se pueda ejecutar un ensamblado existente en un servidor de red, pues lo mismo no se va a poder ejecutar hasta que no se modifique dicha directiva.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 28 de mayo de 2016 17:17
    Moderador
  • Hola Enrique:

    Si ya lo entiendo, la aplicación se distribuirá para que se instale en cada equipo como hasta ahora, y si quieren que funcione en el servidor, pues que pongan la base de datos en el servidor, pero si alguno, una vez se le hayan hecho las oportunas observaciones de los problemas que pueda tener, la quiere instalar en el servidor, bueno, contra eso no puedo hacer nada, solamente advertirle y así lo pondré en la ayuda del programa.

    Bueno, lo que precisaba saber era si podía o no funcionar una aplicación de escritorio en un servidor y ha quedado sumamente claro. Ahora no podían hacerlo porque cuando realizaba el ejecutable con "SetupFactory" ahí me da la opción de marcar donde se autoriza la instalación y yo ahí ponía que en servidores "no".

    Bueno, ya está entendido y clarificado.

    Muchas gracias maestro.

    Un fuerte abrazo.

    Gemma

    sábado, 28 de mayo de 2016 17:31