In the recent development of v2.0 we moved more towards using the config file instead of the registry, which is great for server side processes, and is something I do not expect to change.
However the client tools that we then develop are not so capable of working with configs for a couple of reasons.
- Part of our product is an IExcelRTDServer (see MSDN) which will always exist only as a dll. Since it has no .exe component then it cannot have a *.exe.config, (unless you wish to go the route of saying it will only ever be called from Excel (not a test harness) and therefore modifying excel.exe.config, which I would be opposed to).
- Where more than one tool (including Excel & GUI) is deployed on a single client dekstop, we would have multiple config files. These would each require changing if an organisation would change its server config.
- All tools developed using the new API interface will also effectively hand over responsibility for settings like remoting endpoint, and database connection string to the API.dll. Unless each tool hands over its config file, we have the same issue as for Excel (see point 1.), and if you do (which would be impossible for Excel) you still have multiple configs (see point 2).
All comments appreciated,
Al.