In the course of creating some components for iMIS, I find the need to have some additional settings, global to all my components running in this instance of iMIS, but independent of other instances.
In iMIS 10, I would tend to put these settings in System_Params or Gen_Tables, or sometimes create a UDT in Customizer.
The web.config in the Net folder comes to mind as one place I could put these. It seems like a good idea, since I'll have to review that file when copying \Net from test to live anyway.
- If I use names that ASI doesn't/won't use, can I safely do this? (E.G. AppSettings > RSMSettings > MySetting)
- Should I be concerned about these settings being lost by an iMIS upgrade?
- Do any of the iMIS utilities grab the standard settings, plug them in a new file and overwrite the old one?
If web.config is a bad idea, what is a better one?
- What is the logical offspring for System_Params?
- Can I safely add settings of my own creation to that table?
- Can I expect them to be left alone by iMIS, and preserved through an upgrade?
- Are there any existing iMIS screens which may expose my new settings so users can manage them without going into SQL? (And do I need to format my new settings a certain way to allow this?)
Our internal decision
Our internal decision process for settings goes something like this:
Are the settings per-server or per-database? (i.e. things like local paths should be per-server, since paths may differ from appserver to appserver, while financial settings might be per-database.)
If the settings are per-server, then they should go in web.config. As long as you use a naming convention that will not cause collisions (for example prefixing with your company name followed by a period) you can use appSettings just fine; otherwise, a custom section is entirely fine. Web.config does get rewritten on major-version upgrades (but not in patches), however, so customers will need to re-apply any changes in that case.
Per-database settings can go either in System_Params, Gen_Tables, a UDT, or (if you want the new shiny way) in the SystemConfig table (and use the Asi.AppConfig.GetConfigValues/GetFirstConfigValue methods to retrieve those). As far as I know, the contents of these tables should be preserved during upgrades; only system settings would be modified, added, or removed during an upgrade.
As far as I know, there is no general Ref table editor yet (we keep meaning to add one...). There is a way to set up pages under System Setup to manage entries in SystemConfig; I'll write myself a note to doc that, maybe next week if I get a spare hour.