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.

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.

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.

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.

This is something we strongly discourage as it isn't what TDS Classic was meant for. TDS Classic is intended for handling developer controlled items, not content. Sitecore is designed to manage the content including revision history. With that said, content is like any other item, and therefore can be brought into your SC system using the sync with Sitecore functionality.

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

You need to specify the path to the required dll's from the property page of your TDS Classic project.

Right click on your TDS Classic project and click on 'Properties.' From there, go to the "Update Package" tab. There is a text box with the label "Sitecore Assembly Path." That textbox should have a relative path to the directory containing the dll's.

To check your version number go to the Help menu, click About Microsoft Visual Studio. All your installed products are listed in alphabetical order. Find TDS Classic and the version number is to the right.

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.

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.

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 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?

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.

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.

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).

TDS Classic and Sitecore Rocks work seamlessly together. We've teamed up with the Rocks developers to ensure that your development experience between TDS Classic and Rocks is as fluid as possible. The products compliment each other and if utilized in combination can give you great power and flexibility to your Sitecore development structure.

TDS Classic is compatible with Web Forms for Marketers (WFFM). Once the WFFM package is installed on a Sitecore instance, TDS Classic can manage the assets WFFM creates. These assets are simply Sitecore items stored in a specific folder. We have used TDS Classic and WFFM on a number of projects successfully. The key to making it work is to locate the folder WFFM uses and only add the assets WFFM created for you.

No. Duplicate item names are not currently supported by TDS Classic. There are two main reason for this.

1.The basic differences between a file system and the way Sitecore stores items
2.We can’t find a good reason to ever have items at the same level with the same name Sitecore stores items based on a GUID.

Every item has a unique ID, and therefore the name is irrelevant to Sitecore. The Windows file system on the other hand stores items on the name, and therefore cannot support having two items with the same name in the same folder.

There are a couple of cases where we hear requests for duplicate item support with the majority being that the developer wants to store 'Divider' items from the 'Core' database. For these instances we recommend that the dividers in the core database are renamed. The name of the ‘Divider’ item is irrelevant and if you rename them to Divider-1, Divider-2, etc… it will work as expected and TDS Classic will not complain.

For more information on this please see this blog post by Sean Kearney.

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.

No. This allows developers to create update packages for specific environments, where different items are included in each package.

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

See our Getting Started document on how to do this.

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.

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.

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.

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.

If you are running 32 bit you can run the TDSLicenseInstaller.exe located here:

C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2010)

If you are running 64 bit you need to uninstall TDS Classic, and then reinstall. This WILL NOT DELETE your TDS Classic project.

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.

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.

This means that your Sitecore License is expired or missing.

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

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.

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

If you are seeing this exception:
Exception Cannot generate package: '_', hexadecimal value 0x03, is an invalid character.(System.Exception):

at Sitecore.Update.Engine.PackageGenerator.GeneratePackage(DiffInfo diff, String licenseFile, String outputPath) at HedgehogDevelopment.SitecoreProject.PackageBuilder.PackageBuilder.BuildPackage(BuildContext ctx)
at HedgehogDevelopment.SitecoreProject.PackageBuilder.Program.Main(String[] args)

It typically is caused by bad character values in one of the .item files. Since this error is thrown by Sitecore, we have no way to trap/handle it better. Please review your items for special characters. This usually happens when someone pastes a text field from a program like word. If you have a good file search tool, you may want to try searching all the .item files for the special character 0x03. Once you find it, you will need to figure out how to remove it from the content and re-sync the content.

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.

The first thing you should do is change the logging options on the build to increase the amount of information in the log. To do this, go to the Tools->Options menu. Select Projects and Solutions/Build and Run. There is a dropdown for “MSBuild project output verbosity” Please set this to “Normal” it is most likely set to “Minimal”.

Do your build and open the “Output Window” Select “Build” in the Show Output From: dropdown. This should have your build output. You should review the output and look for any error messages. If nothing jumps out at you, set the verbosity to "Diagnostic" and try the build again. A word of caution, with the verbosity set to Diagnostic you will get a LOT of information, and it may be tough to wade through it all. This is why we recommend you start by setting the verbosity to "Normal".

The next thing to do is to check the Project dependencies.
 1. Right click on your solution and go to "Project Dependencies"
 2. Choose your TDS Classic Project from the drop down

Does the TDS Classic project have a dependency on your web application project?

If not...
 1. Go to properties of the TDS Classic project
 2. Go to the General tab

Is the "Source Web project" dropdown populated with the web application project?

If so, choose "<none>" and save. Then re-select your web application project and save.

Recheck the project dependencies dialog.

You should also check the Deployment Properties of the Sitecore items. You should set them as “Deploy Once”. Please see Deployment Properties and how they impact deploying items. You can right click on an item in the TDS Classic solution and choose “Deployment Property Manager…” to view/manage these properties all at once instead of working through the property window.

If none of these solutions work, please send us the build output (after changing the verbosity), as well as a copy of the SCPROJ file.

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. TDS Classic provides full support for the renaming, deleting and adding of items in your Sitecore project.

There are some limitations when syncing items where the items has been moved and/or renamed. A sync point must be chosen that contains the original position of the item and the new position of the item as subfolders. e.g. given the following folder structure:
          ParentFolder
                 ◦Folder 1
                       ◾ItemToBeMoved
                 ◦Folder 2

If ItemToBeMoved was moved to Folder 2, you must choose to sync from ParentFolder. If you choose to sync from either Folder 1 or Folder 2 TDS Classic will think the item has been either added or deleted (Depending on the folder you choose), and will not treat the operation as a rename.

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.

TDS Classic has been fully tested with the following:

Visual Studio: 2008, 2010 and 2012, 2017 (requires TDS 5.6 or higher).

Source Code Control Systems: Team Foundation Server, Subversion, and Git, but will also work with any Microsoft compliant source control system.

Sitecore: Version 6.0.1 and higher. The Update package feature in TDS 2.0 requires Sitecore 6.1 or higher.

Sitecore and Visual Studio communicate with each other via the Sitecore Connector. See the question: What is the Hedgehog Development Sitecore Connector (HDSC)? above for more details on the Sitecore Connector.

Using Sitecore 6.5 and see this exception while trying to generate an update package?

Exception Could not load file or assembly 'Sitecore.Update, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The given key was not present in the dictionary. (Exception from HRESULT: 0x80131577)(System.IO.FileLoadException):
          at HedgehogDevelopment.SitecoreProject.PackageBuilder.PackageBuilder.BuildPackage(BuildContext ctx)
          at HedgehogDevelopment.SitecoreProject.PackageBuilder.Program.Main(String[] args)

This is a bug with Sitecore's Sitecore.Update.dll. They have a hotfix available here: 

http://dl.sitecore.net/hotfix/Sitecore CMS 6.5.0 rev. 110602 Hotfix 348444-1.zip

Yes, TDS Classic does work with Git, TDS Classic will work with any Source Control you attach to Visual Studio. However, there is an issue with the line endings when bringing items into Git. The Unix-style line endings add an extra character. To avoid this error please configure your .gitattributes file with these lines:

# Custom for TDS/Sitecore serialization
*.item -text

For more information please see Sean Kearney's post on using TDS with Git or GitHub.

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.

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.

There is a bug with Visual Studio. Please see here for more information and fix. http://connect.microsoft.com/VisualStudio/feedback/details/544183/web-config-transform-writes-extra-line-break-spaces-to-values-elements-under-applicationsettings-section

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

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.

YES!!   To keep TDS Classic relevant and up to date we released a fix to version 5.6 which fully supports Visual Studio 17.    Please keep in mind that we do not back fix prior versions of TDS Classic so in order to be compatible with Visual Studio 17 you must be using the latest release of TDS Classic.  Click here to download the latest version. 

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.

TDS Classic gives you the ability to keep track of all the Sitecore items in your project, and see who changed what in a Source Code Management System. By maximizing all the features and functionality of your Source Code Management System with TDS Classic, you will streamline and improve the overall performance of your team. Having everything in a Source Code Management System gives you one master repository for the project and one, central integration point of all the code and Sitecore items for a team. Even if you are a team of one, using a Source Code Control system is the smart way to work, and provides many benefits, including:

• Complete accountability and an audit trail for all changes to all Sitecore items and .NET code in a project.
• Easier, secure backups thanks to single repository storage for all of your Sitecore items and code.
• Ability to work remotely or disconnected from the network and then sync and merge changes at a later date to the source code control system.
• Easily compare versions of items and code.
• Rollback to prior versions if there is a problem.
• Merge changes with ease.
• Leverage branching and other advanced source code management techniques.
              
               

TDS Classic helps new developers on a team get up to speed quickly by creating a new, clean Sitecore environment, getting the most out of the Source Code Management System and then deploying items and code to Sitecore. You also have to ability to easily see what other team members have been doing by reviewing the check-in comments.

Without TDS Classic each developer is dependent on coordinating and then packaging up changes with the entire team. We have even seen partners go so far as design their projects so that developers each work on separate areas of a project to reduce possibilities for collision.

This is not the optimal way to work.

TDS Classic has changed the way Sitecore projects are developed, and now, with the introduction of TDS Classic 5.6  it’s continues to be the standard Best Practices methodology for Sitecore development.

The Microsoft Build Engine (MSBuild) is the build platform for Microsoft and Visual Studio. MSBuild is completely transparent with regards to how it processes and builds software, enabling developers to orchestrate and build products in build lab environments where Visual Studio is not installed.

MSBuild allows you to deploy your code to other environments automatically. In conjunction with TDS Classic's custom-build targets, you can also create build scripts that deploy both your code and Sitecore items automatically.

We have a list of MSBuild references here.

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).

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.

These values are the actual items in your Sitecore project. Each of the values in SitecoreItem describe the items in the project. They map back to properties in the items property page.

SitecoreItem.ChildItemSynchronization is the same as the property of the same name
SitecoreItem.Identity is the relative path to the item file
SitecoreItem.ItemDeployment is the same as the property of the same name
SitecoreItem.ExcludeItemFrom is the same as the property of the same name

These values are the actual items in your Sitecore project. Each of the values in SitecoreItem describe the items in the project. They map back to properties in the items property page.

SitecoreItem.ItemDeployment is the same as the property of the same name SitecoreItem.ChildItemSynchronization is the same as the property of the same name

SitecoreItem.Identity is the relative path to the item file

SitecoreItem.ExcludeItemFrom is the same as the property of the same name

These values are the actual items in your Sitecore project. Each of the values in SitecoreItem describe the items in the project. They map back to properties in the items property page.

SitecoreItem.ExcludeItemFrom is the same as the property of the same name

SitecoreItem.ItemDeployment is the same as the property of the same name SitecoreItem.ChildItemSynchronization is the same as the property of the same name
  
SitecoreItem.Identity is the relative path to the item file

These values are the actual items in your Sitecore project. Each of the values in SitecoreItem describe the items in the project. They map back to properties in the items property page.

SitecoreItem.Identity is the relative path to the item file

SitecoreItem.ChildItemSynchronization is the same as the property of the same name SitecoreItem.ItemDeployment is the same as the property of the same name

SitecoreItem.ExcludeItemFrom is the same as the property of the same name

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.