TDS Classic Support

The Sitecore Access Guid on the server doesn't match the Guid in the project. What does this mean?
The Sitecore Access Guid is set at the bottom of the Build Property Page. The Guid is also in Sitecore in the /_DEV/web.config file. This value is updated by TDS Classic during the build. Please verify that TDS Classic is writing the correct value to that file.

Do you have two TDS Classic projects in your solution? If you do, then the values in each of the build property pages need to match.
I created an alias for an item, but when I sync the item the alias isn't brought into TDS Classic. Why?
Aliases in Sitecore are actually their own entities.

If you created an alias for an item Sitecore will, behind the scenes, create an item in /sitecore/system/Aliases. In order to bring your aliases into TDS Classic you will need to bring the items under /sitecore/system/Aliases.
We typically have 3 environments going for a given project: dev (individual developer machines), QA (hosted in our office and accessible by clients), and production. We have source control and a continuous integration server. When developers commit code, the continuous integration server builds the project and deploys to the QA site. In this scenario, a new developer would set up a clean Sitecore install on their machine and sync the instance with TDS Classic. This will give them a very basic site to work with. Is this the recommended way for developers to work? What if the developer needs to develop/test something that requires more items, like for example a complex content indexing algorithm that involves thousands of content items? We would like to keep only development essential items in source control, but still have the ability for new developers to pull down a full content tree. Is this a common practice?
The process you describe for setting up a new machine works well, and is how we work, and recommend that. However, you can also leverage the 'deploy' option of TDS Classic which will essentially do an automate sync; this is typically how I like to populate my environment the first time. Beyond the initial deployment I typically use the sync functionality since I like to be a little more 'hands on' with changes to my environment.

 In the case of needing sample content to test functionality this is up to you if you think it is needed by everyone. If the majority of developers will need these item then it makes sense to check them in for everyone to use. However, if a single developer needs them for some isolated development and testing, then they would simply keep the items in their local Sitecore environment and don't add them to the TDS Classic project. We have heard of clients maintaining a separate TDS Classic project for sample content and this may be appropriate here.
What is the Child Item Synchronization property on the Item property page?
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.
Do I need to do anything special to get Sitecore Rocks integration working?
TDS Classic and Rocks communicate through a special Rocks Plugin, called the TDS Classic Connector. Since Sitecore Rocks version 1.0.0.1, the TDS Classic Connector needs to be manually installed through Visual Studio.

Ensure that the latest versions of TDS Classic and Sitecore Rocks is installed.

Then, in Visual Studio, select Sitecore -> ‘Manage Plugins’ to bring up the Plugins dialog.

In the dialog select Online -> ‘Sitecore Rocks MyGet Gallery’.

Find the TDS Classic Connector from that list, and install it. Once installed, restart Visual Studio.
How do I use TDS Classic with automated build and/or continuous integration?
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.
We've noticed that when using TDS Classic to create update packages it syncs insertions but not deletions. Is this supported?
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.
I am getting this deployment timeout error: C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets (312): Timeout deploying items /sitecore/templates/common/folder. Deployment Aborting.
There are several possible reasons for this. We recommend that you do/check the following before contacting support:
1.Are there any customizations to Sitecore, such as pipeline steps or dataproviders? These are the usual suspects with deployment timeouts.
2.Take a look at the "publishing targets" in your target cms. Is there a publishing target defined that doesn't exist in your target?
3.Is the target database is trying to grow its data or log file? If the growth is set to 10%, which is the default and the data or log file is really large, the growth time could be really long. If the file is almost full, you may want to grow it manually.

If you have checked 1,2, and 3 above and are still seeing an issue you can try and change the default timeout in the config file.

The config file that controls the deployment timeout, is set to 2 minutes by default. The file is located in the msbuild folder, which is usually called “C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0” The config files is called “HedgehogDevelopment.SitecoreProject.Tasks.Dll.config”.

If you still feel the need to contact support, please have the following information ready:
1.Are there any exceptions or things of significance in the Sitecore log file in the /data/log folder and see if there are any errors in the log around the time you are trying to do the deployment?
2.Does the build deploy any items or is the 'folder' template the first thing it tries to deploy?
3.Are you able to use the sitecore desktop on the target instance without a problem?
I have created a second TDS Classic project to handle my CORE database. How should I set up the deployment settings?
For the second TDS Classic project you should do the following:

1.If you are using a .user file for the first project, then copy that to the second TDS Classic project's location.
2.The "Source Web Project" setting should be left blank. This will prevent building twice and allow you to leave the "Deploy" folder blank.
3.The settings in the configuration manager can be the same.
We need to use different web.configs - I know we can use file replacements to help; but I am not sure if the source should be a config somewhere on my machine and target be within my SVN sourced or in my destination deploy folder.
We have a sample project available that demonstrates how file replacements can be used.

You essentially set the source to a location on your file system. You then can set the target as needed. Typically you would set this to a location on the destination server via UNC path, or you can set it simply as '.\' and this will copy it to the "Build Output Path" and then ultimately end up at the "Sitecore Deploy Folder" (or update package).
I am getting "Endpoint not found when deploying". How do I get around this?
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.
Can I exclude items that are in TDS Classic when deploying, for example some test content that I have?
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.
If I exclude items for a configuration that creates an update package, will those items be in the update package created by that configuration?
No. This allows developers to create update packages for specific environments, where different items are included in each package.
I am getting this error message: Exception The maximum message size quota for incoming messages (16000000) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. (CommunicationException)
You are probably trying to bring large file size content into your source control system. This is something that we discourage. If you have to do it, you can modify the maxBufferSize values in this file:

(64 bit system)

C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore\HedgehogDevelopment.SitecoreProject.VSIP.dll.config

(32 bit system)

 C:\Program Files\Hedgehog Development\Team Development for Sitecore\HedgehogDevelopment.SitecoreProject.VSIP.dll.config
How does file path shortening work?
First, it is important to understand that the file path shortening feature is only available with TDS Classic 3.0 and above.

Second, for developers in places like Scandinavia, The Netherlands and Germany where file path names tend to be longer, it can be time-consuming and quite a hassle to come up with names that conform to the 260 character file path + filename limitation. With TDS 3.0, the original file path name chosen by a developer is captured and safely stored in the TDS project, and the developer can create a shortened name to be used when storing the item on a file system.

This is done by entering the new name into the file path property of an item on the property page (F4). This will allow you to change, for example, the name of “Home” to “H” on the local file system. This shortens all paths under “Home” by 3 characters. File path shortening allows you to choose abbreviations for items that retain some meaning to the developers looking at the tree.
How do I configure TDS Classic to connect to other Sitecore databases?
Beginning with version 2.1 of TDS Classic, you can create a separate TDS Classic project for each database you wish to connect to. Simply add a new TDS Classic project to your solution, right click on the project name, select properties, and then on the General tab specify the Sitecore database you wish to connect to. By default, the Master database is selected.

To configure the deployment settings for additional projects do the following:

1.If you are using a .user file for the 1st project, then copy that to the 2nd TDS Classic project's location.
2.The "Source Web Project" setting should be left blank. This will prevent building twice and allow you to leave the "Deploy" folder blank.
3.The settings in the configuration manager can be the same.
How do I include extra files in an update package?
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
How do I install an update package?
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.
I installed TDS Classic but do not see a TDS Classic Project type when I’m creating a new project.
By default TDS Classic wants to install the project templates (TDS Project.zip) in the My Documents folder on your c: drive.

C:\Documents and Settings\UserName\My Documents\Visual Studio 2008\Templates\ProjectTemplates

The My Documents folder redirection seems to be a challenge for Visual Studio. When the My Documents folder is moved, the Visual Studio paths do not get updated. Ben Hall a UK C# developer wrote an interesting blog post on this.

If you have installed it in a different direct, you should make sure that the Visual Studio User Project Template Location setting in Visual Studio is pointing to the desired location.

                          1.In Visual Studio go to Tools>>Options
                          2.Under the Projects and Solutions highlight the General settings
                          3.Locate the Visual Studio user project template location: verify that this path is correct. It should                                be
                                        •Path to directory\Visual Studio 2008\Templates\ProjectTemplates
                          4.Click okay when you are done and now you should see the TDS Project Template when you try to                              create a new project.

Also, please note that if you are running Visual Studio in Safe Mode, none of your add-ins will load.
I bought several TDS Classic licenses for each member of the team, and I am now adding a new build server? Do I need to purchase an additional license?
No. Your TDS Classic license allows you to install TDS Classic on unlimited build servers. You must purchase a TDS Classic license for each developer that is working on a project.
What does this exception mean:An exception occurred while updating the Sitecore item /sitecore/path. The maximum size of data has been exceeded. Current data size: 2,739,200 bytes. Limit according to license: -7,455,744 bytes. Emptying the Recycle bin might help.
This means that your Sitecore License is expired or missing.
I have configured my continuous integration server with my TDS Classic project, but items aren't being deployed. Why?
When you tell MSBuild to build your solution, or TDS Classic project, you need to pass a parameter with it.

Pass the following command line parameter to MSBuild:
IsDesktopBuild=false
How do I work with multiple TDS Classic projects in a single solution pointing at the same Sitecore server?
To accomplish this in the development environment, the Sitecore Web URL, Sitecore Deploy Folder and Sitecore Access GUID must be the same across all TDS Classic projects. Also, Install Sitecore Connector must be checked for all projects. All of these values can be set for each project in the Build property page.

If you change the value of the Sitecore Access GUID for any project, you must change all projects to match the new value. After the property pages are saved, you must right-click on a TDS Classic project in the solution explorer (It doesn’t matter which one) and choose Install Sitecore Connector. This will update the connector with the new GUID, which will allow all TDS Classic projects to communicate with Sitecore.

In the production environment, the Install Sitecore Connector can be left un-checked, since this environment is deploy only. When the deploy runs for each TDS Classic project a new GUID will be chosen for each deployment.
I have a project in my solution named Sitecore.Support.12345, but the dll's never get pushed to my website. Why?
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.
Can I create separate packages for my code and Sitecore items?
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.
What do I need to do to activate Configuration Transforms?
You don't need to do anything to activate Config Transforms, that's the best part! After you indicate which file you want transformed and you follow the transformation syntax, TDS Classic transforms the file for you. No need for any Custom MSBuild script or any kinds of custom settings.
Can I use TDS Classic to sync users and roles?
Included in TDS Classic 5.1 is the ability to Sync your Sitecore Roles into Visual Studio. Users are not currently supported with TDS Classic; however, we expect to add this feature in future releases.

To learn how easy Syncing Roles with TDS Classic is check out this short video.
What are File Replacements?
File replacements allow the deployment of environment specific files when the TDS Classic project is built. This is useful for files holding connection strings or application settings that may vary from environment to environment. The file replacement tab can push individual files or folders. The source location can be an absolute path or a path relative to the project selected as the web application project.

By allowing for file replacement during builds, TDS Classic allows environment specific configuration files to be placed under Source Code Control.
What is the Hedgehog Development Sitecore Connector (HDSC)?
The Hedgehog Development Sitecore Connector (HDSC) is a custom web service designed by Hedgehog Development to allow Team Development for Sitecore to directly manipulate Sitecore Items. The connector uses a GUID to prevent undesired access to the service. The connector operates in two modes; Development and Deploy Only.

In Development mode, the connector is installed permanently in the Sitecore installation. This is done by CHECKING the Install Sitecore Connector checkbox on the Build tab of the property page. This allows the developer to use the Sitecore connector to sync with the Sitecore database and to browse item templates at any time.

In Deploy Only mode, the connector is installed at the start of a deployment and removed when the deployment completes. This is done by NOT CHECKING the Install Sitecore Connector checkbox on the Build tab of the property page. This allows only a small window where the connector is available on the server. Additionally, a new random GUID is chosen at the start of every deployment.
Why isn’t TDS Classic able to get my items if they aren't in the final workflow state?
TDS Classic is bound by the limits of the Sitecore API. If you are running your site in "Live Mode," as Sitecore provides in the /App_Config/Include/LiveMode.config file, then when TDS fetches an item from the API it is honoring the workflow state and version of the item.

For TDS Classic to be able to get the item(s) that aren't in the final workflow state, you must disable workflow for the master database.

The Complete TDS Classic Manual
This manual is a complete set of documentation you can use while learning TDS Classic. If you find something new, different or needs changing add it through a pull request!
Hedgehog Tools Help
Our TDS Classic Help section is built in to the tool. This will help gives you a granular understanding of each function and feature within TDS Classic.
TDS Classic Cloud Build
A document describing how to build in the VSTS cloud with NuGet TDS Classic build package.
Team City and Octopus with TDS Classic
Integrating TDS Classic with Team City and Octopus.

Continuous Delivery: Kagool and TDS Classic
TDS Classic has allowed Kagool to automate the build of their Sitecore Update Packages as part of a continuous delivery process.
Sync, Deploy & Transfer: Norfolk County Council, TDS Classic and Razl
With TDS Classic, Norfolk County Council syncs all Sitecore development items to source control; they use Razl to transfer and compare Sitecore content items between environments.
Too Many Cooks Spoil the Broth
Whitepaper on the importance of Continuous Integration while working in a team environment.
Build Extensions
Our Whitepaper on how to extend Hedgehog Tools to fit within your environment. Have the most up to date and complete project on the block!