asked on Entity Framework with Connection String in Seperate Project
HI all,
I'm after some best practise advice here.
I currently has an Entity Framework edmx held in a seperate project. The connection string is held in the app.config of this project.
Now when I try and create an instance of myDbContext() from the seperate project I get the message that the connection string does not exist. From googling this appear to be because it looks for the connection string in the local project.
Coudl someone please help me find a solution where I can (maybe by using a helper method). Keep the connection string contained in the Entity project? i.e. so I can just call the dbCOntext without having to have multiple connection strings across my projects?
Thansk in advance.
Matt
I'm after some best practise advice here.
I currently has an Entity Framework edmx held in a seperate project. The connection string is held in the app.config of this project.
Now when I try and create an instance of myDbContext() from the seperate project I get the message that the connection string does not exist. From googling this appear to be because it looks for the connection string in the local project.
Coudl someone please help me find a solution where I can (maybe by using a helper method). Keep the connection string contained in the Entity project? i.e. so I can just call the dbCOntext without having to have multiple connection strings across my projects?
Thansk in advance.
Matt
.NET ProgrammingC#ASP.NET
Last Comment
flynny
If you have a separate, that means that it is a .Dll. The App.Config file of a class library is created by the designer because it doesn't where else to put stuff. But when your class library is used by an application, the App.Config of that application needs to have everything in it (all others are just ignored).
ASKER
Hi Eric,
Thanks for your reply.
Sorry, I understand why the app.config file is not reading the connection string, however, is it possible for me to somehow reference a single connection string (maybe from a helper method) and pass it through to my context?
Like I said I am looking at best practise and open to suggestions, basically I would rather just have a single connection string entry rather than have to woory about multiple connections string in each project access in the entity solution.
Thanks for your reply.
Sorry, I understand why the app.config file is not reading the connection string, however, is it possible for me to somehow reference a single connection string (maybe from a helper method) and pass it through to my context?
Like I said I am looking at best practise and open to suggestions, basically I would rather just have a single connection string entry rather than have to woory about multiple connections string in each project access in the entity solution.
I don't understand why you would have multiple connection strings.
The designer will create one and put it in the App.Config of your class library. You then need to copy this section to your application's own App.Config and you are good to go.
Do you have multiple .EXE projects all accessing the same EF class library? This is the only time I could think where you get multiple App.Config/connection strings.
The designer will create one and put it in the App.Config of your class library. You then need to copy this section to your application's own App.Config and you are good to go.
Do you have multiple .EXE projects all accessing the same EF class library? This is the only time I could think where you get multiple App.Config/connection strings.
Hi Flynny,
Is your connection string ever going to change or will it have the capability of being changed?
-saige-
P.S. --> What EF version are we talking about here?
Is your connection string ever going to change or will it have the capability of being changed?
-saige-
P.S. --> What EF version are we talking about here?
One other question, are the csdl, ssdl and msl a part of the same library? (meaning that the library you have the connection string defined in, is the model a part of that same library).
If it is, I am assuming that the model will be referenced (or should be referenceable) from external assemblies.
-saige-
If it is, I am assuming that the model will be referenced (or should be referenceable) from external assemblies.
-saige-
ASKER
Hi Guys,
Thanks for the help guys and sorry for the late reply
Basically, I was hoping to have some kind single entry point so if the db connections ever did change I would only have to change one point.
I have a number of solutions using the entity solution, all different functions.
I have a helper functions solution. Would it be best practise to maybe store the db connection in a static string in here and ref it when creating a context in my other solutions?
Also would it be possible to have the entity framework solution refrence it rather than the one in its config file?
Thanks for the help guys and sorry for the late reply
Basically, I was hoping to have some kind single entry point so if the db connections ever did change I would only have to change one point.
I have a number of solutions using the entity solution, all different functions.
I have a helper functions solution. Would it be best practise to maybe store the db connection in a static string in here and ref it when creating a context in my other solutions?
Also would it be possible to have the entity framework solution refrence it rather than the one in its config file?
EF designers updates the config file in the project it is living because it doesn't know which other project to affect. Your connection strings surely don't change often enough to be a real show stopper.
ASKER
Hi Eric,
No its not, I just wanted to try and alleviate as many issues as possible and keep it simple.
Realistically they will not change either. The idea is mainly to try and keep the db access seperate from the other projects. Also is the connection string is stored in DLL rather than a config file the user password details are kept away from the main project (or am I wrong does this get pulled away at compile time?).
Whilst this isnt an issue currently we are just trying to plan for the future.
So realistically, I would keep the app.config connection string in the ef project. Then I coud use a static kept string to use when the projects access the db and create the dbcontext?
No its not, I just wanted to try and alleviate as many issues as possible and keep it simple.
Realistically they will not change either. The idea is mainly to try and keep the db access seperate from the other projects. Also is the connection string is stored in DLL rather than a config file the user password details are kept away from the main project (or am I wrong does this get pulled away at compile time?).
Whilst this isnt an issue currently we are just trying to plan for the future.
So realistically, I would keep the app.config connection string in the ef project. Then I coud use a static kept string to use when the projects access the db and create the dbcontext?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks for your help Eric. Its great to get well explained and reasoned answers.