TDS Support

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.