No me hace caso del fichero config

Pedro wrote:

Hola, tengo una aplicacion que utiliza una dll para obtener datos de
configuracion (string de conexion con la bbdd y algunos mas) llamada p.ej.
miclase.dll.
Bien, cuando instalo la aplicacion en otro PC, copio el fichero
miclase.dll.config creado durante el tiempo de desarrollo. En dicho
fichero logicamente cambio el string de conexion de la bbdd. Hasta aqui es
como creo que en todos los sitios que he leido se debe hacer.

Te coloco un tema muy interesante sobre donde guardar la cadena de conexion.
Puedes leer todo el tema en
http://msdn.microsoft.com/library/d...tml/Dp.asp
Haz click en enlace del frame de la izquierda 'Up one level'
y nuevamente en el frame de la izquierda sobre el enlace:
.NET Data Access Architecture Guide' (el 2º)

Storing Connection Strings

To store database connection strings, you have a variety of options with
different degrees of flexibility and security. Although hard coding a
connection string within source code offers the best performance, file
system caching ensures that the performance degradation associated with
storing the string externally in the file system is negligible. The extra
flexibility provided by an external connection string, which supports
administrator configuration, is preferred in virtually all cases.

When you are choosing an approach for connection string storage, the two
most important considerations are security and ease of configuration,
closely followed by performance.

You can choose among the following locations for storing database connection
strings:

* In an application configuration file; for example, Web.config for an
ASP.NET Web application
* In a Universal Data Link (UDL) file (supported only by the OLE DB .NET
Data Provider)
* In the Windows registry
* In a custom file
* In the COM+ catalog, by using construction strings (for serviced
components only)

By using Windows authentication to access SQL Server, you can avoid storing
user names and passwords in connection strings. If your security
requirements demand more stringent measures, consider storing the
connection strings in encrypted format.

For ASP.NET Web applications, storing the connection strings in encrypted
format within the Web.config file represents a secure and configurable
solution.

Note You can set the Persist Security Info named value to false in the
connection string to prevent security-sensitive details, such as the
password, from being returned by means of the ConnectionString property of
the SqlConnection or OleDbConnection objects.

The following subsections discuss how to use the various options to store
connection strings, and they present the relative advantages and
disadvantages of each approach. This will allow you to make an informed
choice based on your specific application scenario.

Note The Configuration Application Management block allows you to
manage configuration settings—from database connections to complex
hierarchical data. For more information, see
http://msdn.microsoft.com/practices.

Using XML Application Configuration Files

You can use the <appSettings> element to store a database connection string
in the custom settings section of an application configuration file. This
element supports arbitrary key-value pairs, as illustrated in the following
fragment:

<configuration>
<appSettings>
<add key="DBConnStr"
value="server=(local);Integrated Security=SSPI;database=northwind"/>
</appSettings>
</configuration>


Note The <appSettings> element appears under the <configuration>
element and not directly under <system.web>.

Advantages

* Ease of deployment. The connection string is deployed along with the
configuration file through regular .NET xcopy deployment.
* Ease of programmatic access. The AppSettings property of the
ConfigurationSettings class makes reading the configured database
connection string an easy task at run time.
* Support of dynamic update (ASP.NET only). If an administrator updates
the connection string in a Web.config file, the change will be picked up
the next time the string is accessed, which for a stateless component is
likely to be the next time a client uses the component to make a data
access request.

Disadvantages

* Security. Although the ASP.NET Internet Server Application Programming
Interface (ISAPI) dynamic-link library (DLL) prevents clients from directly
accessing files with a .config file extension and NTFS permissions can be
used to further restrict access, you might still want to avoid storing
these details in clear text on a front-end Web server. For added security,
store the connection string in encrypted format in the configuration file.

More Information

* You can retrieve custom application settings by using the static
AppSettings property of the System.Configuration.ConfigurationSettings
class. This is shown in the following code fragment, which assumes the
previously illustrated custom key called DBConnStr:

using System.Configuration;
private string GetDBaseConnectionString()
{
return ConfigurationSettings.AppSettings["DBConnStr"];
}


* For more information about configuring .NET Framework applications,
see
http://msdn.microsoft.com/library/e...tions.asp.

Using UDL Files

The OLE DB .NET Data Provider supports Universal Data Link (UDL) file names
in its connection string. You can pass the connection string by using
construction arguments to the OleDbConnection object, or you can set the
connection string by using the object's ConnectionString property.

Note The SQL Server .NET Data Provider does not support UDL files in
its connection string. Therefore, this approach is available to you only if
you are using the OLE DB .NET Data Provider.

For the OLE DB provider, to reference a UDL file with the connection string,
use "File Name=name.udl."
Advantages

* Standard approach. You might already be using UDL files for connection
string management.

Disadvantages

* Performance. Connection strings that contain UDLs are read and parsed
each time the connection is opened.
* Security. UDL files are stored as plain text. You can secure these
files by using NTFS file permissions, but doing so raises the same issues
as with .config files.
* SqlClient does not support UDL files. This approach is not supported
by the SQL Server .NET Data Provider, which you use to access SQL Server
7.0 and later.

More Information

* To support administration, make sure that administrators have
read/write access to the UDL file and that the identity used to run your
application has read access. For ASP.NET Web applications, the application
worker process runs by using the SYSTEM account by default, although you
can override this by using the <processModel> element of the machine-wide
configuration file (Machine.config). You can also impersonate, optionally
with a nominated account, by using the <identity> element of the Web.config
file.
* For Web applications, make sure that you do not place the UDL file in
a virtual directory, which would make the file downloadable over the Web.
* For more information about these and other security-related ASP.NET
features, see "Authentication in ASP.NET: .NET Security Guidance," at
http://msdn.microsoft.com/library/e...otnet.asp.

Using the Windows Registry

You can also use a custom key in the Windows registry to store the
connection string, although this is not recommended due to deployment
issues.
Advantages

* Security. You can manage access to selected registry keys by using
access control lists (ACLs). For even higher levels of security, consider
encrypting the data.
* Ease of programmatic access. .NET classes are available to support
reading strings from the registry.

Disadvantages

* Deployment. The relevant registry setting must be deployed along with
your application, somewhat defeating the advantage of xcopy deployment.

Using a Custom File

You can use a custom file to store the connection string. However, this
technique offers no advantages and is not recommended.
Advantages

* None.

Disadvantages

* Extra coding. This approach requires extra coding and forces you to
deal explicitly with concurrency issues.
* Deployment. The file must be copied along with the other ASP.NET
application files. Avoid placing the file in the ASP.NET application
directory or subdirectory to prevent it from being downloaded over the Web.

Using Construction Arguments and the COM+ Catalog

You can store the database connection string in the COM+ catalog and have it
automatically passed to your object by means of an object construction
string. COM+ will call the object's Construct method immediately after
instantiating the object, supplying the configured construction string.

Note This approach works only for serviced components. Consider it
only if your managed components use other services, such as distributed
transaction support or object pooling.

Advantages

* Administration. An administrator can easily configure the connection
string by using the Component Services MMC snap-in.

Disadvantages

* Security. The COM+ catalog is considered a non-secure storage area
(although you can restrict access with COM+ roles) and therefore must not
be used to maintain connection strings in clear text.
* Deployment. Entries in the COM+ catalog must be deployed along with
your .NET-based application. If you are using other enterprise services,
such as distributed transactions or object pooling, storing the database
connection string in the catalog presents no additional deployment
overhead, because the COM+ catalog must be deployed to support those other
services.
* Components must be serviced. You can use construction strings only for
serviced components. You should not derive your component's class from
ServicedComponent (making your component serviced) simply to enable
construction strings.

Important It is critical to secure connection strings. With SQL
authentication, the connection contains a user name and password. If an
attacker exploits a source code vulnerability on the Web server or gains
access to the configuration store, the database will be vulnerable. To
prevent this, connection strings should be encrypted. For descriptions of
different methods available to encrypt plaintext connection strings, see
Improving Web Application Security: Threats and Countermeasures, which will
be available at http://www.microsoft.com/practices.

More Information

* For more information about how to configure a .NET class for object
construction, see How To Enable Object Construction For a .NET Class in the
appendix.
* For more information about developing serviced components, see
http://msdn.microsoft.com/library/e...nents.asp.
* For general guidance on developing secure ASP.NET and Web
applications, refer to the following Microsoft patterns & practices guides:
o Volume I, Building Secure ASP.NET Applications: Authentication,
Authorization, and Secure Communication, available at
http://www.microsoft.com/practices
o Volume II, Improving Web Application Security: Threats and
Countermeasures, which will be available at
http://www.microsoft.com/practices

Pues bien, el resultado es que no hace ni caso a este archivo, y como
curiosidad, si por ejemplo abro con el block de notas el fichero
miclase.dll puedo ver el string de conexion de mi PC de desarrollo que es
al que hace caso, pero el config como si no existiera. Por favor estoy
frustado y desesperado, ¿¿¿¿que estoy haciendo mal ????

Ayudaria mucho que mostraras el codigo

Desde Aguadulce - España
Carlos Gomez

Bien, cuando instalo la aplicacion en otro PC, copio el fichero
miclase.dll.config creado durante el tiempo de desarrollo.

Aqui esta el primer problema. Los archivos de configuracion no son para DLLs
sino para EXEs. Tu dll entonces leera el archivo de configuracion del
ejecutable que la use.

Pues bien, el resultado es que no hace ni caso a este archivo, y como
curiosidad, si por ejemplo abro con el block de notas el fichero
miclase.dll puedo ver el string de conexion de mi PC de desarrollo
que es al que hace caso, pero el config como si no existiera.

Aqui veo otro problema. Primero, que si la cadena de conexion (o cualquier
dato) se lee desde el app.config no veo por que tienes una cadena escrita en
el codigo. Y otro punto, ¿estas leyendo la del config? Pregunto porque si
dices que funciona entonces no esta leyendo del config porque deberias estar
recibiendo una cadena de conexion vacia ya que no la tenias en el app.config
(por estar en el archivo equivocado) lo que causaria un error al intentar
conectar.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Vale, el primer punto no lo sabía, pero respecto a tu segundo comentario te
diré que cuando estoy desarrollando, si por ejemplo cambio en el app.config
del proyecto que luego genera la dll al compilar, me hace caso a lo que le
indico, es decir, que me coge los valores configurados en dicho fichero.
Entonces, ¿eso no significa que me está haciendo caso al app.config del
proyecto de la dll?. De hecho no tengo ningun archivo de configuracion para
el proyecto que genera el exe y consume la dll.
Por lo que disculpa Eduardo, pero no lo acabo de entender.

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

> Bien, cuando instalo la aplicacion en otro PC, copio el fichero
> miclase.dll.config creado durante el tiempo de desarrollo.

Aqui esta el primer problema. Los archivos de configuracion no son para

DLLs

sino para EXEs. Tu dll entonces leera el archivo de configuracion del
ejecutable que la use.

> Pues bien, el resultado es que no hace ni caso a este archivo, y como
> curiosidad, si por ejemplo abro con el block de notas el fichero
> miclase.dll puedo ver el string de conexion de mi PC de desarrollo
> que es al que hace caso, pero el config como si no existiera.

Aqui veo otro problema. Primero, que si la cadena de conexion (o cualquier
dato) se lee desde el app.config no veo por que tienes una cadena escrita

en

el codigo. Y otro punto, ¿estas leyendo la del config? Pregunto porque si
dices que funciona entonces no esta leyendo del config porque deberias

estar

recibiendo una cadena de conexion vacia ya que no la tenias en el

app.config

(por estar en el archivo equivocado) lo que causaria un error al intentar
conectar.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

http://mvp.support.microsoft.com/pr...4EF5A4191C

¿Estas usando VB2005? ¿Estas usando My.Settings? Si estas usando
My.Settings, el valor que tengas en el app.config del proyecto de la DLL
queda como valor por defecto cuando la compilas. Ese puede ser el motivo por
el cual encuentras la cadena de conexion en el codigo y que aparentemente
funcione el app.config de la dll.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Yep, has dado en el clavo, es VB2005 y usaba My.Settings. Vaya, pues no
sabia eso que se compilase por defecto, (eso no sale en ningún manual,
¿eh?). Bueno como ves, no sé muchas cosas. Pero lo que más me sorprende es
que para una dll no puedas tener un config.
Pues ahora me has dejado de piedra, en fin, que no sé ahora muy bien como
hacerlo.

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:%

¿Estas usando VB2005? ¿Estas usando My.Settings? Si estas usando
My.Settings, el valor que tengas en el app.config del proyecto de la DLL
queda como valor por defecto cuando la compilas. Ese puede ser el motivo

por

el cual encuentras la cadena de conexion en el codigo y que aparentemente
funcione el app.config de la dll.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

http://mvp.support.microsoft.com/pr...4EF5A4191C