Combine all of the XML configs

I think in terms of simplicity of the configuration that we should combine all of the xml config files into the AutoSPInstallerInput.xml. This will allow for easier management of configurations for multiple environments.

It would look something like this (config.xml in this example)

Once the script runs, it will have to extract the configuration back into an external file. I can help coding this.

Interesting approach - and I agree in principle; less files to manage would be better. However since there are so few of the config.xml elements that you'd ever need to change, I think we should only include those elements that most users would ever want
to modify. The rest could simply be included (hard-coded) into the script itself. Let me give some thought as to the best & most streamlined approach and get back to you.

Interesting approach - and I agree in principle; less files to manage would be better. However since there are so few of the config.xml elements that you'd ever need to change, I think we should only include those elements that most users would ever want
to modify. The rest could simply be included (hard-coded) into the script itself. Let me give some thought as to the best & most streamlined approach and get back to you.

Brian

Although i agree with you in terms of need, i disagree with hard-coding elements into anything because it limits the usability of your application/script. I see no reason not to have all settings present even if they will not be altered you will never know
how microsoft decides to change something or maybe someone has a very special instalation. Having to go into the script to remove hard coded values is a pain.

All the GUI's that apeared take the part of validation on modifications of the configuration. This drastically lowers the time/effort and mistakes, ammount made.

Other then that i do think its a great idea to have all configuration files inside the main config if you are delpoying multiple farms in multiple locations to have it central with keys and special configurations. I even asked on the AutoSPInstallerGUI
project on codeplex to make the GUI handle the rest of the config files.

I normally stay away from hard-coding stuff too, but with the number of SharePoint newbies out there using AutoSPInstaller I think the less parameters in the XML the better - especially parameters which, in 99% (or 100%) of cases, should never be changed.
Any super-advanced & comfortable users can dive into the PS1 and make their changes there.

The GUIs are getting better yes but still a bit buggy - a manual check of the XML is still required in my recent experience.

So my plan is to review each element in the config.xml, and include those that are typically user-modified in the AutoSPInstallerInput.xml. At script run-time, it will then write out the config.xml so the SharePoint installer can read it. Maybe I'll have
the script check first for an existing config.xml file and use that (rather than try to write out the config.xml each time.