Entity Framework not working when in separate project from MVC3 web application project
I have an Entity Framework project and a repository class in a separate project from my MVC3 web application. I have set a link in my MVC project for the Entity Framework Data Project so that I can instantiate the repository and call its methods. However, I am getting the error:
The specified named connection is either not in configuration, not intended for use with the EntityClient provider, or is invalid.
I've run into this before and I believe the solution is to include the connection string from the entity framework app.config file into the MVC web.config file.
It doesn't suit me. It looks like there should be another way that makes the projects less tightly coupled. Am I dreaming or is there a best practice that would let me just call the referenced DLL and be done with it?
thank
source to share
The file app.config
that is included in the Entity Framework project DLL contains a connection string that is used by the EDMX designer to find the target database when running the Update Model from Database command.
When you deploy your application, the only configuration file that is known is web.config
. The file app.config
from your EF-dll is not used in production.
So, in your web.config, you include the connection string that is used when the MVC application starts. When using transforms, you can also specify different connection strings for different deployment scenarios (such as testing and production).
So it doesn't look like you are introducing any connection. You are simply using the customization methods that .NET offers you.
source to share
There are ways to hard-code a connection string in your repository, and using it when creating a context comes to mind, but you certainly don't want to use them. The correct way to handle this is through a config file. You really don't want it to use the config file from the DLL, as that would give you less control over the connection string used. This would make it more difficult rather than easier to have different connection strings for integration testing, organization and production. Although it is possible to combine the approach (a fixed connection string that can be overridden by a config parameter), using both of my preferences for a fully config-driven approach. I love the single agreement and one-time step of updating the Web.Config (and any transformations) with the correct configuration seems to be a low cost to pay for a simple configuration usage agreement at all times.
source to share
I don't understand how placing the connection string in the MVC project config file makes it "tightly coupled". The configuration files themselves are the source of the loose coupling. You can always change the connection strings using config transforms, which means you can switch the connection string by simply choosing a different solution configuration.
source to share