We have a large VS solution, consisting of many projects representing the various model, service and presentation layers.
Currently the connection string to the main database is spread throughout the solution. On the web front end, its contained in the web.config file. The data initialization and web forms app have it contained in separate nhibernate.config files.
Is there a better way to manage the connection string?
I was thinking if somehow it was centralized in one point, it would then be easier to manage and update, rather than having it spread all over the place.
If the intention is to have only one place in the solution where the connection string need be specified, then the following should work.
Split out the connection strings section into a separate file and reference it in the configuration files that you need to using
<connectionStrings configSource="connectionStrings.config"/>
Now put connectionStrings.config file in a common location (perhaps Solution Items). Add it as a link to each project that requires it using Add Existing Item -> Add as Link.
Because all of the projects now have a link to the one connectionStrings.config file, any changes to that file should propagate to the linked items in each project in the solution.
Related
I have 2 projects currently. A dashboard(MVC) and a API. both of them look at the same database but have their own models generated in their respective projects so if you make a change to one it doesn't reflect in the other one.
I want to add a third project for the data and have both my other projects look at that project for any data queries.
What would be the simplest way of doing this and how would the context of EF be affected with the queries sitting in a separate project from where the data is used.
Create a separate project for your Data Access Layer (EF en entities). Then create a reference to this separate project to use it.
Do not forget to add the connection string and entity framework setting to your .config file.
When do not work with code first and in your project you work with multiple Data layers, it may be required you add some metadata to the connection string.
I hope this helps u.
Normally, in a .NET application, you store your database connection strings in the app.config.
For a single .exe, there's a single .exe.config. And we're using Entity Framework, which defaults to using a .config setting that matches the DbContext name. Which all works fine, so long as you follow the common pattern of having a single instance of an application talking to a single database.
But our problem requires we have multiple instances of our application, each with its own distinct database connection.
Possible solutions:
Create multiple copies of the .exe, each with its own copy of the .config, and put a different connection string in each. Advantage? No coding changes. Disadvantage? Maintaining all the different copies, making sure they all get updated, etc.
Keep one copy of the .exe, with one copy of the .config, and put multiple connection strings in the .config. Then pass a command-line argument to the program that selects which connection string to use. Advantage? Only one .exe to manage. Disadvantage? Coding change, likelihood that someone's going to mess up the command-line arguments.
Some other brilliant idea, that someone here on Stack Overflow is going to point out to me.
Any ideas?
I'm sure people have dealt with this issue, before. Is there a common way of handling the issue?
You can also think of creating copies of config file and load the appropriate one based on command line parameter using following code:
AppDomain.CurrentDomain.SetData ("APP_CONFIG_FILE", "path to config file")
See this for detail: Relocating app.config file to a custom path
You could try something like this within some C# applications to change the connection string per application.
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
var connectionStringSection = (ConnectionStringsSection)config.GetSection("connectionStrings");
connectionStringSection.ConnectionStrings["database"].ConnectionString = string.Format("Data Source={0}", userCon);
config.Save();
ConfigurationManager.RefreshSection("connectionStrings");
We are moving database from one server to another. There are many connection strings of applications that needs to changed due to this. Is there any generic way where we can keep the connection string so that if we move the database again then this issue doesn't arise??
There are so many ways to resolve this problem.
Ultimately what it sounds like you want to do is centralize your database connection strings in such a way that a database migration is (mostly) transparent to your application. I can think of a few options here:
Use a "control database" that houses your connection strings and configurations. If you migrate to a new database server, you only have to update a single connection string in your application, and perform data updates for everything else. This is what I personally use.
Use a central XML configuration file that is parsed on application startup.
Use SQL Server Aliases and/or add additional IPs to the machine that you can migrate between servers. This way when you move to a new database server you can still bring along the existing aliases/IPs to that server (unless they need to run in parallel of course) and theoretically not need to update anything in your code, provided that you've referenced the appropriate aliases. See here for more info: https://dba.stackexchange.com/questions/56642/how-to-create-a-server-alias-in-sql-server-2012
Over here we ultimately went with option 1 because that gave us more flexibility and reliability than an XML configuration file (#2) and required less configuration and special cases to be documented with our DBAs, since we have no ownership of any database servers outside of our DEV environment.
Have the connection string in an xml file and read the xml file and get the connection string from it. You only need to change the connection string in the xml file and not in the published code. By the way you can have multiple connection strings for Debug and Release modes and make your application choose it.
You could store them in a database. ^_^
Jokes aside, I do not have experience with this myself, but using an Alias sound like it might suit you best:
http://blog.idera.com/sharepoint/performance-webcasts/plan-your-sharepoint-farm-right-with-a-sql-server-alias/
First, you can store your connection strings in external file (custom storage or .config file) - so you will be able to change them without recompiling the code.
Second, you can use domain name instead of IP address
And third, you can store your connection strings in parts and build them in runtime by ConnectionStringBuilder - so you can change only server part.
I am using Entity Framework and recently came to realize the benefits of having your EF model in another project within the same solution so that I can build multiple UIs from it.
I moved it over to a new class library project and updated all the references to the entities in the web project to use the new dll generated by the project. Everything has gone smoothly, except for one small snag. When I moved EF over to the new project, somehow it was still reading its connection string from the web.config in the web project (don't ask me how because I have no clue).
I used "Update Model from Database" in the EF designer and it did not find a connection string (as I expected after moving it over to the new project) so I used the wizard to generate a new connection string, which it did just fine. The new connection string now resides in App.config within the class library project. The connection string in the properties window is correct now, and the designer is reading it from the App.Config. I went ahead and deleted the connection string from Web.Config in the web project.
Now when running the application I get the following error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
If I paste the connection string back into the Web.Config it all works just fine. I do not want to create a new EF model from scratch because it is a fairly complicated model and I did a lot of restructuring after pulling in from the DB. I have poured over the generated CS file as well as the XML in the edmx file and cannot find anything useful. Any help is much appreciated. Obviously for now, until I figure this out, I'm just leaving the connection string in web.config since, for whatever reason, that seems to work.
This is by design; while the config file in the class library is what the designer will use, the configuration file of the actual application is what will get used at runtime. Whether that's Web.config for an ASP.NET project or App.config for a Winforms or WPF project, it's the application configuration file (or something higher up, like Machine.config) that will be used; the file in the class library is not part of the application.
If you're trying to provide an EF model that will work without having to specify the connection string in the application or web configuration file, then you'll have to store the connection string some other way (you could always hard-code it) and pass it into the appropriate overload of your context's constructor.
My solution is generally to provide a static parameterless function on the context itself that calls this overload with the appropriate connection string.
I have used Ruby on Rails with ActiveRecord, so I am quite used to switching to Production/Development database.
I am wondering, how do people implement Development and Production Database difference in ASP.NET MVC (preferably with ado.net entity).
I tried to have it by creating 2 entity datasets with the same name in a different namespace, so I would only need to switch the used namespace in my database code. Unfortunately, this didn't work because the entity datasets do not allow equal names...
The way I do it (with a web app) is to have separate versions of the Web.config file for each of Development (web.config), QA (web-qa.config), and Production (web-prod.config) installs. The config files have different connection strings pointing to the corresponding instances of the database. The default connection string points to the SQL server instance on my local machine which isn't available to the network.
As part of the publishing step, I manually delete the web.config file and rename the appropriate QA/Prod configuration to web.config. This hooks up that instance of the app to the correct instance of the database.
The easiest way (though it's still not as easy as in Rails) will be to include connection strings into App.config.
You should have one entity dataset, and instatiate the entities object using the constructor that takes a ConnectionString, which you can read in from:
WebConfigurationManager.ConnectionStrings["ConnStrName"].ConnectionString;
The ConnectionStrings element also supports the general configSource attribute.
You can therefore have something like:
<connectionStrings configSource="PathToConnectionStrings.config" />
This allows you to have all the connection strings held in a seperate file, that can then have different values on each environment.
Note that unlike the appSettings file attribute, this doesn't do a merge, it completely replaces the section.
Note that in VS2010, you will have the facility to modify the .config based on the build configuration, so could change the values just by setting your build to "Production" say.