Question: using registry to store conn string

Topics: Data Access Application Block
Jun 21, 2007 at 4:36 PM
I recently installed EntLib 3.1 and I want to use the Data Access block to build the database layer. And I also need to store the connection string (encrypted) in the registry, do I still need to use the configuration source. Do I simply write a class that extends the Cryptography Application Block to access the registry and decrypt the conn values?
Jun 21, 2007 at 8:26 PM

You don't need to use configuration to use the DAAB; you can just instantiate the Database instance you want providing the connection string in the constructor call. Of course, you would loose the ability to create a database instance through a factory by supplying a connection string name and instrumentation would not be wired up unless you do it manually, but that might not be an issue in your scenario.

Jun 21, 2007 at 9:16 PM
So using DAAB and encrypting the config file is a better option then?
Jun 22, 2007 at 12:40 PM
I believe it is.

Accessing the registry will require a different "trust" model, so it may not work in a hosted environment. Also, the registry can be an I/O bottleneck.

The nice thing is you don't have to write any code at all to encrypt the connection string, this is built into EntLib.
Jun 22, 2007 at 3:24 PM
It might be better depending on your scenario. You mentioned the need store encrypted connection strings in the registry, so if that is a hard requirement (a policy maybe?) then storing connection strings in a file is not a solution. If you are allowed to store the encrypted connection strings in a file then you can use the built in support for encryption (which is actually provided by the .NET framework).

You might also want to take a look at the "manageablility" support, that lets you specify configuration information overrides through group policies which are ultimately stored in the registry. The current implementation does not support encryption, but you can modify it to support it.

Jun 22, 2007 at 3:58 PM
Thank you both the response.
1. Do you happen to know any good links that explains the "manageablility" support you mentioned?

2. By not using the config file, I lost creating the "database instance through a factory" other words, i lost the following benefits....
*can't easily switch database providers via the config file
*can't use the config tool to manage the config file
*the database conn is no longer transparent to the code

Am I correct? Did I miss any other advantages of using the config file?

Again, thank you for your help!