18

Entonces, creé mi modelo de entidad en una biblioteca de clases separada. Tuve que agregar la cadena de conexión al archivo app.config de esa biblioteca de clases. Luego agregué una referencia para ese proyecto en mi aplicación web. Agregué la misma cadena de conexión en el web.config de mi aplicación web pensando que aquí es donde Entity Framework leerá la cadena de conexión.¡Espera! ¿Qué archivo de configuración? (Entity Framework Connection String)

Todo fue bien hasta que implementé mi aplicación web. Cuando implementé, cambié la cadena de conexión en el web.config (no en el app.config de la biblioteca de clases) y empecé a recibir errores. Después de investigar un poco, descubrí que la cadena de conexión tanto en web.config como en app.config debe coincidir.

¡Esto es simplemente tonto! Cada vez que tengo que implementar mi aplicación web en un entorno diferente, debo regresar y modificar la cadena de conexión en el archivo app.config y luego recompilar mi proyecto de biblioteca de clase solo para que pueda obtener la cadena de conexión actualizada.

¿Alguien ha encontrado una mejor manera de hacerlo? Quiero decir, no puedo ser la única persona que pensó en poner el modelo de entidades en una asamblea separada.

Solución posible (si está utilizando EF 4.1): Dado que la única razón por la que necesitamos tener app.config dentro de un proyecto de biblioteca de clases es para el diseñador de EF. Si abandonamos el enfoque de diseñador e implementamos Code-First (EF 4.1), no necesitará tener un archivo app.config para su proyecto de biblioteca de clase.

+4

Tengo exactamente la misma configuración, pero no tengo este problema en absoluto. Todo lo que hago es modificar el web.config y funciona correctamente. El app.config no está implementado, ese podría ser tu problema. –

+0

Pensé que estabas en algo, pero lo verifiqué y no estoy copiando/implementando app.config ... de una forma u otra el dll sabe cuando dos cadenas de conexión (una en app.config y una en web.config) no coinciden. Si mi cadena de conexión web.config simplemente sobrescribiera la aplicación, la vida sería buena, pero no está sucediendo. – Robert

Respuesta

12

Nos encontramos con la misma situación. Le pedí a cada desarrollador que solo compilara el ensamblaje de EF con la primera cadena de conexión seleccionada.

De esta manera, cuando se implementa, solo se necesita una cadena de conexión en el web.config.

Eventualmente, si cada máquina de desarrollo y servidor de implementación tiene la información de conexión correcta (para esa máquina) en la primera (y afortunadamente) cadena de conexión (es decir, no ConnectionString4), la vida es fácil.

Básicamente, el diseñador agrega cadenas de conexión adicionales a la cadena de conexión dev cuando la cadena de conexión predeterminada (última selección) no se puede conectar.

Además, no hay razón para sentirse mal por poner la capa de datos en un ensamblaje por separado. Algunas veces esto es preferible.

Finalmente, es muy importante asegurarse de que el archivo de configuración que contiene la cadena de conexión no esté enganchado al control de origen; la cadena de conexión a menudo se localiza y causará el "problema de cadena de conexión múltiple" en EF y LINQ to SQL si se sobrescribe con valores incorrectos cada vez que actualiza su proyecto desde el control de origen.

Cuestiones relacionadas