Sitefinity Config Files

This is part question and part feedback: I really don't like how Sitefinity 4 uses a whole bunch of external config files to store Sitefinity settings (Toolbox, Load Balancing, etc.)  This setup forces us to copy these files back into our source code every time we make a configuration change or risk that our next deployment will overwrite the settings.  Is there any way to configure Sitefinity to just save this information in the database and/or can you explain why this change was made?  It's simply not a user-friendly setup at all so I'm guessing that there must be some reason why it HAD to be built this way?

Still awaiting response from Telerik.?!

Hello Zack,

Back in Sitefinity 3.x we were using web.config to store all the settings. In 4.x we moved that to a separate folder and split the configurations for each module in a separate file. We believe this is a more user friendly approach, as you don't have one big cumbersome file with all the settings. Unfortunately there is no way of storing this configuration in the database, since even the connection string to the database is inside one of the config files - DataConfig.config.

We apologize for the caused inconvenience.

Unfortunately there is no way of storing this configuration in the database, since even the connection string to the database is inside one of the config files - DataConfig.config.

Yes, point taken about the database connection string, it's the same for all similar systems. But that doesn't justify everything else. I agree with the original poster, this is really annoying to deal with.

Is something in the database? In one or several config files? Both? Just try and find out. I haven't got to test how well load balancing works yet, but I hope it won't make matters worse. But for now, I had to tell my clients to let me handle all the configurations of the CMS, so I can have all the config files under source control, then deploy them (I added them to the solution, and copy them on build). A bit of a shame, as that takes some value away from the CMS, ie: letting admins configure it.

You're basically forcing us to learn the internal workings of Sitefinity in order to use it efficiently. And as any OOP coder knows, this is a design smell. I should be able to just publish my app and connect it to the right database to get things working. This is not possible with Sitefinity, unless you include all the config files with the app.

The only positive side that I can see is that it's easy to revert corrupt config files when they're under source control. Then again, they shouldn't get corrupt in the first place.

A couple of points that I'd like to clarify:

I too understand that the database configuration string must live SOMEWHERE outside the database.  I also understand the reasoning that it was put in one of the Sitefinity-specific configuration files for the sake of consistency.  That said, the problem this causes is that we no longer have the option of using the built-in Microsoft config transformation functionality to swap out build environment-specific (production, staging, dev, etc.) connection strings.  Thankfully we can use pre-build events like this solution detailed by Scott Hanselman to achieve a similar result, albeit with a good deal of additional hassle.

Also, I need to reiterate that when we make a configuration change through the Sitefinity admin interface in our production environment, the Sitefinity config files in production are updated.  The way things stand at present if we do not then take the MANUAL step of copying those files back into our source control system, the next time we deploy our code to production (this happens FREQUENTLY with us as we develop new server and user controls for use in our Sitefinity environment) THOSE SETTINGS WILL BE LOST!.  I fail to see how this makes ANY sense and I truly do struggle to believe that you have not received this feedback from MANY other customers (or perhaps they just haven't worked with v.4 long enough to notice this yet).  As Thomas said, the ONLY setting that really can't be stored in the database is the database connection string itself, and my hope is that Telerik (specifically the Sitefinity Team) will give some consideration to making this a high priority upgrade.  I really do like Sitefinity and I am very impressed with most of the changes that have been made in v.4 (except for the fact that I can't use Shared Content Items in Page Templates, but that's another rant) and I would probably still recommend it to my developer friends but I would do so with some reservation and would certainly note this issue as a big drawback.

Hi Zack and Thomas,

Some of your points are indeed valid and are good suggestions. We will definitely take into consideration them in our effort to improve the customer experience. However you do understand that this will be impossible for Sitefinity 4.x, as this way of handling the configuration is very deeply cemented in the foundation of our CMS API.

Maybe try to sneak in an abstraction layer / interface, that lets you either read/write from config files or read/write from database, depending on a flag value? If your configuration reading/writing code isn't all over the place, this could be doable. Or write a migration tool from config to DB, and then only handle database data...

Thanks for acknowledging the problem, anyway. I know there are higher priorities.

Hi Thomas,

As I mentioned this is a very complex task and there is a very high chance of regression so it must be tested very thoroughly. I don't think this might make for any of the 4.x releases. Thanks for the good suggestion however.