Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
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?
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.
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.
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.
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.