What is purpose of either of that files?
When to use appsettings.json?
When to use runtimeconfig.json?
appsettings.json is for configuring your application. You (or your IDE) create this file. You manually maintain it with changes that you need.
runtimeconfig.json is an internal configuration for the .NET runtime, used when it needs to run your application. Generally, you don't touch, edit, maintain or even version control this file. It's created automatically when your application is built.
It's never an either/or situation: you generally use both. appsettings.json is used explicitly/manually, while runtimeconfig.json is generally used under the hood and very rarely used manually.
The appsettings. json file is an application configuration file used to store configuration settings such as database connections strings etc. This is basically a configuration file for configuring your application. You can able to edit it manually, whenever the changes are required.
The runtimeconfig. json file is generated automatically in the output directory when the application is built . It is basically a internal configuration for the .Net Runtime. There is no need of making any changes or any edit in this file manually as it is automatically generated at your application's Runtime.
Related
I have a different developer, besides me, working on a Asp.net project (.net 4.5) on Visual Studio. The problem is that I use http://localhost/MyProject as my local server url, while he uses http://localhost:51123, probably because default port is already taken by another server.
The problem is when he commits a change to .csproj file, it change this configuration for me , and i have to change it back. And he's probably having the same problem when I change.
Is there a way for us to use different webserver, while allowing us to commit changes do .csproj file? (For when we add a new class or page, for instance).
How do you deal with that in your projects?
You can have 2 entries in appsettings configuration like
"AWebserver" : "AProject",
"BWebserver" : "BProject"
where the url is passed use the Configuration object to read from the appsettings with your particular server key. It will make it a bit easy to
as you only have to change the key that is being passed in the configuration object.
We have a web application running on-premise at a variety of customers. The web.config contains lots of
stuff which is "part of our application" (such as most of the <system.web> and <system.webServer> blocks) and
stuff which needs to be customized (connection strings, app settings, and various custom tags).
During updates, part 1 should be replaced and part 2 should be left as it is. Ideally, I'd have a web.app.config and a web.custom.config, so I can replace only the first one. Of course, IIS would need to magically "merge" those at run time, which it does not do.
I found the following approaches:
Put the custom stuff in external files, i.e. <appSettings configSource="appSettings.config"/>.
I cannot use that, because it can only be used for complete sections. But, for example, the aspnet:MaxHttpCollectionKeys setting is a value that should be controlled by the application, whereas other app settings values should be customizable.
Parameterization or Web.Config Transformation.
I cannot use that, because our customers have various versions of our application installed. Thus, I need to replace the application-specific parts of web.config rather than transforming individual tags. In addition, I'd like to avoid adding msdeploy to our deployment process (xcopy plus some scripts to create the IIS apps and configure them work great at the moment). Oh, and I'd still have one big web.config with application-specific and customer-specific stuff meshed together.
Is there some elegant solution that I've missed?
It's true that configSource is used for complete sections, but appSettings has a special attribute called file which can be used to reference a file to be 'merged' into the appSettings list. See https://msdn.microsoft.com/en-AU/library/ms228154(v=vs.85).aspx for more details. I've used extensively to merge in an appSettings.config file with environment specific values - either local dev values (as contained in the repo) or a file that is dumped onto the server with environment specific settings. Helpful when promoting a build artifact through qa, uat, prod environments etc. For you, that file could contain your customer specific values and would not change when you deploy updates.
An alternative approach would be to refactor your customer specific configuration into a Custom Configuration Section. As well as giving you typed access to the configuration values, you can load it from a section in the web.config, load it from a section in the web.config that references another file via configSource, or you can load it directly from a separate file.
You can then leave your application configuration in the appSettings, or move it into a separate custom configuration section.
Ok so i have 2 classes so far that i want to put in my common dll, logger and db. im moving them from my current project to a new class library project and changing their namespaces and whatnot. The issue I am having is that I wish to use the app config of my application (or any app that I want to reference my commonlib.dll) but I dont know how to use the referencing projects app.config. Is there any way to do this?
The OpenExeConfiguration() methods of ConfigurationManager are your ticket. One of them will take a path to the executable, allowing you to open the app config of a specified application (even a different one; you can use this technique to change the configuration of another application before launching it with Process.Start()). The other one will open the app.config of the current application (even if your library is used by multiple apps) for a specified user level (All users, current roaming user, and current roaming and local user). Usually, when dealing with an actual app.config, you want the one that applies to all users; the per-user configs are stored in each user's AppData folders.
Also, one last thing; unless your library has its own config file, the ConfigurationManager properties, like AppSettings, will be populated based on the current executable's app.config. So it could be as simple as using those properties. Keep in mind that those properties are read-only and only loaded once at program startup, so if you make changes to your config during program execution that you want to be effective immediately, it's better to explicitly load/save config files.
Scenario
Consider having a solutions with 4 projects in it:
1) ProjectSql: This is a project, whose compilation output is set to Library, and this is responsible of accessing a SqlServer database and do something. The final library will be able to provide APIs in order to manage persistency for the final application.
2) ProjectWCF: This is a project, whose compilation output is set to Library, and this is responsible for defining service contracts, data contracts and service implementations to let my application host a service.
3) ProjectMiscellaneous: This is a project, whose compilation output is set to Library, and this is responsibe to provide APIs for other things.
4) ProjectApp: This is a project, whose compilation output is set to Executable (Exe), and this is responsible for creating the business logic of my application. Suppose this to be a simple Console application. This projects has references to all the other ones.
Assumption: Consider that every project has its own configuration file. ProjectSql, for example, defines connection strings to connect to a database and so on...
Problem: Configuration
Well, my problem is the following: consider that my application project ProjectApp uses ProjectSql, well, every call to a operation in ProjectSql needs to connect to database, in these calls the ProjectSql configuration file is referenced to get connection strings (a simple call to System.Configuration.ConfigurationManager....).
I think that if my ProjectApp, with its own configuration file, makes a call to an operation in ProjectSql, then, that operation will reference to its own configuration file.
My question is:
What I said, is it true???
Do configuration files respect the project hierarchy.
System.Configuration.ConfigurationManager can be told which config file to read. Any given app will normally have one config like appname.exe.config or web.config.
So the answer to you question is NO.
When you call System.Configuration.ConfigurationManager for any of the class libraries, it is the ProjectApp.exe.config file that is read.
I have a Solution with 3 projects in, each project needs access to certain settings. I'm looking for a way to have these setting values available to any project from 1 distinct source. I cant use the .Config file as that is relevent to that particular project.
I could use the database but have been told this is not good practice (Without an reason)
Any ideas?
You could do this:
create a solution.config in your solution folder
in each project's app.config, add this to your <appSettings> node:
<appSettings file="solution.config">
....
</appSettings>
You would have to put symbolic links to your common solution.config in each project folder - but you could have one single physical file that you share amongst the projects.
The <appSettings> node is the only one that allows that sort of "cummulative" settings - those from the file specified in the file= will be added to your app settings, but potentially overwritten by anything you specify explicitly in your app.config.
On the other hand, yes, of course, you could use the database. We do that, too, in most of our projects, since we typically do have access to the database, but not to the file system in the client's server machines. I don't see why that should necessarily be a bad thing - we have settings for DEV, TEST and PROD in a table - so you have all your settings in one place - and we pick those settings we need when we need them. Works just fine - of course, some settings like the connection strings to the database cannot be stored there - but the bulk of our config info is. Again: I really don't see any reason why this should be a bad choice per se - so unless your source can back his/her statement up with some facts and reasons, I'd ignore it.
You can define configSource attribute in a defined configSection, to reference an external file from which to load your properties.
Here you can find an example:
Is there any way for an App.config file to reference another full config file? (.NET)
You can also use a DB of course, but that would probably involve developing some kind of configuration console, since it's not a good practice to manage config attributes directly into DB.
Otherwise you can create your config file (an xml, or yaml for example) and create your own shared config parser.
I create a class to hold system-wide settings using either a Singleton pattern, or a Global instance (whichever you preference is).
If another project is in the solution, it can see the class (when references are added).
This also decouples the presentation of the settings from the storage mechanism (database, config file, custom XML file, whatever), and if you design to the interface, it makes unit testing more flexible, too.
You could add an entry into each projects .config file that points to the global one. You would need to read that in three places though.
Another solution that springs to mind is to put your common settings into their own assembly with it's own .config file. You then include that assembly in each of your projects. The .config file is read in the assembly and you can read out those values you need.
What kinds of settings?
You can use the system wide machine.config and web.config files for settings that apply across an entire machine.
\Windows\Microsoft.NET\Framework[64]\[version]\config\machine.config
\Windows\Microsoft.NET\Framework[64]\[version]\config\web.config
You could use the registry if you have access to it. Then all you would need is a class to read them out (and possiblty one to put them in) and each project could use that class to read them.
The major downside though is that you would have to add the settings to each machines registry that you run your solution on.