none
Proyecto con SQL Server migro a otro motor de BD o no RRS feed

  • Pregunta

  • Buenas , tengo una aplicación con VS 2013 y SQL Server Express y estoy pensando en distribuir la a unos clientes que tengo.
    Cuando empezé a programar la verdad no mire las especificaciones de la BD y ahora que he puesto a mirar precios de la BD SQL Server Standard cuesta 4124€ y me da derecho a 10 instalaciones de cliente.
    Ese precio es muy superior al que los clientes van a pagar por la aplicación por lo que tengo 2 opciones : 
    - Sigo usando SQL Server express que tiene el inconveniente que la BD esta abierta y el cliente tiene acceso a todas las tablas y toda la información.
    - Uso otro motor de BD , por ejemplo MySQL o NoSQL

    En el primer caso si uso SQL Server Express el inconveniente es ese ... que el cliente con un visor puede entrar a los datos y modificar los datos con lo que no se si es conveniente...
    En el caso de usar MYSQL o otro motor de BD la duda que tengo es que en el proyecto de VS tengo los dataset creados que ahora mismo apuntan contra unas tablas de la BD en sql server , en el caso de por ejemplo usar MySQL debo modificar algo de los dataset? O solo modificar la conexión que usan y listos?

    Gracias
    • Editado golfgti6 sábado, 3 de diciembre de 2016 19:00
    sábado, 3 de diciembre de 2016 18:59

Respuestas

  • golfgti6,

    ¿Tienes necesidad de una edición de pago de SQL Server? Si tu proyecto es pequeño y no son muchos los usuarios que concurren a los datos creo que es suficiente una edición Express para evitar el costo de licencias.

    Por otro lado, los datos le pertenecen al cliente, por tanto es derecho y responsabilidad del cliente gestionar sus datos e implantar medidas de seguridad para salvaguardar su información, eso es así con cualquier gestor de base de datos sea gratuito o de pago. Quizá el alcance que puedas dar es algún manual de como crear un Login para conectarse a una instancia de base de datos Create a Login y gestionar los permisos/restricciones de acceso a los datos.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    • Marcado como respuesta golfgti6 domingo, 18 de diciembre de 2016 12:18
    sábado, 3 de diciembre de 2016 19:13
  • Para entrar con un usuario que NO sea el de Windows, hay que hacer varias cosas. Primero, activa en SQl Server la seguridad en modo mixto (es una opcion que esta en la pestaña "seguridad" en las propiadades de la instancia en SSMS). Despues de cambiar esta opcion hay que reiniciar el servicio SQL.

    Despues de eso, crea un Login desde la pestaña Security de la instancia (no la Security de la base de datos, que es la que has mostrado en la imagen). A ese login asignale credenciales de SQL Server (no de Windows), incluyendo una password. Desde la misma ventana de creacion de Login puedes ponerle un mapping que lo mapee a un User de la base de datos, y asignarle privilegios sobre esa base de datos.

    Y finalmente, en tu cadena de conexion, quita el "Integrated Security=yes" (o similar, se puede escribir de varias formas), y a cambio ponle "user id=usuario;pwd=password" (evidentemente usando los valores que antes creaste en el login).

    Para que NO entre el usuario de Windows con autenticacion integrada, tendras que suprimir ese usuario de la lista de logins de SQL Server (o su grupo, si es que esta asignado a un grupo tal como "builtin\administrators"). Antes de suprimirlo, asegurate de que has añadido algun otro login con privilegios administrativos sobre SQL Server, para que puedas administrar el servidor usando este otro login. Por supuesto, al usuario final que maneja el equipo no le diras la password de este otro login recien creado.

    • Marcado como respuesta golfgti6 domingo, 18 de diciembre de 2016 12:18
    lunes, 5 de diciembre de 2016 13:19

Todas las respuestas

  • Los datasets valdrán igual, pero tendrás que cambiar los objetos de acceso a base de datos. Por ejemplo, si estás usando un SqlDataAdapter tendrás que sustituirlo por la versión equivalente para el servidor de base de datos que utilices, y revisar las sentencias SQL con las que lo hayas inicializado, que puede que sean ligeramente distintas.

    Pero no ganarás nada. Con MySql el cliente podrá ver y modificar la base de datos exactamente igual que con SQL Server (Express o no, no tiene nada que ver la edición -- en todas ellas se accede igual).

    sábado, 3 de diciembre de 2016 19:04
  • golfgti6,

    ¿Tienes necesidad de una edición de pago de SQL Server? Si tu proyecto es pequeño y no son muchos los usuarios que concurren a los datos creo que es suficiente una edición Express para evitar el costo de licencias.

    Por otro lado, los datos le pertenecen al cliente, por tanto es derecho y responsabilidad del cliente gestionar sus datos e implantar medidas de seguridad para salvaguardar su información, eso es así con cualquier gestor de base de datos sea gratuito o de pago. Quizá el alcance que puedas dar es algún manual de como crear un Login para conectarse a una instancia de base de datos Create a Login y gestionar los permisos/restricciones de acceso a los datos.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    • Marcado como respuesta golfgti6 domingo, 18 de diciembre de 2016 12:18
    sábado, 3 de diciembre de 2016 19:13
  • Los datasets valdrán igual, pero tendrás que cambiar los objetos de acceso a base de datos. Por ejemplo, si estás usando un SqlDataAdapter tendrás que sustituirlo por la versión equivalente para el servidor de base de datos que utilices, y revisar las sentencias SQL con las que lo hayas inicializado, que puede que sean ligeramente distintas.

    Pero no ganarás nada. Con MySql el cliente podrá ver y modificar la base de datos exactamente igual que con SQL Server (Express o no, no tiene nada que ver la edición -- en todas ellas se accede igual).

    Sinó recuerdo mal cuando he usado mysql al menos para entornos web , al instalar el servidor de Mysql definias un usuario y contraseña para una BD , por lo tanto si el usuario no tenia el user y password no podia acceder a ella.

    En el caso de SQL Server Express estuve preguntando en otro post y me dijeron que por mucho que cree login para la BD , en local siempre se puede acceder a la BD siempre que se este loggeado en el sistema , de hecho en mi instalación en local es asin yo abro el editor de SQL Server busco mi instancia y puedo conectarme sin user y password.

    sábado, 3 de diciembre de 2016 19:22
  • golfgti6,

    ¿Tienes necesidad de una edición de pago de SQL Server? Si tu proyecto es pequeño y no son muchos los usuarios que concurren a los datos creo que es suficiente una edición Express para evitar el costo de licencias.

    Por otro lado, los datos le pertenecen al cliente, por tanto es derecho y responsabilidad del cliente gestionar sus datos e implantar medidas de seguridad para salvaguardar su información, eso es así con cualquier gestor de base de datos sea gratuito o de pago. Quizá el alcance que puedas dar es algún manual de como crear un Login para conectarse a una instancia de base de datos Create a Login y gestionar los permisos/restricciones de acceso a los datos.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.

    Si mi proyecto es pequeño no necesito un motor super potente con la edición express me basta y me sobra.

    Los datos ya que son de los usuarios pero en mi caso como en el de muchos he desarrollado un software de gestión donde puede acceder a la BD distintos usuarios del negocio/instalación y no veo óptimo dejar esa BD abierta ya que cualquiera podría alterar los datos.

    El ejemplo seria un usuario que quita un registro de la TABLA de CAJA bien porque ese dinero quiere sustraerlo...por eso quiero un motor de BD con usuario y contraseña-

    Gracias,

    sábado, 3 de diciembre de 2016 19:24
  • En el caso de SQL Server Express estuve preguntando en otro post y me dijeron que por mucho que cree login para la BD , en local siempre se puede acceder a la BD siempre que se este loggeado en el sistema

    No, si está bien configurado no se puede. Desde luego, si usas una vulgar instancia de usuario, entonces sí que el usuario puede acceder como dbo. Pero si montas correctamente la BD en el motor de SQL, usando el directorio predeterminado "data" (al que no pueden acceder los usuarios), entonces no puede acceder nadie sin tener credenciales adecuadas. Y los que tengan credenciales adecuadas, solo pueden acceder a aquellas partes sobre las que les hayas concedido permisos a las credenciales en cuestión.

    En otras palabras, si le aplicas al SQL Server la misma configuración que al MySql, queda igual de protegido que éste. La cuestión es que a lo mejor has desarrollado el programa usando una de las configuraciones de baja seguridad, pero esto puedes reconfigurarlo con solo cambiar la cadena de conexión, y configurar bien el SQL Server, sin necesidad de modificar nada en el código del programa.
    • Editado Alberto PoblacionMVP sábado, 3 de diciembre de 2016 20:44
    • Marcado como respuesta golfgti6 sábado, 3 de diciembre de 2016 20:59
    • Desmarcado como respuesta golfgti6 sábado, 3 de diciembre de 2016 20:59
    sábado, 3 de diciembre de 2016 20:40
  • En el caso de SQL Server Express estuve preguntando en otro post y me dijeron que por mucho que cree login para la BD , en local siempre se puede acceder a la BD siempre que se este loggeado en el sistema

    No, si está bien configurado no se puede. Desde luego, si usas una vulgar instancia de usuario, entonces sí que el usuario puede acceder como dbo. Pero si montas correctamente la BD en el motor de SQL, usando el directorio predeterminado "data" (al que no pueden acceder los usuarios), entonces no puede acceder nadie sin tener credenciales adecuadas. Y los que tengan credenciales adecuadas, solo pueden acceder a aquellas partes sobre las que les hayas concedido permisos a las credenciales en cuestión.

    En otras palabras, si le aplicas al SQL Server la misma configuración que al MySql, queda igual de protegido que éste. La cuestión es que a lo mejor has desarrollado el programa usando una de las configuraciones de baja seguridad, pero esto puedes reconfigurarlo con solo cambiar la cadena de conexión, y configurar bien el SQL Server, sin necesidad de modificar nada en el código del programa.

    Vale entonces alguien me lo explico mal , busco información sobre como montar la instalación de SQL Server de esta forma , algún link o alguna idea?

    Gracias,

    sábado, 3 de diciembre de 2016 21:00
  • busco información sobre como montar la instalación de SQL Server de esta forma , algún link o alguna idea?

    Bueno, no se me ocurre ningún link salvo la documentación oficial de SQL Server. Pero el proceso básico es este:

    Lo primero hay que crear la base de datos en SQL Server (no en Visual Studio). Hay varias formas de hacer esto, todas las cuales requieren conectarse a SQL Server con credenciales administrativas. En principio, y salvo que lo hayas modificado, el único usuario que puede administrar SQL Server es el mismo que lo instaló.

    Yo prefiero conectarme con SQL Server Management Studio (puede ser la versión Express del SSMS si es que la tienes, sino es una descarga gratuita). También se puede hacer desde Visual Studio si lo tienes bien dominado. Desde SSMS puedes crear una nueva base de datos y luego rodar el script de creación del esquema para tu proyecto (si hiciste el script), o sino también puedes usar la opción "attach..." para "conectarle" el archivo .mdf que creaste desde Visual Studio. Primero mueve el .mdf y el .ldf a la carpeta DATA que hay bajo los directorios de SQL Server, que está protegida para que los usuarios comunes no puedan acceder (obviamente tendrás que entrar como administrador del sistema para poder mover ahí los ficheros).

    Una vez que la base de datos esté creada o adjuntada al motor de base de datos, usa las opciones de la pestaña "seguridad" en SSMS para asignar los Logins que quieres que puedan acceder a ella. Y después en tu programa cambia la cadena de conexión para que se conecte mediante el nombre de la base de datos en lugar del nombre del fichero, e incluye las credenciales necesarias en la cadena de conexión (de forma muy parecida a como lo harías si cambiases a MySql). Si no tienes dominado el tema de la cadena de conexión, ponnos aquí en el foro la cadena actual y te diremos cómo modificarla para que vaya a la base gestionada por SQL Server.

    Si te lías con el tema de los Logins y permisos en SQL Server, hay un foro específico de SQL Server en el que puedes preguntar estas cosas:

    https://social.msdn.microsoft.com/Forums/es-ES/home?forum=sqlserveres

    domingo, 4 de diciembre de 2016 10:36
  • busco información sobre como montar la instalación de SQL Server de esta forma , algún link o alguna idea?

    Bueno, no se me ocurre ningún link salvo la documentación oficial de SQL Server. Pero el proceso básico es este:

    Lo primero hay que crear la base de datos en SQL Server (no en Visual Studio). Hay varias formas de hacer esto, todas las cuales requieren conectarse a SQL Server con credenciales administrativas. En principio, y salvo que lo hayas modificado, el único usuario que puede administrar SQL Server es el mismo que lo instaló.

    Yo prefiero conectarme con SQL Server Management Studio (puede ser la versión Express del SSMS si es que la tienes, sino es una descarga gratuita). También se puede hacer desde Visual Studio si lo tienes bien dominado. Desde SSMS puedes crear una nueva base de datos y luego rodar el script de creación del esquema para tu proyecto (si hiciste el script), o sino también puedes usar la opción "attach..." para "conectarle" el archivo .mdf que creaste desde Visual Studio. Primero mueve el .mdf y el .ldf a la carpeta DATA que hay bajo los directorios de SQL Server, que está protegida para que los usuarios comunes no puedan acceder (obviamente tendrás que entrar como administrador del sistema para poder mover ahí los ficheros).

    Una vez que la base de datos esté creada o adjuntada al motor de base de datos, usa las opciones de la pestaña "seguridad" en SSMS para asignar los Logins que quieres que puedan acceder a ella. Y después en tu programa cambia la cadena de conexión para que se conecte mediante el nombre de la base de datos en lugar del nombre del fichero, e incluye las credenciales necesarias en la cadena de conexión (de forma muy parecida a como lo harías si cambiases a MySql). Si no tienes dominado el tema de la cadena de conexión, ponnos aquí en el foro la cadena actual y te diremos cómo modificarla para que vaya a la base gestionada por SQL Server.

    Si te lías con el tema de los Logins y permisos en SQL Server, hay un foro específico de SQL Server en el que puedes preguntar estas cosas:

    https://social.msdn.microsoft.com/Forums/es-ES/home?forum=sqlserveres

    Buenas  , cuando abro el SMMS yo me conecto de esta forma como vereis con la autentificación de windows.

    Podemos ver que los ficheros de la BD los tengo en la carpeta DATA , este paso es correcto verdad?
    Esto lo tengo asín desde el principio no he tocado nada.


    Y he creado un login "vsoft" 

    Pero con todo esto me sigue autenticando con el usuario de windows.

    Gracias.

    domingo, 4 de diciembre de 2016 20:56
  • Para entrar con un usuario que NO sea el de Windows, hay que hacer varias cosas. Primero, activa en SQl Server la seguridad en modo mixto (es una opcion que esta en la pestaña "seguridad" en las propiadades de la instancia en SSMS). Despues de cambiar esta opcion hay que reiniciar el servicio SQL.

    Despues de eso, crea un Login desde la pestaña Security de la instancia (no la Security de la base de datos, que es la que has mostrado en la imagen). A ese login asignale credenciales de SQL Server (no de Windows), incluyendo una password. Desde la misma ventana de creacion de Login puedes ponerle un mapping que lo mapee a un User de la base de datos, y asignarle privilegios sobre esa base de datos.

    Y finalmente, en tu cadena de conexion, quita el "Integrated Security=yes" (o similar, se puede escribir de varias formas), y a cambio ponle "user id=usuario;pwd=password" (evidentemente usando los valores que antes creaste en el login).

    Para que NO entre el usuario de Windows con autenticacion integrada, tendras que suprimir ese usuario de la lista de logins de SQL Server (o su grupo, si es que esta asignado a un grupo tal como "builtin\administrators"). Antes de suprimirlo, asegurate de que has añadido algun otro login con privilegios administrativos sobre SQL Server, para que puedas administrar el servidor usando este otro login. Por supuesto, al usuario final que maneja el equipo no le diras la password de este otro login recien creado.

    • Marcado como respuesta golfgti6 domingo, 18 de diciembre de 2016 12:18
    lunes, 5 de diciembre de 2016 13:19
  • Para entrar con un usuario que NO sea el de Windows, hay que hacer varias cosas. Primero, activa en SQl Server la seguridad en modo mixto (es una opcion que esta en la pestaña "seguridad" en las propiadades de la instancia en SSMS). Despues de cambiar esta opcion hay que reiniciar el servicio SQL.

    Despues de eso, crea un Login desde la pestaña Security de la instancia (no la Security de la base de datos, que es la que has mostrado en la imagen). A ese login asignale credenciales de SQL Server (no de Windows), incluyendo una password. Desde la misma ventana de creacion de Login puedes ponerle un mapping que lo mapee a un User de la base de datos, y asignarle privilegios sobre esa base de datos.

    Y finalmente, en tu cadena de conexion, quita el "Integrated Security=yes" (o similar, se puede escribir de varias formas), y a cambio ponle "user id=usuario;pwd=password" (evidentemente usando los valores que antes creaste en el login).

    Para que NO entre el usuario de Windows con autenticacion integrada, tendras que suprimir ese usuario de la lista de logins de SQL Server (o su grupo, si es que esta asignado a un grupo tal como "builtin\administrators"). Antes de suprimirlo, asegurate de que has añadido algun otro login con privilegios administrativos sobre SQL Server, para que puedas administrar el servidor usando este otro login. Por supuesto, al usuario final que maneja el equipo no le diras la password de este otro login recien creado.

    Muchas gracias , ya lo tengo asín.

    Ahora solo me queda como resolver el problema de encriptar el PASSWORD en la cadena de conexión del archivo app.config

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
        <configSections>
        </configSections>
        <connectionStrings>
            <add name="conexion" connectionString="Data Source=MI-PC\SQLEXPRESS;Initial Catalog=BDTest;User ID=usuario;Password=password;MultipleActiveResultSets=True" />
        </connectionStrings>
    <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/></startup>
    </configuration>

    Gracias

    domingo, 18 de diciembre de 2016 12:21
  • [...] ya lo tengo [...] Ahora solo me queda como resolver el problema de encriptar el PASSWORD en la cadena de conexión

    Solo viene "de fábrica" un comando para encriptar la cadena de conexión cuando la aplicación es de tipo web y el fichero de configuración es un web.config. Pero para el app.config, no hay nada estándar. Tendrás que recurrir a pasarlo manualmente a través de las rutinas de cifrado de System.Security.Cryptography. Probablemente tendrás que hacer un primer programa auxiliar que te pregunte la password sin cifrar, la pase por el algoritmo de cifrado, y te devuelva el resultado convertido en texto (por ejemplo, Convert.ToBase64). Después ese resultado lo pegas en la cadena de conexión, y en el programa en que la lees vuelves a usar System.Security.Cryptography para hacer el proceso al revés y descifrar la password, y después ya la insertas de vuelta dentro de la cadena de conexión.

    Nótese que el cifrado tiene un problema: en algún sitio hay que guardar la clave de cifrado para poder descifrar la contraseña cifrada. Si la clave la guardas en el mismo fichero .config, no hemos hecho nada. Si la escribes en el código fuente para que se salve dentro del ejecutable, se puede extraer descompilando el ejecutable. La solución buena es guardarla en Windows protegida por el Data Protection API (DPAPI). Pero eso implica que quien realice la instalación tiene que conocer la clave para poderla salvar. Y ya puestos a salvar algo en el DPAPI, para eso bien puedes salvar directamente la password de la base de datos y ahorrarte las rutinas de criptografía.

    domingo, 18 de diciembre de 2016 19:44
  • [...] ya lo tengo [...] Ahora solo me queda como resolver el problema de encriptar el PASSWORD en la cadena de conexión

    Solo viene "de fábrica" un comando para encriptar la cadena de conexión cuando la aplicación es de tipo web y el fichero de configuración es un web.config. Pero para el app.config, no hay nada estándar. Tendrás que recurrir a pasarlo manualmente a través de las rutinas de cifrado de System.Security.Cryptography. Probablemente tendrás que hacer un primer programa auxiliar que te pregunte la password sin cifrar, la pase por el algoritmo de cifrado, y te devuelva el resultado convertido en texto (por ejemplo, Convert.ToBase64). Después ese resultado lo pegas en la cadena de conexión, y en el programa en que la lees vuelves a usar System.Security.Cryptography para hacer el proceso al revés y descifrar la password, y después ya la insertas de vuelta dentro de la cadena de conexión.

    Nótese que el cifrado tiene un problema: en algún sitio hay que guardar la clave de cifrado para poder descifrar la contraseña cifrada. Si la clave la guardas en el mismo fichero .config, no hemos hecho nada. Si la escribes en el código fuente para que se salve dentro del ejecutable, se puede extraer descompilando el ejecutable. La solución buena es guardarla en Windows protegida por el Data Protection API (DPAPI). Pero eso implica que quien realice la instalación tiene que conocer la clave para poderla salvar. Y ya puestos a salvar algo en el DPAPI, para eso bien puedes salvar directamente la password de la base de datos y ahorrarte las rutinas de criptografía.

    La verdad que veo bastante complicado tu propuesta  , porque otra opción que fuese guardar el user y password en el código del proyecto y que en el APP.CONFIG recogiese el valor? eso como podría hacerlo?

    Teniendo en cuenta que tengo un app.config tal como este

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
        <configSections>
        </configSections>
        <connectionStrings>
            <add name="conexion" connectionString="Data Source=MI-PC\SQLEXPRESS;Initial Catalog=BDTest;User ID=usuario;Password=password;MultipleActiveResultSets=True" />
        </connectionStrings>
    <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/></startup>
    </configuration>

    Gracias


    • Editado golfgti6 lunes, 19 de diciembre de 2016 10:43
    domingo, 18 de diciembre de 2016 20:52
  • [...] otra opción que fuese guardar el user y password en el código del proyecto y que en el APP.CONFIG recogiese el valor?

    Si, se puede guardar en el ejecutable. Puedes directamente escribirlo en una constante de tipo string, o meterlo en los Resources. Pero esto NO lo tomará el app.config, tendrás que tomarlo desde el código fuente en el sitio donde vayas a abrir la conexión.

    Si haces esto, sigue existiendo el mismo problema que yo te comentaba en el sentido de que no es seguro. Cualquier usuario que tenga unos mínimos conocimientos técnicos puede fácilmente examinar el contenido del ejecutable y sacar de dentro la cadena de conexión, casi con la misma facilidad que si estuviese escrita en claro dentro del web.config. Nótese que este problema no es exclusivo de SQL Server, te pasaría lo mismo con la contraseña de cualquier otro motor de base de datos metida dentro de cualquier tipo de programa aunque no fuese de .Net.

    lunes, 19 de diciembre de 2016 11:08
  • [...] otra opción que fuese guardar el user y password en el código del proyecto y que en el APP.CONFIG recogiese el valor?

    Si, se puede guardar en el ejecutable. Puedes directamente escribirlo en una constante de tipo string, o meterlo en los Resources. Pero esto NO lo tomará el app.config, tendrás que tomarlo desde el código fuente en el sitio donde vayas a abrir la conexión.

    Si haces esto, sigue existiendo el mismo problema que yo te comentaba en el sentido de que no es seguro. Cualquier usuario que tenga unos mínimos conocimientos técnicos puede fácilmente examinar el contenido del ejecutable y sacar de dentro la cadena de conexión, casi con la misma facilidad que si estuviese escrita en claro dentro del web.config. Nótese que este problema no es exclusivo de SQL Server, te pasaría lo mismo con la contraseña de cualquier otro motor de base de datos metida dentro de cualquier tipo de programa aunque no fuese de .Net.

    He encontrado esta función en stackOverFLow

    You can encrypt sections of your app.config using DPAPI provider. Put your username/pwd pair in appSettings section. Nothing else need to change in your application. you still keep reading appsettings strings as usual. Use this code below to encrypt/decrypt parts of your config file.
    
    //call: ProtectSection("appSettings","DataProtectionConfigurationProvider"); 
    private void ProtectSection(string sectionName, string provider) 
    { 
        Configuration config = 
            WebConfigurationManager. 
                OpenWebConfiguration(Request.ApplicationPath); 
    
        ConfigurationSection section = config.GetSection(sectionName); 
    
        if (section != null && !section.SectionInformation.IsProtected) 
        { 
            section.SectionInformation.ProtectSection(provider); 
            config.Save(); 
        } 
    } 
    
    //call: UnProtectSection("appSettings"); 
    private void UnProtectSection(string sectionName) 
    { 
        Configuration config = 
            WebConfigurationManager. 
                OpenWebConfiguration(Request.ApplicationPath); 
    
        ConfigurationSection section = config.GetSection(sectionName); 
    
        if (section != null && section.SectionInformation.IsProtected) 
        { 
            section.SectionInformation.UnprotectSection(); 
            config.Save(); 
        } 
    } 

    Y lo estoy adaptando para mi caso que es winFORMS

    En mi caso tengo este código

    using System;
    using System.Collections.Generic;
    using System.Configuration;
    using System.IO;
    using System.Linq;
    using System.Text;
    using System.Threading.Tasks;
    
    namespace proyectoPRUEBAS.DL.clases
    {
        public class protectBD
        {
            //call: ProtectSection("appSettings","DataProtectionConfigurationProvider"); 
            public static void ProtectSection(string sectionName, string provider)
            {
                string appDataPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "proyectoTest", "proyectoTest");
                string configFileName = "proyectoTest.exe.config";
                var fileMap = new ExeConfigurationFileMap { ExeConfigFilename = Path.Combine(appDataPath, configFileName) };                
                Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
                    
                ConfigurationSection section = config.GetSection(sectionName);
    
                if (section != null && !section.SectionInformation.IsProtected)
                {
                    section.SectionInformation.ProtectSection(provider);
                    config.Save();
                }
            }
    
            //call: UnProtectSection("appSettings"); 
            public static void UnProtectSection(string sectionName)
            {
                string appDataPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "proyectoTest", "proyectoTest");
                string configFileName = "proyectoTest.exe.config";
                var fileMap = new ExeConfigurationFileMap { ExeConfigFilename = Path.Combine(appDataPath, configFileName) };
    
                Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);                
                ConfigurationSection section = config.GetSection(sectionName);
    
                if (section != null && section.SectionInformation.IsProtected)
                {
                    section.SectionInformation.UnprotectSection();
                    config.Save();
                }
    
            } 
        }
    }
    

    Lo estoy intentando adaptar pero no consigo ver el fallo.

    Gracias,

    lunes, 19 de diciembre de 2016 11:18
  • Así a simple vista tienen buen aspecto, no es obvio el fallo. Síguelo paso a paso con el debugger, verificando lo que hace en cada línea, hasta que tengas una idea más exacta de cuál es la instrucción concreta que está fallando, y cuales son los resultados que arroja y en qué sentido son diferentes de los esperados.
    lunes, 19 de diciembre de 2016 11:43