Dependancies and enterprise deployment

I'm really struggling with some of the design concepts behind Sitefinity.

For example, a lot of configuration is held in XML in the App_Data folder, but the application seems to want to change these files itself. This is causing many issues with versioning, source control and working locally connected to a shared dev database. We've tried following the guide to 'store config in the database', however the app_data .config files still have to exist and are still updated! Why? if the idea is that it's stored in a database?

There also seems to be odd dependencies on specific versions of these files. When one developer updates their local installation, breaking changes are made to the shared development database, and the .config files. I find the whole idea of guids that have to stay in sync accross a database and local config files odd.

 Finally, if the application throws any kind of error, it appears to shut itself down and restart, which takes around 60 seconds. This worries me - if one user causes some form of error, the whole application becomes unavailable?

 I appreciate I may be missing something with these observations. Does anyone have more information or workarounds to offer?

This may not be any help to you but..

Yes you need to be aware that all the configuration is stored in the Configuration folder and when you alter settings or create modules these update. If the config is stored in the database the same updates also happen so you need to be aware about how you collaborate between developers. (Yes some configs are still required even when the settings are stored in the database. First they serve as defaults for your project at the time of transfer and two of them must always be present. I forget which two)

Generally I exclude my configuration folder from my project and check ins. (I never deploy it unless I am doing a whole site refresh)

By updates if you mean SF updates, yes you have to have a well planned update process. You can't have one dev updating randomly and then expecting to merge up changes with out issues. I generally follow. Everyone checks in. One gal updates. Everyone gets latest.

The Site Sync module is something that could solve a lot of your potential issues, (if you can afford) But again it does require a good process of dev and deploy to ensure smooth process.

I can't say what you crashes issue is expect to say that I don't have such issues with my projects.

Thanks for the comments Darrin.

I understand that is how it is - I'm just disagreeing with some of the design decisions, that don't appear to serve any real purpose.

The config file one is a real puzzler. Sitefinity generates the default config files itself, so why do they need to be present if we've chosen database storage?!

The error's I mention were caused by a bug in 5300, but they've made me very nervous about any other unforeseen circumstances causing down time for everyone, rather than just the particular user who ran into a problem.

 As well as this, every time I hit a page on our development server it takes around a minute to load, before speeding up during subsequent reloads.

I do hope some of these fundamental issues will be resolved in a future release.

Hi Daniel,

You do not need to turn on database storage for configuration files in case you not need this, for example in Azure or Load balancing environment. After setting the config files to be stored in the database - they will be saved there from now on - and only the part that need to be changed. All the current settings will be get (read) from the file system

Regarding the start-up time of the application - note that after the application pools is restarted, pages need to be compiled and this is done on the first request to this page. This is how asp.net works and that is why the first request after a restart takes longer. In .net 4.5, there are settings and improvements that can improve the start-up time - Recommended environment settings for Sitefinity, An easy solution for improving app launch performance.

These settings will help with the startup, in addition to this, you can use one of the options described in the following blog post:

Sitefinity performance boosters - keeping your pages warm. 

Not sure what your reply relating to config files meant? It doesn't address anything I've previously mentioned.

Regarding start up time, I understand how ASP.NET works - I've been using it for five years. I don't understand why the pages take so long to compile. Nothing we've ever built has a start-up time that comes near to the delays seen  before a page is loaded.

 I find the idea of 'keeping your pages warm' a bit of a cop out - the application should be performant anyway. However, looks like that's the option we'll have to use.

Hi Daniel

Answering your question earlier on why the configs are still required.

When you transfer the config settings to the database the setting means that any new config changes will be saved in the database. It doesn't actually transfer all the current settings to the database. The configs are still used for the defaults.

 Personally I don't like this either. I would like a switch which literally copied all config settings from one area to the other but that's the way it is. (Life gets worst if you want to move back to config files.) I would suggest you stick with config files if you can.

As for your page performance. I would suggest you zip up your project and database and log a support ticket with Sitefinity to review.

I haven't had such issues as you are experiencing. It could be a particular way you are calling for some data. I really can't say as I have no idea about your project except to say it doesn't sound normal.