At the moment I have a solution with multiple projects, 2 of those are wcf services with their own web.config files. Everything worked well but stopped working at existing code after I added some new values to one of the web.config files. After some research I found out the service did not refer to his old web.config (his own) but to the other one. My solution to the problem: I add the key settings to the other webconfig aswell so they both have the same appsettings. This worked but as you might understand i am not satisfied with this problem. There is no certainty it will magically switch from file again and i need to make sure both files equals all the time.
Is it possible i use one web.config file or 1 appSettings block for 2 different projects? They both use the same values
Maybe pre-build action and copy web.config from shared folder in to all projects will be workable for you.
Something like this: https://stackoverflow.com/a/54925165/3434393
Related
I have multiple projects in a solution. Each project has its own app.config file. I want to have a single app.config or settings file which can be used across the solution. What I see is now, when i want to add some settings common to the application I will have to add an entry it in all the projects app.config file.
I want to have a single configurable file (XML) which can be used in whole application. At run time if the value of any key is changed, my application should be able to get that changed value from the XML.
It's a arquiteture problem. Why you can't have a unique webconfig file. Everytime that you need to update an application, will have to update all.
I think It's wrong.
You can to try a solution bellow:
The best and correct option. Uses one commom Redis Cache. Everybody can call it.
Save the configuration in one commom database table. So will have only one update in the solutions changes.
Use a noSql(mongodb, cosmosdb etc.) database. It's faster then sql.
Use one WebAPI. You can consult the configurations and to caching the information in each service.
obs: But if you whant a file. Can put in the solution and create a command to copy and replace the config when to build the solution. Like this:
Copying Visual Studio project file(s) to output directory during build
flw
You can use a linked file for using the same file in multiple projects in the same solution. This is good for using in multiple test projects that run either locally or from a build machine, however, for production code a centralized configuration would be a better approach.
For linking a file via the "Add Existing Item" select the arrow on the "Add" button and then choose "Add As Link".
Now I have seen this question before on SO in a variant ways, but surprisingly not in this form:
I have a solution with multiple web services (projects) that need to talk to each other. After publishing each of these web services might end up on a different machine with a different database. To tell each web service where all other web services are, I want to maintain a single config file during development.
I would like to expect that after publishing the config to be present in each published project. And I would like to expect the config file to be editable after publishing, so I can swiftly migrate a certain web service and then just edit all config files of the other web services.
I don't want to do this in the database, for the config file its self should also hold connection settings to the database(s).
I came across the following ideas/thoughts/questions:
I have a dll project called 'common' that is referenced by other projects. Let's give that one a shared.config and build a class in that project that can be used to read out the shared.config by doing System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config"). Just need to make sure the shared.config will be published along with the DLL.
I would favor this solution, as it would also let me keep a web.config inside each project having just the project specific settings. And have the shared.config having the shared settings. But I read on SO that this should not be considered lightly and could have some unwanted side-effects, like file-access-issues; though I wonder if this would apply to my case. Also I would like to ask your help here on how to actually realize this as I don't think Visual Studio supports app.config for DLL projects out of the box.
I also thought about creating a shared.config file in the Solution Items. Then linking that file inside each project. And in the Web.config of each projects, add: <appSettings configSource="shared.config" /> pointing to the linked file in that project.
Though I cannot find any reason why not to do this, first implementation failed. It seems (at least during development), c# cannot find the linked shared.config file. I'm guessing linking files is not done instantly nor maintained after creating the linked file, but the file is only copied to the projects WHEN I do a publish. Thus leaving the file missing during development. Is this correct?
The config files are app specific. This mean that you can add a config file to a class library but the file will then by used by the app (windows service, webservice and so on) referencing the library.
Same thing for external configSource, this are app specific as well and need to be included withing the project using it.
So if your solution is composed by 2 projects you then need 2 config files. One for each project.
While for a windows based application(services, winforms) the expected folder for config files is the bin directory, for web based projects this will be the directory is the root folder of the virtual directory.
This said, using a shared config file looks the easier solution (and you don't have to copy the app.config from the class library for each project). Here are the steps :
Create a solution folder.
Add the config file to it.
Add the file as a reference for each project needing it. Right click the project and Add existing item - > Choose the file and Add as link
Ensure the file is always copied by setting the copy option (properties of the file) with Copy Always.
At this point you should have the config file deployed into your project directory everytime you compile the solution.
EDIT:
I'd avoid looking into the bin for config files within a web app, the
convention is that file should be in the root, so I would avoid the
first option.
Linked files end up in the bin after building the project. Try the same steps for importing the file but this time simply add it (not as link) and it will be deployed as content in the root of your site, so it can be always available.
If your hosting in IIS it is possible to have a single web.config file at the root site level but Giorgio is right in that app.config files are app specific. it is possible to use custom build steps to automate the copying of config files across multiple projects so personally I would go with that.
This actually drove me a bit crazy. In the end I fixed it like this:
Created a Shared.config file in the dll project 'common', having the contents look like any ordinary web.config/app.config.
Set the file to be Content and Copy Always, so it would surely be copied out to all projects that reference project common. (Though the config file will indeed end up in the bin folder.
Created the class SharedConfiguration inside the common project. The really tricky part was having to use OpenMappedExeConfiguration() , and getting the path to the executable directory (including bin, and without file:// in front of it).
Now when I want to access a setting from the shared settings, I do SharedConfiguration.instance.AppSettings.Settings["CubilisEntryPointUrl"].Value.
(I cannot use SharedConfiguration.instance.AppSettings["CubilisEntryPointUrl"] directly because of this issue)
.
public static class SharedConfiguration
{
public static readonly Configuration instance = GetConfiguration("Shared.config");
private static Configuration GetConfiguration(string configFileName)
{
ExeConfigurationFileMap exeConfigurationFileMap = new ExeConfigurationFileMap();
Uri uri = new Uri(Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase));
exeConfigurationFileMap.ExeConfigFilename = Path.Combine(uri.LocalPath, configFileName);
return ConfigurationManager.OpenMappedExeConfiguration(exeConfigurationFileMap, ConfigurationUserLevel.None);
}
}
I have an asp.net project that is using Entity Framework that is used on several different client servers. This means a different web.config for each for connectionstrings and app settings.
Hasn't been an issue but I changed something that altered the web.config file recently and I manually had to adjust this for each client, I also have to exclude the web.config file in updates to ensure their own one is not overwritten.
What I would like to achieve is store these settings in maybe another config file that the project can pick up and use. Maybe that on Globals Application_Start gets these and imports them/overwrites the current web.config file perhaps.
Essentially I don't want to affect the current code that uses the connection string and ConfigurationManager.AppSettings used throughout the project but I do want to be able to let the web.config file update for each client and use a seperate file for some settings.
NOTE: I do not have access to publish directly to each server so I can't simply write a different deploy web.config for each one. I have to publish the files locally, store as zip and automated routine on servers downloads and extracts accordingly.
EDIT:
Please do say if this is considered a bad idea but an idea I had was to put something similar in Global.asax Application_Start method:
Does config file exist?
If no, create file and append all current settings in web.config
If yes, open and import those settings to the current web.config overwriting the original values
Hopefully then in a few weeks time, after I have asked all clients to perform a manual update they will have this code and I can begin to include the web.config in updates.
In VS, inside the Build menu, the last item is Configuration Manager.
In here you can specify various different release environments which can each have their own web.config transforms.
This is normally used for production/staging/test environments. However, I can see no reason why you could not use this and have a configuration file for each of your servers/environments.
You will then need to create the transformations for each environment, by rightclicking the web.config, then selecting Add Config Transform.
each of the environments you had setup can then override the settings in the main web.config. (That now acts as a template/default settings)
e.g.
In Web.EnvironmentA.Config
<add key="ConnectionString" value="ConStringA" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
In Web.EnvironmentB.Config
<add key="ConnectionString" value="ConStringB" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
Then when you do a publish, you simply setup which config file to use. If you use Azure or the VS publish method, it will save each of these settings, so then you can simply push to the relevant environment easily.
Just make sure you test this works as you intent first, before you start publishing everywhere ;)
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.
I have looked around and simply cannot find a way to open a linked XML file. My folder structure is like this:
...\projects\ConfigService\
...\projects\Shared\
...\projects\WebTool\
Inside the Shared folder I have a single XML file that will be modified by the WebTool project and read by the ConfigService (many times after each one is built and running). To make things as simple as possible, I simply tried "add as link" at the XML in each project, but then how do I actually get a full path to the linked object so I can open it? I use a link because the file will be changed after my projects are built, but I will not rebuild.
All answers I have found either try to pack the linked file into the project's binary, or the instructions are for adding classes/code instead of just a flat resource.
Or is there a better way to do this?
The solution that worked out best for him was to use the Server.MapPath() method to find his Shared folder regardless of where in the file system his website was rooted. Since it will always be [virtual-directory]\Shared this works out perfectly and he doesn't need to worry about config settings.
I think you want to use an app.config file to resolve this. Here's how you would do it.
In the WebTool service, and in the Config service, add an app.config file with the following text:
<configuration>
<appSettings>
<add key="XmlFileLocation" value="c:\folder\projects\shared\myfile.xml" />
</appSettings>
</configuration>
Then, you can retrieve the file location in each program by using the following:
string filepath = ConfigurationManager.AppSettings["XmlFileLocation"];
You'll have to add a reference to System.Configuration in your projects though.
Good luck!
Two ways to go
One depends on how you are going to deploy. If they are all going to same folder, the Mr Oded's solution is a quick and simple.
If you are deploying to a more complex folder structure e.g
MyApps
Shared
ConfigService
WebTool
The create a folder structure that mirrors that and set the output directory in each project to the relevant one (instead of the default bin\debug bin\release). The you can grab it with a relative path from from each tool e.g. (..\MyXmlFile.xml).
That said, I like neither of the above.
What else in shared? If there's a dll, then may be it should have a method that returns the location of the file, or the content, and let it manage where that location is.
PS don't forget seeing as it is exposed on the file system (somewhere), you need to cope with some well meaning individual deleting or modifying it.