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>
Related
We are storing session data in the database, ideally each developer wants a session database on their own pcs, or possibly 1 developer might use inproc, another a mssql connection, another Oracle (if we get it working)
Is this possible? Can you access the session key in code and change it in the application startup? Or is there a file which could be merged with the web.config file that wouldn't get checked in?
Or option C which is easier but which I haven't thought of :-)
thanks
(Edit) Just found this which goes into this in some detail
developer specific app.config/web.config files in Visual Studio
(Answer). This came from a mix of Andrew Barber in the comments and the above
(1) In the web.config have this
<sessionState configSource="SystemWeb.config" />
(2) Make a file called SystemWebDefault.config which holds something like this:
<sessionState mode="SQLServer" allowCustomSqlDatabase="true" etc
(3) Each developer has to copy the default into a file called SystemWeb.config, changing it to suit themselves. This file should be explicitly ignored in subversion or whatever source control system you use.
(4) The build box needs a copy step
Something that might do what you want is NConfig (NuGet link). I've used it on projects to let multiple developers in our team have different connection strings for their local DB copies. It lets you define a machine specific config file to replace your default config values. For example you can define a {MachineName}.Custom.config that might look like this:
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<add name="main" connectionString="data source=(local)\SQLExpress;uid=username;pwd=password;initial catalog=mydb" providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
I've never tried it with the session settings, but I can't find anything that says it won't work.
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.
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?
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).
On a project I'm working on we have a web application with three configuration files;
Web.Config
Web.Config.TestServer
Web.Config.LiveServer
When we release to the test server, Web.Config is renamed to Web.Config.Development and Web.Config.TestServer is renamed to Web.Config, making that configuration active for the application.
It is quite onerous keeping three very similar configuration files up to date, and this system is used across a number of applications which are part of this project; not just the website.
The differences in configuration are most commonly local directories or paths, URLs, IPs, port numbers, and email addresses.
I'm looking for a better way.
While your approach seems tedious, I find it to be the best approach.
I used to keep all of my configurations in a single web.config file, and simply had the "production" section commented out.
Shortly after this I had to do a "hybrid" test where my lookup data was coming from the production server, but the new data was being inserted into the test database. At that point I had to start piece-mealing what parts of the configuration block to comment/uncomment, and it became a nightmare.
Similarly, we have our server administrators do the actual migration from test to production, and most of them aren't fluent enough in .NET to know how to manage the web.config files. It is far easier for them to simply see a .test or .prod file and migrate the proper one up.
You could use something like a database to store all your configurations, but then you're running into another layer of abstraction and you have to manage that on top of things.
Once you get the knack or the template of how your two (or three) configuration files will be setup, it becomes a lot easier to manage them and you can have your test server configuration get modified for some unique testing without much hassle.
If you have a db server in the mix, you can create a table that has the config, the property name, and the property value in it, then all you have to do is change one value in the web.config, the config name (dev, test, prod).
If you have different dbs for each config, then the only thing that's different is the connection string.
Use Config Transformation and there is a blog here about it.
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Basically you create targets named web.{build configuration}.config. In each target file you write your transformation where you can add, delete and modify nodes and attributes. Example could be
web.staging.configss
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="personalDB"
connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" />
<add name="professionalDB"
connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
</configuration>
You then execute the transform by calling MSBuild {project file} /t:TransformWebConfig /p:Configuration=Staging