studio - ¿Por qué no se almacenan en el registro las “configuraciones de la aplicación” de.NET?

que es app config (17)

Hace algún tiempo, en los años noventa, Microsoft introdujo el Registro de Windows. Las aplicaciones pueden almacenar configuraciones en diferentes colmenas. Hubo colmenas para los ámbitos de aplicación y específicos del usuario, y se colocaron en ubicaciones adecuadas, de modo que los perfiles móviles funcionaron correctamente.

En .NET 2.0 y versiones superiores, tenemos esta cosa llamada Configuración de aplicaciones . Las aplicaciones pueden usarlas para almacenar configuraciones en archivos XML, app .exe.config y usuario .config. Estos son para ámbitos específicos de la aplicación y específicos del usuario, y se colocan en ubicaciones apropiadas, de modo que los perfiles móviles funcionen correctamente.

¿Suena familiar? ¿Cuál es la razón por la que estas configuraciones de la aplicación están respaldadas por archivos XML, en lugar de simplemente usar el registro? ¿No es esto exactamente para lo que estaba destinado el registro?

La única razón por la que puedo pensar es que el registro es específico de Windows y .NET intenta ser independiente de la plataforma. ¿Fue esta una razón (o la ), o hay otras consideraciones que estoy pasando por alto?

en lugar de simplemente usar el registro

El registro no es simple . En mi PC, es un desastre binario de 40MB, y espero que los bits que contiene no cambien de opinión.

¿No es esto exactamente para lo que estaba destinado el registro?

Sí. Pero, de nuevo, las DLLs pretendían proporcionar funcionalidad compartida a diferentes aplicaciones.

Creo que hay un gran problema de seguridad en la configuración de la aplicación (archivos .config), que se puede editar en cualquier editor de texto y cambiar todo.

Digamos que una cadena de conexión está almacenada y que algunos eliminaron o cambiaron todos los valores en el archivo de configuración, entonces la aplicación tendrá una gran cantidad de recursos, por lo que el archivo de configuración debería estar protegido.

o almacenar la configuración en el archivo DLL, por ejemplo.

Creo que la nueva forma de archivo .config ayuda por:

Ofrezca a las aplicaciones la flexibilidad de proporcionar sus propias configuraciones como una anulación de las configuraciones predeterminadas provistas - considere el caso de web.config anulando la máquina.config
A veces, puede que no sea posible cambiar la configuración del registro, ya que es posible que no tenga los derechos necesarios. Por lo tanto, un archivo de configuración le permite realizar cambios aplicables a su propia aplicación sin necesidad de derechos adicionales
Con una entrada de registro, la aplicación múltiple podría estar usando la misma configuración. Pero si lo cambia para su aplicación, puede causar un comportamiento no deseado en otras aplicaciones y es posible que no tenga información completa sobre esto.

Sólo algunos pensamientos que vienen a la mente ...

HTH.

Creo que una de las razones principales para esto fue la actualización de la aplicación. Cuando instala una actualización (es decir, con ClickOnce), la nueva configuración se coloca en una nueva carpeta. Cuando lo desinstala, la nueva carpeta se borra y las configuraciones antiguas siguen existiendo. Si se utilizara el registro en su lugar, no habría manera de hacer este "control de versiones".

Otras razones pueden incluir:

Permisos (la configuración de la aplicación siempre va a AppData / LocalAppData que no requiere privilegios)
Facilidad de mantenimiento / copias de seguridad
Portabilidad (es bastante difícil lidiar con el registro utilizando .NET Compact Framework, y Dios te ayuda si estás tratando de soportar Mono).

Es porque el registro es una pesadilla fea de usar, y a la gente no le gustó. Tampoco es compatible con la implementación de xcopy. Con el uso de archivos xml para la configuración, puede mover una aplicación de una máquina a otra sin la necesidad de un instalador. Esta fue una de las quejas más importantes al escribir un código en los años 90.

Con el registro, debe otorgar a alguien permiso para modificarlo cuando instale la aplicación que en muchas organizaciones está prohibida. Para modificar la configuración de una aplicación, también debe saber dónde buscar en el registro, lo cual es difícil en muchos casos. Con el archivo de configuración, ahí está segregado de la mayoría de las otras aplicaciones. Normalmente, todas las configuraciones que necesita están ahí para una fácil visualización y modificación.

Escuché un rumor bastante importante de que el formato de almacenamiento de datos utilizado por sharepoint y por el servidor de Team Foundation, respaldado por SQL, originalmente fue pensado para reemplazar el sistema de archivos de Windows en Windows 7. Si este era el plan, entonces Windows habría ganado / ( ¿Algún día?) obtendrá un almacén de datos transaccional para almacenar listas de datos. Este método de almacenamiento de datos probablemente sería superior en todos los aspectos al registro.

Dado esto, no es sorprendente que Microsoft minimice el uso del registro a medida que avanzan con el marco .net.

La portabilidad de la aplicación puede ser una de las razones. Las carpetas de la aplicación se pueden copiar de una computadora a otra y la configuración irá con la aplicación. Útil cuando se ejecutan aplicaciones desde unidades flash USB en varias computadoras.

Me atrevería a suponer que la facilidad de despliegue remoto era un factor decisivo.

Me parece que el registro es una de esas cosas que "parecían ser una buena idea en ese momento", por todas las razones ya enumeradas por otros. No hay nada de malo en darse cuenta de que algo no era una idea tan buena después de todo, y en su lugar usar una alternativa que sea más simple y conveniente, incluso si puede parecer un paso atrás en ciertos aspectos.

Microsoft sugirió ambas formas, porque tienen capacidades diferentes. Por ejemplo, si crea alguna aplicación para usar en Active Directory, puede modificar fácilmente la configuración de miles de computadoras, incluso su aplicación instalada en directorios diferentes. Si elige xml, debe conocer las carpetas de aplicaciones para cada PC o crear un script inteligente para encontrarlas. Pero como mucha gente dijo xml mejor para la portabilidad, la configuración de copia de seguridad y otros.

Por lo tanto, no hay mejor manera. Desarrolladores que necesitan registro - usándolo directamente. No es tan difícil. Probablemente es por eso que Microsoft no hizo la configuración de la aplicación en el registro.

No creo que esta sea una cuestión de ser plataforma independiente. Muchas aplicaciones se han desarrollado en el pasado en Linux, Mac y Windows, algunas usando archivos de configuración y otras en el registro.

Creo que la razón principal viene de la "experiencia COM". Todo el principio era tener objetos componentes registrados centralmente en el registro para que cualquier aplicación pudiera usarlos sin tener que copiar la dll. Esto nos lleva rápidamente a problemas de versionamiento. Múltiples aplicaciones difícilmente podrían usar diferentes versiones de un mismo componente.

Con las configuraciones en el registro tienes el mismo problema. Tener dos versiones de una misma aplicación puede ser un problema real si el desarrollo no se realizó correctamente. Tuvimos este tipo de problemas con el uso de varias versiones de Oracle hace mucho tiempo.

Con .Net y la capacidad de explosión de los discos duros y el ancho de banda, la duplicación de archivos ya no es una preocupación. La copia de las dependencias en el proyecto de su carpeta simplifica en gran medida la implementación de la aplicación. Lo mismo se aplica a los archivos de configuraciones. Puede alojar varias copias / versiones de la misma aplicación sin tener problemas con la arquitectura de máquina / usuario limitada del Registro.

No creo que sea una respuesta, creo que es una combinación:

El registro en el momento de crearlo parecía una buena idea para almacenar todas las configuraciones de todos los programas en un solo lugar, en oposición a los archivos .ini que generalmente se usan antes. En el momento en que este aumento del rendimiento, dado que las lecturas de pequeños archivos .ini de discos duros lentos eran costosos, un solo archivo de registro incrementó algo el rendimiento. Ahora es diferente, ya que los discos duros son mucho más rápidos y cada vez se han volcado más configuraciones en el registro, lo que hace que sea una carga para el sistema. Verá esto si instala y desinstala muchos programas en Windows, comienza a disminuir la velocidad y, finalmente, probablemente termine de formatear.
Una escritura incorrecta en el registro, incluso en la configuración de usuario actual, puede arruinar su sistema.
El registro no ayuda a la implementación xcopy de programas sin un código específico para manejar la falta de claves de registro ... Esto incluye eliminar programas simplemente eliminando la carpeta en muchos casos
Se pueden necesitar mayores permisos para instalar una aplicación si necesita acceso al registro
Un archivo .config permite fácilmente la configuración predeterminada de la aplicación y el usuario, que el usuario final puede modificar en la primera ejecución del programa.
Permite que .NET se ejecute potencialmente en otros sistemas sin un código específico del sistema operativo. Esto se puede ver de alguna manera con Silverlight y el almacenamiento aislado.
Mayor seguridad mediante el uso de almacenamiento aislado para la aplicación y los usuarios.
Da a Microsoft la posibilidad de tener en el futuro un sistema operativo con código administrado sin muchas dependencias antiguas. Piense en el marco como una capa entre cualquier sistema operativo y el código administrado.

Otra razón es que para editar el registro, tendría que tener mayores cantidades de permisos. Si solo está editando un archivo de configuración de la aplicación, solo necesita tener derechos sobre ese archivo.

Tomar una dependencia en el registro evita la implementación de XCOPY .

Una gran ventaja de pasar a los archivos de configuración sobre el registro es permitir instalaciones paralelas del mismo programa. Con el registro, la información de configuración central se superpondría para estas instalaciones duplicadas, pero al usar los archivos de configuración, la información se mantiene privada para cada instalación específica. Es cierto que los reemplazos de configuración específicos del usuario podrían superponerse (ya que se almacenan en la carpeta de datos de la aplicación del usuario, no específica a la ruta de instalación), pero imagina un escenario en el que diferentes usuarios usan instalaciones diferentes, en cuyo caso este problema potencial se convierte irrelevante.

Una ventaja inmediata (pero importante):

Con los archivos de configuración plain , los usuarios pueden restaurar su configuración fácilmente en caso de una reinstalación / restauración desde la copia de seguridad. Es mucho más difícil hacer esto desde los valores del registro.

El registro es enorme, por lo que puede ser complicado ubicar la información relevante (incluso con la búsqueda).
Es posible afectar a otras aplicaciones por accidente al modificar el registro.
Si el registro está dañado, todas las aplicaciones pueden verse afectadas (incluido el sistema operativo).
Necesita herramientas especiales para buscar, modificar e incluso copiar el registro.

Prefiero los archivos de configuración.