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.
Sitefinity deployment breaks down into roughly 4 parts.
Before continuing be sure to test the web site thoroughly in your development environment. Troubleshooting development issues in a production environment is extremely challenging.
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:
For more tips, see the following documentation:
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.
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.
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.
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.
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.
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:
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.
DECLARE tabcurs CURSOR
SELECT 'dbo.' + [name]
WHERE xtype = 'u'
DECLARE @tname NVARCHAR(517)
FETCH NEXT FROM tabcurs INTO @tname
WHILE @@fetch_status = 0
EXEC sp_changeobjectowner @tname, 'charity'
FETCH NEXT FROM tabcurs INTO @tname
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.
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.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
Copyright © 2019 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.