I have next scenario:
One Class Library (For example called Utilities) using one app.config
One General Site Web application using web.config and applications with web.config each one.
I need to insert an appsettings called "XXX". obviouslly should set in the Site web.config.
The Utilities library is called in all application that I have inside the Site, then I should set the appsettings key in each web.config (something confusing).
How can I set the key inside app.config and read it? ConfigurationManager only read from Web.Config and I would like to read app.config keys inside Utilites.
Is it possible?
Hi I found the solution:
if yu want to get the properties of app.config you can use:
var value = Properties.Settings.Default.keyName
Related
I want to read and write the users settings in the app.config file of my project.
I want to add the user name as a section and adding its setting, for each user if he is not exist in the app.config.
And I want to read it at the beginning of the application.
Can you help me please?
.Net already has this class ConfigurationManager you can use to read app.config and web.config for web scenarios. You could use something like this
var temp = ConfigurationManager.AppSettings["data"];
for more info please check the MSDN ConfigurationManager
i have a webapi project that uses cache library.I am using cache duration key that is used inside cache library.My question is what is the standard practice where should i put Cache duration key,from Where to pick the value of cache duration, inside appconfig of cache library or from web.config of webapi?
The web.config is the place to go in a web application. There's no such thing as app.config in an ASP.NET application. You could always build some mechanism to load configuration data from custom places but the first place a developer would look for such things is the web.config.
We have a static html/webform site, the site lacks search functionality, I was able to get yahoo BOSS (Build your Own Search Service) after a few hours yesterday, i got it working (still working on adding missing features like pagination) , I was wondering about the configuration options of the class, as I have a BossSearch.cs in App_Code, with some fields that are set at the top:
public class BossSearch
{
String sResultsPage = "~/searchResults.aspx";
String sSearchString="";
String sApiKey = ConfigurationSettings.AppSettings["BossApiKey"];
String sSite = "www.oursite.com"; //without http://
String sQuery = "http://boss.yahooapis.com/ysearch/web/v1/{0}%20+site:{1}?appid={2}&format=xml&start={3}&count={4}";
String sStart = "0";
Uri address;
WebProxy webproxy = new WebProxy("http://192.168.4.8:8080");
bool bUseProxy = true;
int nResultsPerPage = 10;
int nTotalResults = 0;
...
As you can see, i get the BossApiKey from the web.config file, but all others I have them in the declared in the class, should I put all of them in the web.config file? if I'm thinking of reusing the class (should i say class library?) in other websites as well? can I turn it into a dll and what would the advantages be? i read somewhere that a dll has its own config file, is this the way to store those settings?
Apologies for my ignorance, since I'm not that familiar with developing applications (still studying)
What you read about .NET assemblies having their own config files is not absolutely correct; a web site has web.config files, one in the root and zero/one in each subdirectory. If a .NET assembly that is in the application calls into the standard config API, it will get its data from that web.config.
The same goes for WinForms apps and the [appname].exe.config file; any assemblies included that use the standard config API will be getting their data from that.
All of that is not to say that any assembly could not define its own configuration mechanism which pulls its data from wherever it wants.
And yes; if you intend to reuse this code a good bit, you are thinking along the right lines; put the code in its own assembly, and have it get its data from Config files so you do not need to recompile it for each application.
If you declare all of them in a database or web.config, you don't need to recompile each time you reconfigure the search engine
I you're striving for reuse and ease of use, then I would recommend writing a custom configuration section for your control. This can be part of the dll you distribute to other application and will allow you to have the ultimate in flexibility and explicit portability to other .net apps.
Enjoy!
You should only store the value in a single place in your application. For an ASP.NET application, the web.config file is an appropriate place for these kind of things. You won't need to recompile your application if this value changes.
If you decide to put your code into a separate class library and still want to use a config file to store your api key, you should note that your appSetting key needs to be entered in the application or web site's config file - you can't define a config file for a class library.
One other approach that you might find useful would be to make a wrapper class to store your settings. You could have class with static methods to look up your appSettings key so that you get a nice, compile time, way to get the api key, rather than typing out the name of your appSettings key everywhere.
What is the best practice to store application settings (such as user name and password, database location ...) in C# ?
Hint: I am new to .net and C#
Application Configuration Settings that are application wide (non-user specific) belong in either app.config (for Desktop apps) or web.config (for Web apps).
Encrypting sections of a web.config file is quite simple as outlined in this Super Simple Example.
If you need to store User specific settings (like application settings, etc.) or Application wide settings not related to application configuration you can use a Settings file as described here:
User Settings in C#
I'm not sure what version of .net/Visual Studio it was introduced in, but you can right click on your project, choose 'Add New Item' and select 'Settings File' from the "Add New Item" window. This provides your project with a (named by default) Settings.settings file that you can configure all the settings you want to expose in.
You can define settings that you create to be either Application or User which means you can use this single interface to control global and user settings. Once you've created a setting in the Settings.settings file using the editor that Visual Studio provides, you can access it in code like this:
// Get a Setting value
var valueOfSetting1 = Settings1.Default.Setting1;
// Modify and save a Setting value
Settings1.Default.Setting1 = "New Value";
Settings1.Default.Save();
First option is the registry. It is easy, but it is not too safe for passwords. Another option is using a file that you create. This too isn't safe, unless you want to implement cryption.
Next option is using the Application Settings. This is also quite simple, but there are a few catches. First, right click on your project and go to Properties. There, under the Settings tab, you can store variables to which you can access from your program by
string password = Properties.Settings.Default.Password
You can also change them the same way, but ONLY IF the scope is set the User. WHen the scope is application-wide, VS does not allow you to change these variables for some odd reason. To save changes, you must call Save() as follows:
Properties.Settings.Default.Save();
These are saved in the User Data folder under C:\Documents and Settings\'Current User'\Local Settings\Application Data\
Another option would be to include them in your database, but since you are also storing your database location, this might not work for you.
I think app.config (non web app) or web.config (web app).
These sorts of settings usually land in Application Configuration Files (web.config, app.config).
http://www.devasp.net/net/articles/display/679.html
If you are storing passwords, you might also need to encrypt the configuration section in question.
http://msdn.microsoft.com/en-us/library/53tyfkaw.aspx
http://msdn.microsoft.com/en-us/library/ff650304.aspx
Note if you use app.config, you will see it get renamed to ..config, depending on if your output produces a DLL or an EXE.
As with the above replies suggest, app.config or the web.config is the best place for app settings.
If you need a more robust way of xml style tags for database, server settings and the like, you can use the configurationSection and create custom sections.
http://www.codeproject.com/KB/cs/CustomConfigurationSectio.aspx
For database passwords, the way i do it is have an encrypted string in the xml tag value and decrypt then when reading them, that way you dont expose the passwords.
appsettings config file, ini file(nini), embeddable database(sqlite,berkelydb/etc..),whatever method you like, it depends on your application size/performance consideration and design.
I have WCF Client initialized like this
MyServiceClient client = new MyServiceClient();
so it uses the app.config to read the endPoints.
I would like to dynamically change the default config file to a file I define.
I know I can open a configuration file like this:
Configuration myConfig = ConfigurationManager.OpenExeConfiguration
but how can I set myConfig to replace the default configuration?
Check out this article here: Read WCF Configuration from a Custom Location.
It basically involves creating a custom ServiceHost that will read the configuration from a different file which you can specify, rather than from web.config or app.config.
Here's another excellent article on using custom config files for WCF services hosted in IIS:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/22/custom-service-config-file-for-a-wcf-service-hosted-in-iis.aspx
Marc
I've seen something similar done by just reading values out of a custom config file (that was just opened and read with a standard XML parser). Then the values were plugged into the WCF configuration entries programmatically.
This was done because multiple projects in the same solution all read their WCF configuration entries out of the same file. I'm not sure why they went with that architecture, but in the end it worked just fine.