TDS Support

If you are running Sitecore 6.5 or above, there was a change in the Sitecore API that requires a fix to the TDS Sitecore Connector. This fix was included in the 4.0 version of TDS. If you are still under maintenance please upgrade your version of TDS, to solve this issue. If you are no longer in maintenance please contact sales,[email protected], for assistance.

We recommend having a common web.config across all our environments and use configSource and App_Config/Includes to manage changes. That being said, you can do web.config replacements with TDS Classic. We usually create a separate project to hold the files for the various configs and have file replacements point at the folder that contains all the replacements for an environment.

Here is an example:
 [customer].Config
              +Debug
              |+web.config  
              |+App.config
              |           +ConnectionStrings.Config
              +Release
                          +web.config
                          +App.config  
                                  +ConnectionStrings.Config

This property controls how items are handled during a Sync operation and a Deployment. There are three possible values for this property. They are NoChildSynchronization, KeepAllChildrenSynchronized and KeepDirectDescendantsSynchronized.

During Synchronization the property values work as follows:

NoChildSynchronization: Only the current item is checked for changes. This is the default when adding single items to the project.

KeepAllChildrenSynchronized: All descendants under the current items are checked on Sitecore. If there are items on Sitecore not in the project, those nodes are added to the sync window automatically as children of the current items. The user will have the option of adding them to the project. This is the default when a node is added recursively to the project.

KeepDirectDescendantsSynchronized: Works like KeepAllChildrenSynchronized, but only the direct descendants of the item are checked.

During Deployment the property values work as follows:

NoChildSynchronization: Only the current item is deployed to Sitecore

KeepAllChildrenSynchronized: When the node is deployed to Sitecore, the deployment process checks for child nodes in Sitecore which are NOT in the project. If nodes are found, the Recursive Deploy Action setting is used to determine the desired course of action.

KeepDirectDescendantsSynchronized: This behaves the same as KeepAllChildrenSynchronized, except that child nodes are not checked.

With TDS Classic you are able to automate your builds, and perform continuous integration, with any build server that supports MSBUILD. If you haven't yet evaluated any CI tools we would suggest you look at TeamCity (www.jetbrains.com/teamcity/) as it is a free CI/Build server.

You can use TDS Classic and MSBUILD to deploy your Sitecore items and .NET code automatically. Because TDS  
Classic has some advanced features, such as deploying and packaging, we've created our own .targets file that
ships with TDS Classic. You can find the .targets file at C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets

The targets are:
                         <Target Name="BeforeSitecoreBuild"/>

			<Target Name="BeforeSitecoreMerge"/>
			<Target Name="AfterSitecoreBuild"/>
			<Target Name="BeforeGeneratePackage"/>
			<Target Name="AfterGeneratePackage"/>
			<Target Name="BeforeFileReplacements"/> 

                        <Target Name="AfterFileReplacements"/>   

As an example, let's say you wanted to make a copy of the web root files before any file replacements happen. You
would add the following to the project file (before the closing </Project>)

      <Target Name="BeforeFileReplacements" Condition=" '$(Configuration)' == 'Debug' ">
         <!-- define the new location -->
         <PropertyGroup>
         <_CopyPath>$(OutputPath)..\$(Configuration)_COPY</_CopyPath>
         </PropertyGroup>
         <!-- Grab the build output -->
         <ItemGroup>
         <_OutputFiles Include="$(OutputPath)\**\*.*"/>
         </ItemGroup>
         <!-- write a message to output window -->
         <Message Text="Destination: $(_CopyPath)" Importance="high" />
         <!-- clean it up -->
         <RemoveDir Directories="$(_CopyPath)" />
         <!-- perform the copy -->
         <Copy SourceFiles="@(_OutputFiles)"
        DestinationFiles="@(_OutputFiles>'$(_CopyPath)\%(RecursiveDir)\%(FileName)%(Extension)')"/>
      </Target>

           Read our paper on Continuous Integration with TDS and MSBuild for more information.

Yes. This is supported.

You need to set the “Recursive Deploy Action” in the property window for the configuration you are setting up. See image.

We usually choose “Move to Recycle”.

 The “Child Item Synchronization”(CIS) will control what the package does when it sees an item that isn’t in TDS Classic. If CIS is set to “None”, the item is ignored. Otherwise it is deleted/recycled.

There are many things that would cause delays deploying items. We typically see about 500-1000 items deployed in under 30 seconds. One of the biggest contributors to delays is adding large media items. This is simply due to the amount of data being moved.

Can you narrow down which items are causing problems? Set the build output to “Normal” in the Visual Studio options window (Tools-Options. Select Projects and Solutions/Build and Run). Opening the output window and starting a build should show you the progress of the build. Is there one particular item that causes problems or is it slow? When you are deploying, please use Task manager to see if there are any processes using lots of CPU.

Do you have anti-virus software running? It has been known to slow things down. We recommend excluding the SQL databases from being scanned.

TDS Classic supports field level deployment on items that are marked as deploy once. Most items in the content tree should be set to "deploy once", so that they are created if they are not there, but are not changed if they are. There are some fields that you may want to update on these items.

The Renderings field is a good example. To access these fields, you need to set a value on that field in the item and sync the value back into TDS Classic. Then, right-click on the item and select "field level deployment". You can check the checkbox next to the field you wish to deploy, and TDS Classic will deploy the current value of the field to the item when it deploys the site.

Question: I'm doing a deploy and I am getting this error:

 C:\ProgramFiles(x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets(312,5): error : Endpoint not found when deploying /sitecore/content. Deployment Aborting.

 Answer:The “Endpoint not found” means TDS Classic can’t reach the web service. Either, the service name isn’t
setup correctly for the configuration TDS Classic is trying to build or the url can’t be reached from the build server.

The “Endpoint not found” means TDS Classic can’t reach the web service. Either, the service name isn’t setup correctly for the configuration TDS Classic is trying to build or the url can’t be reached from the build server.

Yes. There are two ways of doing this.

First way:
1.In the TDS Classic project explorer select the item that you want to exclude. Right click, and choose properties, or alternatively press F4.
2.In the property window, click on the Exclude Item From property; press the dropdown button in the right-most portion of the property value area for Exclude Item From.
3.Click the check box next to the configuration name you wish to exclude the item

Second Way:
1.In the TDS Classic project explorer select the item that you want to exclude. Right click, and choose Deployment Property Manager (DPM)
2.The DPM shows the Sitecore item you selected along with all items under the selected item. In the Current Config column, there will be two values: Include or Exclude.
3.Clicking on a value under Current Config will allow you to change that value.
4.Selecting a different configuration in the Solutions Configuration dropdown will change the Include/Exclude values under Current Config to match the selected configuration.

Note:
1.Excluding an item from a configuration will exclude all children of that item.
2.Including an item in a configuration will include all parents of that item.
3.A solution configuration may use a project configuration with a name that is different than the solution configuration. Please use the Configuration Manager window to manage this.

You can leverage the "File Replacement" features of TDS Classic. This feature will allow for you to configure individual files as well as entire directories to be included in the package.

Please see the sample project

Update packages are not the same as the normal Sitecore Packages most of us are accustomed to installing. This means that you cannot use the standard package installer to install these.

Instead, you must use the Update Installation Wizard, which can be found here:

http://[your URL]/sitecore/admin/UpdateInstallationWizard.aspx

If you are looking to automate the installation of a package then download the package installer source code from GIT (GitHub Project) . The package installer will let you script your package deployments. We gave you the source because we realize that each of our customers will have slightly different requirements and the ability to customize the source allows for maximum flexibility.

This property controls how items are pushed to Sitecore during a deployment. The two possible settings for this property are DeployOnce and AlwaysUpdate.

AlwaysUpdate: The contents Item in the project will always overwrite the values in Sitecore. This is the default. This is typically used on Items that are not considered to be content.

DeployOnce: The Item will be created if it doesn’t exist on Sitecore. If the Item exists in Sitecore, it will not be changed. DeployOnce is typically used to help setup the initial content tree, but once users begin entering and altering content, those nodes are left alone.

A single TDS Classic project will generate a .update package that would get installed into a Content Management Server (CMS). However, a typical production environment will consist of at least one CMS and 'x' number of Content Delivery (CD) Servers. These CD servers would typically have different configuration files and therefore require some other way to be updated.

In this scenario, we setup TDS Classic with file replacement so that it is building a package for the CM server. We then modify the build definition so that it generates a zip file of all files required for a CD web root. This way, when we do a build we get a .update file for the CMS and a .zip file for the CDS.

This is a bug with Sitecore (Issue #337147).

The fix for this is to manually reset the fields within the Sitecore Content Editor. Versions -> Reset

I am trying to install an Update Package, but the installer fails with the following exception:

Exception occured: System.Web.HttpParseException (0x80004005): The base class includes the field 'logArea', but its type (System.Web.UI.HtmlControls.HtmlGenericControl) is not compatible with the type of control (System.Web.UI.HtmlControls.HtmlIframe). ---> System.Web.HttpParseException (0x80004005): The base class includes the field 'logArea', but its type (System.Web.UI.HtmlControls.HtmlGenericControl) is not compatible with the type of control (System.Web.UI.HtmlControls.HtmlIframe). at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildFieldDeclaration(ControlBuilder builder) at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildSourceDataTreeFromBuilder(ControlBuilder builder, Boolean fInTemplate, Boolean topLevelControlInTemplate, PropertyEntry pse) at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildSourceDataTreeFromBuilder(ControlBuilder builder, Boolean fInTemplate, Boolean topLevelControlInTemplate, PropertyEntry pse) at System.Web.Compilation.TemplateControlCodeDomTreeGenerator.BuildMiscClassMembers() at System.Web.Compilation.BaseCodeDomTreeGenerator.BuildSourceDataTree() at System.Web.Compilation.BaseCodeDomTreeGenerator.GetCodeDomTree(CodeDomProvider codeDomProvider, StringResourceBuilder stringResourceBuilder, VirtualPath virtualPath) at System.Web.Compilation.BaseTemplateBuildProvider.GenerateCode(AssemblyBuilder assemblyBuilder) at System.Web.Compilation.AssemblyBuilder.AddBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.AssemblyBuilder.AddBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at Sitecore.Update.UpdateInstallationWizard.InstallationWizard_ActiveStepChanged()

This is due to a Sitecore bug (#387071).

If the web.config's system.web/compilation element has targetFramework=4.5 then the UpdatePackageInstallationWizard will fail.

As a temporary work around (until Sitecore resolves the issue), set the value to 4.0 install the package and then switch it back to 4.5

This is usually caused by a permission issue on some of the files you are trying to replace in the target directory. The installer creates a log in the /temp/__UpgradeHistory folder that will give you details about the files that are included in the update package. You need to open that file, identify the files with permission problems, correct the permissions, and re-run the build.

TDS Classic purposefully prevents the deployment of files matching the pattern "Sitecore.*.dll". This is to ensure that Sitecore provided dll's aren't overwritten.

Yes you can.

You can have the build split the update package TDS Classic creates into two packages: one for the Sitecore Items that would go into the CMS and then a code only one for the CDS. In the TDS Classic Project properties tab you will see a checkbox at the bottom to generate separate code and item packages.

Another way to approach it is to make a CDS specific configuration that excludes all the Sitecore items and will then just build and deploy just the code. This will allow you to use the file replacements if you need completely different configs on the CDS.

This is a Sitecore bug (#344807/344884) that was resolved in Sitecore CMS 6.6.0 rev 121015. Please take a look at ref# 344884 in Sitecore Documentation.

Unfortunately the best way to deal with this scenario is to manually change the template of the items in each environment.

This is a feature of Sitecore's Update Installation Wizard as documented in their guide available on the SDN.

After installing the update package, you should rebuild the search indexes and the links database.
If the update package contains configuration files, these files will be saved with a different name. This 
makes it easier to manually merge changes to configuration files by allowing you to use a file 
comparison tool such as WinMerge. For instance, if you are upgrading to version 6.1.0 rev.090630, 
this update package contains the clean web.config file for 6.1.0 rev. 090630, which will be saved in 
the root folder with the following name:
Web.config.Sitecore_6.1.0_rev.090630

We have a sample PowerShell script that can be used to rename the config files available at https://gist.github.com/seankearney/6282452

During deployment, TDS Classic may find items in Sitecore that are not in the project. If TDS Classic determines that those nodes do not belong in the Sitecore database (See Child Item Synchronization), TDS Classic will use the Recursive Deploy Action to resolve the issue. There are 3 possible options:

1.Ignore Sitecore Items not in the Project: This is the default when a project is created. When this is selected, TDS does nothing to the unknown items.

2.Delete Sitecore Items not in the Project: TDS Classic will delete nodes under an items marked for child synchronization (See Child Item Synchronization). They are permanently removed from the database.

3.Move Sitecore Items not in the Project to the Sitecore Recycle Bin: TDS Classic will move nodes under an items marked for child synchronization to the recycle bin (See Child Item Synchronization).