I have implemented a custom file configuration, that uses custom sections, using C#.
The main issue i have is with implementing some kind of version aware configuration loader.
Confgiurations change, but we need to make them usable anyway.
Is there any documentation that points in the direction of having some kind of versioning in configurations?
I'll give you two examples on what my issues are:
- key["key1"] changes from boolean type to int type.
- key["key2"] mandatory ceases to exist
thanks.
My tendency would be to add some kind of version header to the configs and keep a history of their schemas in the app. It could be troublesome in some ways, but at least you don't have to guess what an old value meant.
You could have the concept of default values for each setting. If you introduce a new setting and an old config file doesn't have it then it would use the default value. Similarly, if you remove a setting from the code then its existence in the config file would be harmless, it would just be ignored.
If you want to change how a given setting works (the type or the format) then it's a little more tricky. You could try to parse the value and if it's not in the right format you could ignore it and use the default value.
Related
I have a component that have some default values. These values are used when some classes are instantiated, so the properties will be, by start, filled with the default value.
If you will ask why i'm doing these is because, these values, will be the same in the entire application. So there is no need to always repeat the same value, every time an instance is created.
So I'm thinking in 3 ways this can be done:
1st like a custom .config class as in this topic.
2nd using .config appSettings by adding add tags.
3rd using some static or singleton class that have the properties of each value.
My question is, how these strategies is the best or there is other that i miss?
Well! I would suggest you go with 2nd option.
using .config appSettings by adding add tags.
The reason is .config will also be included in client version. So what if you want to change or modify some of the values in the near/far future? Would you change them in code and rebuild all the application?
I think modifying the values in .config in deployed version will be more easy and will save your time. Trust me! when you have to re-build entire application just for a minor modification it is an overhead. :)
Hope that helps. :)
Honestly, I think any of your choices is fine. My recommendation is to pick whichever approach feels like the best and go with it. With solid practices, refactoring to a different pattern later should be straightforward. Plus, by starting, you will quickly learn a lot more about the problem domain allowing you to make a much better (and easier) decision.
Having a bit of trouble getting this right...
The main objective is to have user configurable password strengths and here's where I get stuck:
There's a setting in some config file somewhere that specifies the minimum password length to be seven and I can't for the life of me find the blasted thing, I've checked the the app.config for the specific provider implementation, the web.config for the solution ( where the parameter is mentioned but set to 1), and I've even checked the .config files for anything even touching this but there's nothing. Kinda frustrating.
Well, the minRequiredPasswordLength is configured in your Membership provider section. Take a look at this question to see an example where it's set to 6.
Given that, you should access this value using the following property on the Membership type:
var minPassLength = System.Web.Security.Membership.MinRequiredPasswordLength;
If it doesn't work maybe you have a custom provider implementation that overrides the property value set in Web.config - see here for an example. In this case I'd suggest you do a search in your entire solution to find the string minRequiredPasswordLength and see from where this value is coming. If the custom provider comes from a third party DLL, you must have access to the library code to change that value.
What's the appropriate way to design the following application:
I have some IAlgorithm objects, each of them has it's own settings. Obviously, I would like to store the settings in some settings file and easiest way to do it would be to utilize app.config.
Now, I have an injection scheme, where objects using algorithms are set up the following way:
Bind<IAlgorithm>.To(new SimpleAlgoritm(simpleAlgorithmSettings));
Bind<IAlgorithm>.To(new ComplicatedAlgoritm(complicatedAlgorithmSettings));
The first way that comes in mind would be to make something like:
var simpleAlgorithmSettings = DeserializeSimpleAlgorithmSettingsFromConfigFile();
and then pass them into the object bindings.
Still, I assume something better can be done here, but I can't come up
with a really nice idea, so any help
would be appreciated.
Also, what are the alternatives for
the app.config usage for such
cases?
You can use app.config, but let the single alorithm type to pick for his settings. From the algorithm code, even if it is declared in another dll, you always have the ConfigurationManager pointing to the current application config file.
What is the difference between configuration.Save(ConfigurationSaveMode.Modified, true) and configuration.Save()?
Background: I have a programme, where I manipulate a web.config, which I use for configuring WCF Services. I load it into a Configuration object, change some attributes and save it back. When I use configuration.Save(ConfigurationSaveMode.Modified, true) I get an Exception like this:
"It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level..."
When I use configuration.Save(), then it works! The reason for the exception may be the section <serviceActivations> in my web.config (the exception points to this section)
The default parameters to Save are:
Save(ConfigurationSaveMode.Modified, false);
So the only difference would be that you force saving the configuration, even if it was unchanged. See http://msdn.microsoft.com/en-us/library/ms134089.aspx for more information.
Why woyld you write configuration.Save(ConfigurationSaveMode.Modified, true) when:
ConfigurationSaveMode.Modified means:
Causes only modified properties to
be written to the configuration file,
even when the value is the same as
the inherited value.
true means: true to save even if the
configuration was not modified;
otherwise, false.
Isn't the first option the opposite of the second?
ConfigurationSaveMode.Modified only saves the parts of the configuration that are different to the application/system configuration to a user local or roaming configuration (i.e. using ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel) with ConfigurationUserLevel.PerUserRoaming or ConfigurationUserLevel.PerUserRoamingAndLocal).
Since ASP.NET doesn't have user levels (and user isolated storage) this doesn't make sense.
From the documentation is not clear if any of the Configuration.Save overloads will really work in the case of ASP.NET which uses a completely different configuration setting inheritance model to non-ASP.NET .NET applications. In practice using one of the WebConfigurationManager to load the configuration manager is likely to be a necessary pre-condition to saving the file.
Another approach might be to explicitly load a explicitly designated file with ConfigurationManager.OpenMappedExeConfiguration.
I wrote a class library in C# that uses a external XML file to store some data. I use this data (encoded rules) directly in the class library to do some substitutions within a text parser. The rules within the XML:
<rule>
<word>h e l l o</word>
<sub>Hello</sub>
</rule>
When I share the lib, I also have to share the XML. This is a bug source, at least for me ;) My question: is there any common way to solve such issues? Should I use app.config instead?
Thanks for any hint and best regards!
Why not embed the XML within the dll?
As with every external configuration data i can be changed or missing. So your application (or library) has to deal with such circumstances.
This means:
For every missing value you have a default value (should be declared in your documentation)
Check every value for correctness (type, range, etc.) (All input is evil!)
Blame user for invalid config files (error message, etc)
Implement and document behaviour in error case (abort, crash, use default value, etc)
So it doesn't matter which way to go, cause it is a user configuration (which means it can be changed by the user) and so you have to check those entries.
Create the XML file with default settings/values if it doesn´t exist.