I want to keep the settings for two different projects for c# commonly.Is there any way to achieve this?.
Regards,
Harsh Suman
I guess there are many options to choose, from, depending on your exact scenario and preference.
Here are some -
You could use a database, if you can safetly assume there is one.
you could use entries in the machine config, which would be accessible to both applications; you could do so using AppSettings or, better yet, custom configuration section.
You can declare your configuration in the machine config, but specify it in a separate file to make it easier (and safer) to maintain -
<configuration> .. <appSettings file="MyConfig.config" />...</configuration>
Where MyConfig.config is the name (can be a path to any subfolders as well) of a file containign an appSettings section.
If you're using custom configuration (or any build in configuration section, other than appSettings) you can use the ConfigSource attribute to specify the location of your configuration as described here
You can look at using some shared location for the configuration, for example - in Windows Vista you can make use of the %APPDATA% location to store the configuration (create your own folder under that), looking at this folder you will notice this is what many other programs do.
If by project settings you mean configuration information then the solution already posted about setting a common file for appSettings is fine (assuming that you are using the appSettings section for your configuration). You can also make a custom configuration section handler that loads from a common place or even a database.
If you are talking about project information, like Assembly type of information, then you can edit the project file and include a link to a common file that will be compiled into both of the projects. You can add the link by including something like this...
<Compile Include="..\..\SolutionInfo.cs">
<Link>Properties\SolutionInfo.cs</Link>
</Compile>
We use this for common attributes across projects that are either in the same solution (like to align version numbers, etc) or across various projects to have one place to manage common information like company information.
Related
In several C# projects I have been using an app.config file to pass various settings to my program, settings like connectionstrings, power levels etc.
However sometimes I have come in situations where the settings aren't updated as expected and I have concluded that I am not that well informed with the proper use of app.config file.
Example:
Replacing the .exe file with a new version (where settings are different) to the output directory without changing the exe.config, results in the program seeing the hard-coded settings and not the settings of the existing .exe.config
So my Questions are:
What is the exact role of exe.manifest file
Every time I create a new .exe do I have to paste in the output folder anything else except the .exe file?
Whats the difference in obtaining the setting value by: ConfigurationManager.'settingName'... rather than:
Properties.Settings.Default.'settingName'?
What is the role of app.config build action?
Sorry If I am asking too much in a single Question.
The app.config file is a file that gets a special treatment when running the associated application. If you executable is named MyApp.exe the app.config file should be named MyApp.exe.config. The role of the app.config build task is to copy the file named app.config in your project to MyApp.exe.config in the output directory.
.NET provides ways to read the contents of the file (it is in XML format) and various parts of .NET will look for different sections in this XML to provide configuration.
A widely used section is the settings section you refer to as Properties.Settings.Default. This section plays together with Visual Studio that provides an editor for application settings. The settings are accessed in the code by using a generated class. Adding a setting will add a property to this class and this property is initialized from a value in the app.config file.
In the Visual Studio editor you can set a value for the setting and you can think of this as a default value for the setting. However, if you overwrite the value in the app.config file the later will take precedence. This allows you to modify the app.config file after installation and rerun the application with a modified setting.
You can also access application settings the app.config file using other methods, but in my oppinion using the Visual Studio editor and the code generated class is the best way to do that.
I am not sure I fully understand the problem that you experience. If you update MyApp.exe and leave MyApp.exe.config intact you should not see a change in the settings used by the application (unless of course you have renamed or changed some settings).
The manifest file provides information about side-by-side assemblies and can be used to request elevated privileges among other things. This is not related to the app.config file.
There quite a few resources about that.
See http://msdn.microsoft.com/en-us/library/ms229689%28v=vs.90%29.aspx
and the (better) overview: http://msdn.microsoft.com/en-us/library/k4s6c3a0%28v=vs.110%29.aspx
app.config is a very powerful tool. It addresses many issue like versioning, migration, upgrading etc. but this requires some in-depth reading from the links above.
Maybe one thing you could do, if you want to copy only .exe file every time you build your app, is make a settings.ini or settings.txt file, put your parameters in this file (that are not secret of course) and read all your settings from there when you start your app.
You can put all your connection string logic in your login form if you have one...
I am having two different application configuration files in my project.
I need to read values from these two config files in my code. Searched a lot and found most of the answers are: use ConfigurationManager. But I can't read the second config file in my code. Please help on this.
Example:
1. app1.config
2. app2.config
how to read the value of the app2.config?
Never used the app.config in .NET but another solution would be using Xml(XmlReader, XmlWriter) from the System.Xml namespace and you can create a tag for Configuration and use as many configurations as you like, all this in one file. e.g.
<Configuration name="app1">
//here you would have your 1 configuration
</Configuration>
<Configuration name="app2">
//here you would have your 2 configuration
</Configuration>
The app will use the config file named YourExcecutable.exe.config which is by default the file App.config included in your (executable) project. Note, that .NET only loads one config file for the whole application. You cannot use multiple configuration files (i.e. one per library project) without coding.
You can use postbuild events and different solution configurations to copy one or another App.Config file to the output folder
You can use the ConfigurationManager Class to load an alternate config file by code.
Reference:
Handle multiple configuration files
Managing Multiple Configuration File Environments with Pre-Build Events
Atlast I found the way to handling multiple configuration files, the only way is use the SECTION handling within the main app.config file.
The best way is first understand .NET configuration. The best source is http://www.codeproject.com/Articles/16466/Unraveling-the-Mysteries-of-NET-2-0-Configuration
Really hard for the first time to understand, once you are clear with this idea you can do wonders using configuration files in .NET. This is the only solution I found throughout the internet.
Thank you,
Happy coding.
We have many C# console apps that run on scheduled tasks. All of these apps have their own config file, which contain settings like our smtp server. If our smtp server ever changed, we would have to manually go into each config file and change it. Can multiple apps look at 1 config file on the C: drive, or is that considered bad practice? Using the database to store values is a no no.
You can point to external config files inside your application's configuration file like the following, and have all your applications use the same set of settings from a single file:
<appSettings file="c:\CommonSettings.config">
<add key="MyKey" value="12"/>
</appSettings>
For more information, you can read following articles:
AppSettings can Reference an External Config File
How to share custom application configuration settings across projects in .NET
It is not directly possible to share one application configuration file because the .config filename needs to match the executable name (so for example.exe it would be example.exe.config).
It makes sense to have separate values for the different applications, as they are separate applications.
If there are configuration sections that you do want to share, you can use the configSource attribute to point to a file. The appSettings section also has a specific file attribute that you can use in the same manner.
If there are certain configuration values that are shared across all applications, you can consider placing them in the machine.config file for the version of the framework you are using.
Can you use custom xml files to store configuration data ?
There's no necessity to use app.config.
Using Cinchoo framework you can achieve this, by simply creating custom configuration object and use it all the console applications. All of them will read from same configuration file. For more information, please visit http://www.cinchoo.com
I have the following projects:
MVC
Console application
Class library
Windows forms application
COM Library
All these applications need to use a single configuration file. As far as I understand, app.config files are for windows, console applications and class libraries when web.config are for the web projects.
The same configuration need to be accessible in all of these projects. I have read that it's suggested to use machine configuration file, but we won't always have access to that, therefore configuration files must reside within our solution.
I don't fully understand how the configuration files get build. Currently I wrote a simple project where I have the following:
Class library to store for serving configuration files. A have attempted to do this through reflection.
Windows application that should read the app.config from a class library.
When I execute the following code I expect to get a configuration file with test values:
_applicationSettings = ConfigurationManager.OpenExeConfiguration(
System.Reflection.Assembly.GetAssembly(typeof(WCSConfiguration)).Location
).AppSettings;
What I get instead is an empty application settings file.
Class library has the following App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="TestTextKey" value="TestTextValue"/>
</appSettings>
</configuration>
I have tried using .GetExecutingAssembly() method which I expect to return an assembly of a code that's currently being executed. This didn't work, instead it has returned the assembly of a Windows application.
GetAssembly(type(WCSConfiguration)) has returned a right assembly, however, the configuration file was missing in the bin/debug directory.
I have a feeling that either I'm doing something fundamentally wrong or Microsoft hasn't made this flexible enough. I have also tried to search MSDN for explanation, but this hasn't been documented well IMO.
I have also left COM in bold because I'm not sure whether any config files would be available to COM library at all. Firstly I would like to get other projects to work.
I understand that this is a lot of information. Any help would be greately appreciated. Previously we have chosen to use registry, but this has turned out to be nasty, mainly because access to registry is not available in some scenarios. Additionally we now have multiple versions of the applications and switching between branches is a half an hour job :(
Thank you
Edit:
If I add the dll's config sections to app.config that means that these settings will be available only from that application. Please correct me if I'm wrong. Example that I have provided is a scaled down version. In total there are about ten windows applications, a single MVC project and range of class libraries all of which need to make a use of that configuration.
Configuration settings are mostly connection strings, lookup values that do not belong in the database and few other minor settings. Main concern at this point are the connection strings. There are few minor releases of the application where each release points to a different database.
What I'd like to get out of this is a good workable solution so that it can be posted online and other people who come across the same problem won't spend days of their time.
Morale of the story IMO:
Use both App.config and Web.config to store location of your own configuration file.
Write simple XML serializer to read/write config and DLL for serving the configuration.
COM objects are a long story and were implemented with a "hack", since neither App.config or Web.config are available in COM DLLs.
Note ConfigurationManager.OpenExeConfiguration needs to be passed the filename of the config file, not the executable.
You'll need to append .config to the path of the executable. To get the exe assembly use Assembly.GetEntryAssembly.
If you have configuration settings you want to share across multiple pieces of code that are not all in the same .NET Process, I would suggest:
Put them in their own myStuff.config.
In .NET code use ConfigurationManager.OpenExeConfiguration to open and access myStuff.config.
Non-.NET code will need to use an XML parser to load and read the settings. Unless you configuration structures are very complex this shouldn't be too hard to encapsulate.
Put the path to myStuff.config in the app.config of each application sharing this configuration for .NET applications. (Not non-.NET applications: depends on what works for that application.)
Another approach, where the configuration structure is the same but the settings are per-application would be a custom configuration section.
A couple of general points -- add the dll's config sections to the app.config file rather than relying on the dll's config file to get picked up; and app.config actually gets renamed to .exe.config on build, so you need to make sure a file of that name's available.
Also -- you're not constrained to using the default config loading mechanism to configure your application. You could create your own configuration classes and just use XML serialization to deserialize and configure at will.
I'm writing a class library as an abstraction to use for logging in any application, service, etc. that I write. I'm making it decently robust by making it very configurable to suit my needs for most application/service logging scenarios that I come across.
The config is designed to specify things such as:
What logging level to write
Write to one log file for all levels
Write to separate files per level
Logging cutoff (periodic, app event, byte size restricted)
Log file expiration (delete log files after file age)
Write as flat text or XML
Log file name format specification
Whether to prefix filename with date
Parent app's name
etc, etc, etc...
I've read some other stackoverflow questions regarding configs for DLL assemblies and it causing conflict between the app.config for the hosting assembly/app. I believe that my assembly has just cause to provide a config file.
Is this a good scenario for that occasion? Is it perhaps a better idea to bake my own config into my project so that my logger reads from XML files to retrieve config values?
What you could do is
create a custom configuration section (using e.g. the COnfiguration Section Designer tool)
put your assembly's configuration into a separate MyAssembly.config file
reference that assembly config file from your host app's config:
<configuration>
<configSections>
<section name="YourAssembly"
type="YourAssembly.ConfigSection, YourAssembly" />
</configSections>
<YourAssembly configSource="MyAssembly.config" />
</configuration>
That way, you can "externalize" your configuration into a separate config file which you have only once (in your assembly's project), and any project needing it just needs those settings in its own config file.
Sounds like a custom config section would work well in your case. Many libraries, such as the Enterprise Library do exactly this. Check out the MSDN article about creating one.
The .NET config mechanism is not meant to handle configuration files for DLLs. You should configure your application with appropriate settings and pass them on to the class you are instantiating from the DLL.
It is possible to add settings to a DLL project as you'd usually do for applications. All you then need to do is copy the relevant sections and entries into the application's app.config manually and it will work.
It is, however, still true that there's no point copying the DLL's config file. It will not be read.
Another mechanism is to have a seperate configuration file (*.dll.config) for your assembly. The technique is shown here: http://blog.rodhowarth.com/2009/07/how-to-use-appconfig-file-in-dll-plugin.html
The above, imitate the standard app.config technique for assemblies.
In my opinion the dll configuration reading code should only exist in the corresponding dll and in a seperate class - with single responsibility of reading configuration entries from the *.dll.config. This is a nice way of having configuration file for an assembly in a way similar to the configuration file (app.config) an executable can have.