If you’ve been using TDS to do automated deployments for Sitecore, you’ll eventually need to start deploying to a new environment.  Maybe you’ve set up your local environment, and now you want to get that process working in a daily build environment.  Maybe you want to automate deployment to a QA or Staging environment.  Maybe you’re trying to do continuous deployment to Production.  In all these scenarios, you’ll come across a few hiccups when first setting up the new environment. Below I’ll provide some troubleshooting tips for these common issues…

Deploy Succeeds but New Environment is Not Updated

Let us assume we are trying to set up a new Staging environment based on a Daily Build QA environment.  The build definition has been executed to perform a deploy and everything seems to have executed without errors.  For some reason, however, the Staging environment isn’t receiving any of the data.

How does this happen?

This is usually caused by misconfiguration in the build definition or the website, especially when duplicating an existing environment or existing build definitions.  Here are a few troubleshooting steps:

1. SitecoreWebUrl: In the build configuration, is this build parameter set to the new Staging environment site, or is it still pointed at the Daily Build environment?
2. SitecoreDeployFolder: In the build configuration, is this build parameter set to the new Staging environment site, or is it still pointed at the Daily Build environment?
3. ConnectionStrings.config:  Are all of the connection strings in the Staging environment site pointed at the new staging databases, or are they still pointed at the databases for the Daily Build environment?

Error: Access to Serialization Folder is Denied

After initially setting up a new environment, the first deploy might throw a build error such as :

sitecore\content.item (1): Deploy of /sitecore/content failed. Reason: Access to the path 'C:\MySitePath\Data\serialization\master\sitecore\content.item' is denied.

This error means that TDS and Sitecore do not have sufficient permission to write to the Serialization folder inside the Sitecore Data folder.

How does this happen?

This usually occurs if the new site instance was created by copying from an existing site instance on another system.  The Serialization folder is initially created with appropriate security assigned to the application pool identity that created it.  If the new instance is installed on a different system by doing a file copy across the network, the NTFS settings from the original source are retained.  However, the application pool identity from that original source system will not exist in the new target environment but will still be associated to the Serialization folder’s security settings.

We can manually fix the NTFS settings, but the easiest fix is to delete the Serialization folder and let it be recreated during the first successful deploy.

Error: Length of Field Content Does Not Match

During a deploy, the build may show build errors such as the following:

sitecore\content\Configurations\MyConfig.item (1): Deploy of /sitecore/content/configurations/myconfig failed. Reason: Error reading item: /sitecore/content/Configurations/MyConfig
Failed to load version 1 for language en
Length of field content does not match the content-length attribute. Field name: Value, field id: {C8B4641D-C20D-4424-84B3-5ED37AF9CD33}

Each field that is source-controlled by TDS stores in the .item file the value of the field as well as the character length of the field value.  This error occurs during deploy if the length in the .item file no longer matches to the character length of the value.

How does this happen?  

Usually, this occurs due to a string replace action.  For example, if we were trying to replace all instances in the solution of “myqasite” with “mystagingsite”, the .item files in the TDS projects would also be affected.  At first glance, everything seems fine and compiles.  However, because the two strings are not the same length this will cause the field values to come out of sync with the stored character lengths.

There are a couple of options on how to fix this:

Manual File Update

1. Open the .item file (F7 in Visual Studio) and locate the field that was updated.
2. Copy the offending value into a new file in Visual Studio (or some other text tool) and determine the character length of the value.
3. Return to the open .item file and manually update the content length value stored there to the new character length.

Synchronization

1. Save a list of all the TDS items that were changed during the file replace.
2. Undo the changeset.
3. Go to Sitecore and manually make the changes there for all items.
4. In Visual Studio, open the solution and execute a synchronization on the TDS project.  This will update the value and the content length at the same time.