Hai ,
I am doing a web project in asp.net. Now I am trying to keep each connection string for each user . And the user can decide which server he prefer. How to change this dynamically and where can I store this?. I happen heard about machine.config .Unfortunately i am not familiar with this. Can you just tell what it is and it's use. If any disadvantages please tell.
And How it use?
Machine.config is a "global" set of configuration settings. All websites on your server use the settings set in Machine.config, and they can be overridden with settings in Web.config. See Machine Configuration Files on MSDN.
If the connectionstring is unique to each user, web.config (or machine.config) is probably not the location where you'd want to store it.
But if I assume you're only going to deal with a handful of connections (i.e. NOT a unique connection per user), you could create the connections in web.config and then just store a reference for each user.
<connectionStrings>
<add name="cnn1" connectionString="[your connectionstring]" />
<add name="cnn2" connectionString="[your connectionstring]" />
</connectionStrings>
Where do you store user specific data? ASP.NET Membership? Something handrolled?
Its usage (I am talking for web.config):
Writing connection strings manually is difficult especially when you don't know its syntax. So,
1.Add a SqlDataSource (if your db is mssql)
2.Point it to your .mdf file
3.It will ask whether it should save it to web.config
4.say "yes" and give a name to that string
5.Now you have a connectionstring with a name
6.Then you can manipulate it
I don't advice you to use that file, it is server wide configuration file, use web.config that is application wide.
Meantime, why do you want to store connection string for each user?
Related
I have a WebForms project that has a connection string hard coded into the web.config (for Debug - web.Debug.config). This connection string points to a DB server for development.
I'd like to run a local copy of that database so that my changes don't immediately affect others.
What I've been doing is going into the web.config and updating the connection string to point to my local DB. This works, but is somewhat tedious as I have to remember to exclude the web.config and have to re-update it if I undo all changes.
Since, like I said, others are using this solution, I'd like to avoid checking anything in or modifying the web config.
Is there any way to override the web.config connection string to force the site to point to my local DB without checking anything in to source control?
One solution would be to use config transformation feature.
VS 2012:
Go to Build->Configuration Manager
Click on the Active solutions configuration List box and select "New".
Enter local as name of your new configuration and click Save.
Make sure you change the values under Configuration column back to Debug or which
ever was default previously
Right click on your Web.config file and select Add Config Transform, which will add the newly created web.local.config
Inside web.local.config add the local connection string transform, something like
<connectionStrings>
<add name="DbConnection"
connectionString="...Add Local Connection String..."
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
When you run or debug the project, make sure you select local configuration from the list box next to green run arrow. You just don't check in the web.local.config
One thing you might be able to do is have a separate file for your connection strings - you wouldn't check this into source control at all.
Depending on how your stuff is organized, you might need everyone who's doing development to do the same thing, and depending on how you do your publish/deploy, this may not work for you.
For example:
Web.config
<configuration>
<connectionStrings configSource="connectionstrings.config">
</connectionStrings>
</configuration>
connectionstrings.config (not in source control)
<connectionStrings>
<add name="cs" connectionString="server=.;database=whatever;"/>
</connectionStrings>
Each developer can choose which database their local machine points to, and as long as the connectionstrings.config file is not in source control (add it to the ignore list), nobody will step on each other's feet.
Create a SQL ALIAS on your local machine.
Click start run and type "cliconfg.exe" on local machine. This will help you to create a SQL Alias on your local machine. On the web.config connect to the live database but on your machine create a SQL Alias that will redirect to your local database. When this is done, when you publish the program it will automactically connect to the live database but when running from your local machine it will connect to local database without any code change.
This is about ConnectionStrings / ASP.NET MVC with Visual Studio 2012 ultimate & SQL Server Express 2012.
Following up with this tutorial here: http://www.asp.net/mvc/tutorials/mvc-4/getting-started-with-aspnet-mvc4/intro-to-aspnet-mvc-4 I came across an issue with these two connection strings at my web.config:
<connectionStrings>
<add name="DefaultConnection"
connectionString="Data Source=(LocalDb)\v11.0;
Initial Catalog=aspnet-MvcMovie-users;
Integrated Security=SSPI;
AttachDBFilename=|DataDirectory|\aspnet-MvcMovie-users.mdf"
providerName="System.Data.SqlClient" />
<add name="MovieDBContext"
connectionString="Data Source=(LocalDB)\v11.0;
AttachDbFilename=|DataDirectory|\Movies.mdf;
Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
the website works fine but I couldn't fingure out why the first db is created in the App_Data folder while the second one is created in "C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA"?! I supposed that both will be created in App_data because both utilize this attribute: AttachDBFilename=|DataDirectory|!
note: the tutorial mentions that it should be in the App_Data & they added a screenshot that shows it there indeed!
I have been looking for an answer and got into the complicity of SQL (I thought User Instances might be the solution) but couldn't reach an answer for this : |
(this might be useful to read about User Instances http://msdn.microsoft.com/en-us/library/bb264564(v=sql.90).aspx)
Any ideas are greatly appreciated. Thanks in advance.
Regards
after research/tests it turned out to be as follows:
VS will look at the class name of the DataContext and will look to see if you have provided a connection string with the same name as the class name; for example:
public class MovieDataContext : DbContext
and
<connectionStrings><add name="MovieDataContext" ...
if it manages to find a matching connection string it will create the DB based on the criteria you specified in the respective data string (to add the DB to the App_Data set the path of the DB to |DataDirectory| as shown in both connection strings mentioned in the question); if the name doesn't match or you didn't provide any connection string, VS will fall back to the default settings and will create the DB in the default location/settings (usually C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA).
note neither the "Integrated Security" settings nor the "Initial Catalog" play any role with this (I was able to create the DB in the App_Data with both Integrated Security = True & Integrated Security = SSPI and with/without Initial Catalog).
Hope this helps. Thanks for everyone that participated.
I had the same issue. I believe the difference is in the Integrated Security setting. I have SQLExpress installed and found my Movies database in there using MS SQL Server Management Studio.
Check out this response for a better explanation. Difference between Integrated Security = True and Integrated Security = SSPI
What AMT has given is exactly right. It was confusing as it is to use connection strings with .mdf and .sdf files.
I have another pointer for you though, you can change the default setting where the application looks for a connection string with the name matching the class name of the context class by overriding the constructor of DBContext and providing the paramter nameOrConnectionString as follows
public BlogsContext()
: base("name=EFBlogs")
{
}
Application then searches for a connection string named EFBlogs, if it cannot find connection string then it creates the database with name EFBlogs, instead of BlogsContext
Hi I notice a difference when you add a database and it asks do you want it to be placed in the app_data folder if you click yes then it goes to the app_data folder and the full path name of the mdf is also in the app_data folder whne you use file explorer.
In one of the applications I have been referring to, the Connection String is stored in AppSettings! Till now I have been storing the connection in the <connectionstring/> element. But what is the correct way?
So my question is, what are the differences between <connectionstrings> and <appsettings> in the web.config and are there any specific reasons why I should or should not be storing connection strings in appsettings? Are there any rules / guidelines provided to follow? Or is this completely the choice of the developer?
There is a fundamental difference between connectionString and appSettings:
They look for different things. In .NET 2.0 and above:
A connectionString object is an XML node that has specific attributes to set; and semantically it refers to a database connection string.
For instance, a connectionString looks like the following:
<connectionStrings>
<clear/>
<add name="LocalSqlServer"
connectionString="Data Source=(local);Initial Catalog=aspnetdb;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
You'll notice it has a few different attributes:
name
connectionString : This has a specific string inside of it, it needs an Initial Catalog, a security mechanism (in this case Integrated Security
providerName
Whereas appSettings is just a user-defined Key-value pair that allows you to... well... set application settings. It can be anything:
<appSettings>
<add key="Mom" value="Your"/>
<add key="UseCache" value="True"/>
<add key="MapsKey" value="1234567890-AA"/>
<add key="SMTPServer" value="smtp.peterkellner.net"/>
</appSettings>
In many cases, it would just be odd to put the connectionString in a key-value pair like appSettings (semantically and programmatically). As well as it would make it more difficult to encrypt the connectionString when you need to.
There is more information about this from this blog post.
As far as I know it doesn't make a huge amount of difference, other than it being in the "correct" place - the main advantage of putting connection strings in their own section (you do encrypt your connection strings.. right?) is so you can encrypt that section without encrypting all of the settings you might want to change.
Connection strings are generally kept in the <connectionstring/> element...and is a good guideline since it's named properly.
Sometimes you might use a third party control or usercontrol that looks for the connection string in a key in the <appsettings> element. That should be the only exception to the guideline.
Additionally, in IIS7, connect strings can be maintained through the respective IIS7 Administration.
You can use appSettings section to share custom application configuration settings across projects in .NET.
How to share custom application configuration settings across projects in .NET
Regarding deployment, there's one significant difference between them. When you import web packages to IIS:
Connection strings will automatically be included in the wizard dialog for further parameterization.
App settings will not be there by default. If you really want to do that, please follow the steps in "Custom Parameterization - Application settings in the web.config file" section of Configuring Parameters for Web Package Deployment
That means, when it comes to deployment, you'd better put environment parameters(database, cache, AWS key/secret, etc.) in connection strings. It will provide differentiation between dev/staging/prod environment explicitly.
after digging for a while i have decided to go with WCF service and i really love the idea of multiple end points, this will let me serve different type of service protocols with one service.
now my question is how i can make for example a service address like this
http://www.mysite/services/blog/RSS/gettopposts
http://www.mysite/services/blog/JSON/gettopposts
to be more specific i want to be able to test this address both on Dev and production server without changing configuration
one more question will this help me in security as i would want my real WCF file location to be under ~/Internal/Services/blog.svc
thanks alot in advanced.
Are you asking how to configure WCF for multiple environments?
If you are my posting on msbuild and multiple environments may help.
What we do is store the url's in an SQL Compact database (could also simply be in the config file), we store the environment specific url's in a separate xml file then as part of the build process the urls are updated in the SQL db.
Then to point to any given 'environment' we just have to change the 'BuildEnvironment' setting and all urls for the WCF services (and other environment specific info) are automatically set to their correct values.
Are you using VS2010? You don't specify If you are please investigate web.config transformation at http://go.microsoft.com/fwlink/?LinkId=125889
In the example below (directly from the help), the "SetAttributes" transform will change the value of "connectionString" to use "ReleaseSQLServer" only when the "Match" locator finds an atrribute "name" that has a value of "MyDB".
<connectionStrings>
<add name="MyDB" connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
I'm entering a parallel test and dev stage where I need to use one db for test and a different one for dev. How can I have the app choose which connection string to implement based on which physical folder it (the app) sits in?
I know there are SVN strategies to consider but this is small-scale enough to avoid 2 sperate code-bases. Would like to be able to publish the same VS project to either of my 2 directories without having to remind myself to change the connection string.
I'm running under IIS7 so perhaps it offers better control than conditionals in (and overrides) web.config. (or not)
thankx!
A word of advice:
I wouldn't base your connection string on your published folder. Down the road, the folder might change, and folks may not be aware that that determines which connection string you're using.
Instead, control it with a setting in your web.config file. Just add a setting that allows you to switch between production and dev databases. In fact, you could simply test for the presence of a debug mode setting. If that setting is there, you're targeting the development database; otherwise, you're targeting production.
The nice thing about that solution is that it doesn't depend on where you deploy the site, and you can document the setting in the Web.config file.
Hope this helps.
Edit for Clarity: By "a debug mode setting" I mean a setting that determines which database you're targeting, dev/production. Not whether your application is running in Debug mode, since the Framework already provides a function that does that. Also, you wouldn't necessarily remove the setting, since you'd want to keep it for documentation purposes. Rather, you'd comment it out.
You could e.g. create a <connectionStrings> container that contains a connection string for each folder your app could be in:
<connectionStrings>
<add name="Folder1" connectionString=".....(conn str. #1)...:" />
<add name="Folder2" connectionString=".....(conn str. #2)...:" />
....
<add name="Folder-n" connectionString=".....(conn str. #n)...:" />
</connectionStrings>
and then just pick the right one, depending on where your app starts up from.
Marc
Get a unique string for the application, perhaps something like:
string folder = Regex.Match(Server.MapPath("~"), #"\(.+?)\$").Groups[0].Value;
Then use the string to get a value from the web.config:
ConnectionStringSetting connectionString = ConfigurationManager.ConnectionStrings["ConnectionString." + folder] ?? ConfigurationManager.ConnectionStrings["ConnectionString"];
In the web.config you can add several connection strings with the folder names appended for each dev site, and a default connection string with just the name and no folder.
I usually put the connection strings into a separate config file and reference them from the main web.config using configSource:
In web.config:
<?xml version="1.0"?>
<configuration>
<!-- connection strings are located in an external config
file to facilitate deployment in various environments -->
<connectionStrings configSource="connections.config"></connectionStrings>
</configuration>
In connections.config:
<?xml version="1.0"?>
<connectionStrings>
<add name="ConnectionName" connectionString="[your connection string]"/>
</connectionStrings>
Once deployed, I usually exclude connections.config from future deployments (unless it should be changed, that is).