.net - tipo - ¡Espere! ¿Qué archivo de configuración?(Entity Framework Connection String)
se produjo una excepción en el inicializador de tipo de extentplaceholdercreator (1)
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.
Todo estuvo bien hasta que implementé mi aplicación web. Cuando implementé, cambio la cadena de conexión en web.config (no app.config de la biblioteca de clases) y comencé a recibir errores. Después de investigar un poco, descubrí que la cadena de conexión tanto en web.config como en app.config deben coincidir.
¡Esto es simplemente tonto! ¿Cada vez que necesito 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 volver a compilar mi proyecto de biblioteca de clases para que pueda obtener la cadena de conexión actualizada?
¿Alguien ha encontrado una mejor manera de hacer esto? Quiero decir, no puedo ser la única persona que pensó en poner el modelo de entidad en un conjunto separado.
Posible solución (si está utilizando EF 4.1): 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 del diseñador y seguimos con Code-First (EF 4.1) no necesitará tener un archivo app.config para su proyecto de biblioteca de clases.
Nos topamos con la misma situación. Le he pedido a cada desarrollador que compile solo 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 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 cadena de conexión (y es de esperar solamente) (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 (la última seleccionada) no puede conectarse.
Además, no hay razón para sentirse mal por colocar la capa de datos en un ensamblaje separado. A 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 fuente; la cadena de conexión a menudo se localiza y causará el "problema de cadena de conexión múltiple" en EF y LINQ a SQL si se sigue sobrescribiendo con valores incorrectos cada vez que actualiza su proyecto desde el control de origen.