How to deploy Sitefinity 4 to shared hosting

How to deploy Sitefinity 4 to shared hosting

Posted on June 02, 2011 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

The day has finally arrived for your Sitefinity web site to leave the house.  It has been completed, tested and is ready for the web. However, publishing the web site requires it to be transferred to the production server.

We have documentation that covers 3 different Sitefinity deployment scenarios (shared hosting, private server, cloud server).  However, customers occasionally encounter deployment challenges that aren’t explicitly addressed in the documentation. 

This blog post & the accompanying video demonstrate how to work through these challenges.

How to deploy Sitefinity 4 to a shared hosting server video

Sitefinity Deployment, in a nutshell…

Sitefinity deployment breaks down into roughly 4 parts.

  1. Configure the production web server
  2. Modify the project configuration 
  3. Transfer the web project files to the production server
  4. Transfer the database to the production database.

Before continuing be sure to test the web site thoroughly in your development environment.  Troubleshooting development issues in a production environment is extremely challenging.

#1 - Configure the production web server

Shared hosting accounts are frequently limited regarding the IIS configurations that can be applied to the web site.  In some cases the Control Panel (provided by the shared hosting provider) might enable some IIS settings to be modified.  In other cases, these configuration changes will need requested through hosting support.

In either case, there are a couple things to pay attention to:

  1. Sitefinity requires .NET 4.0.  If the web site is using an older version of the .NET framework then Sitefinity will not run.

  2. Sitefinity has minimum memory requirements.  Many shared hosting providers limit the hosting account to a small memory size.  If Sitefinity is starved for memory then the application will recycle frequently, causing slow load times & sessions timeouts.

For more tips, see the following documentation:

#2 - Modify the Project Configuration

The development environment frequently utilizes a development database than the production environment.  Consequently, during deployment, Sitefinity needs to be reconfigured to use the production database.

The database configuration string is found in the ~/App_Data/Sitefinity/Configurations/DataConfig.config file.  Update this connection string to point to the production database.

Alternately, modify Sitefinity to use the web.config’s connection string.  This enables you to utilize Visual Studio 2010’s transformation feature to easily toggle between development & production environments.

In addition, disabling debugging in the web.config is recommended before deployment.  Debugging slows the application and is undesirable in a production environment.

See the Sitefinity deployment documentation for more information.

#3 - Transfer the Web Project

With the project prepared for deployment, it’s time to move the web site files to the production server.  In most cases this will be done via FTP or through a network share.  Work with your hosting provider if you need details about how to access the production server or where to put the web site files.

See the Sitefinity deployment documentation for more information.

#4 – Transfer the Database

Depending on the hosting scenario, this step can be challenging.  If using MS-SQL Server then Microsoft SQL Server Management Studio Express can be used to Export Data from the development server to the production server. 

Export data in Microsoft SQL Server Management Studio

However, this procedure assumes that you’re starting from scratch on the production database.  Merging a development database with an existing production database is going to require 3rd party tools (RedGate’s SQL Compare) or manual merging.   The goal is to compare 2 databases and then generate a SQL script to synchronize the databases.

See the Sitefinity deployment documentation for more information.

Access the web site and troubleshooting

Everything is transferred and it’s time to access the web site in a web browser.  Hopefully, everything will instantly click into place.  However, it’s possible to encounter several different errors:

Could not load file or assembly 'Telerik.OpenAccess.Web or one of its dependencies

Assuming the web site works in the development environment, then any assembly errors are most likely due to the related DLL missing from the ~/bin folder.  Check the ~/bin folder on the production server and ensure that the DLL file exists.  If it’s missing, then you probably have the Copy Local property set to False in Visual Studio.

Copy Local property in Visual Studio

Invalid root node configured for pages. No root node with the name of "FrontendSiteMap".

This error is sometimes challenging to solve.   It’s likely due to a couple of issues though:

  1. Sitefinity can’t correctly access the expected data in the database
  2. Changing the ProjectName

For the video in this blog post, the issue was caused by my development server using database table names that looked like dbo.[tablename] and Sitefinity, in the production environment, expecting database table names that looked like charity.[tablename]

The solution was to rename the dbo tables to match the charity tables that Sitefinity was expecting on the production server. 

Here are some SQL snippets I used to quickly manage the misnamed database tables.

EXEC sp_MSforeachtable @command1 = "DROP TABLE ?"

I used this to remove the duplicate tables Sitefinity had created on the production database.  (CAUTION:  This SQL snippet will annihilate everything in your database.)

And then, after re-transferring the database from my development server to the production server, I used the following SQL snippet to rename all the dbo tables.

    SELECT 'dbo.' + [name]
      FROM sysobjects
     WHERE xtype = 'u'

OPEN tabcurs
FETCH NEXT FROM tabcurs INTO @tname

WHILE @@fetch_status = 0

    EXEC sp_changeobjectowner @tname, 'charity'

    FETCH NEXT FROM tabcurs INTO @tname
CLOSE tabcurs

Thanks to Anatoly Lubarsky for the script.

For more tips on solving this error, visit the Sitefinity forum thread on this subject.


Everything mentioned in this blog post and shown in the video is based on me learning from customer experiences and attempting my own deployments.  However, it’s difficult to create a single set of instructions that address every scenario. 

Consequently, I’m more interested in showing the overall process and common troubleshooting steps.  I hope that this will help you discover where the problem is, even if it isn’t explicitly shown in the video.

However, we can build on each other’s success.  If you discovered solutions to issues not addressed in this blog post, please share your solution with the community using the comments below.


The Progress Team

View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.


Comments are disabled in preview mode.

Sitefinity Training and Certification Now Available.

Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.

Learn More
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

Loading animation