Hedgehog Development

Support is available Monday – Friday, 9am – 5pm EST. Because of the nature of technical support we find it best if you contact us via email at support@hhogdev.com

If you need support for Team Development for Sitecore (TDS), please include the version number, the version of Visual Studio you are using, and the Sitecore version you are using.

We continually update our FAQ's, so we encourage you to read through the other questions and answers we have provided on our FAQ page. The FAQs may quickly provide you may find the solution to your problem there and save you time.

We frequently make announcements about updates to Team Development for Sitecore on Twitter, so please consider following us.

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

Team Development for Sitecore (TDS) 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, 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 one1, 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 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 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 is already changing the way the Sitecore projects are developed, and now, with the introduction of TDS 3.0, it’s is well on its way to becoming the standard Best Practices methodology for Sitecore development.

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, and then reinstall. This WILL NOT DELETE your TDS project.

No. Your TDS license allows you to install TDS on unlimited build servers. You must purchase a TDS license for each developer that is working on a project.

Team Development for Sitecore has been fully tested with the following:

Visual Studio: 2008 and 2010

Source Code Control Systems: Team Foundation Server, and Subversion, 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.

TDS 3.0 and Sitecore Rocks work great together. The products are very complimentary to each other, and combined, they give you all the power and flexibility of Sitecore in the comfort and familiarity of Visual Studio 2010.

We have a video on our You Tube Channel that shows you how the two work together.

There are two things that control Rocks integration.

The first is the host name of the connection in Rocks and the Sitecore url of the currently active TDS project configuration. These two must match, or TDS will not know that changes Rocks makes should be tracked. The rocks host name is set in the Rocks Connection window, and it is shown as a sitecore server in the Sitecore Explorer window. For example in Rocks, the connection name is “test.sitecore.local” in the TDS build property page, the Sitecore Web Url should be “http://test.sitecore.local”. Once these match, TDS should see rocks changes.

The next thing that is important is the Child Sync setting. If the item in TDS has Child Item Synchronization set to None, then TDS will ignore any additions from Rocks. Items that are already in the project will be updated

By default TDS 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
1. 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.

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 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 project. We have heard of clients maintaining a separate TDS project for sample content and this may be appropriate here.

This is something we strongly discourage as it isn't what TDS was meant for. TDS 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.

See our Getting Started document on how to do this.

No. Duplicate item names are not currently supported by TDS. The reason for this lies in the basic difference in the way Sitecore stores items, and the way the Windows file system stores names. 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.

TDS 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 to be able to get the item(s) that aren't in the final workflow state, you must disable workflow for the master database.

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

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 is compatible with Web Forms for Marketers (WFFM). Once the WFFM package is installed on a Sitecore instance, TDS can manage the assets WFFM creates. These assets are simply Sitecore items stored in a specific folder. We have used TDS 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.

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.

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

A single TDS 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 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 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.

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

During deployment, TDS may find items in Sitecore that are not in the project. If TDS determines that those nodes do not belong in the Sitecore database (See Child Item Synchronization), TDS 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 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 will move nodes under an items marked for child synchronization to the recycle bin (See Child Item Synchronization).

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.

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.

TDS 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. 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 will deploy the current value of the field to the item when it deploys the site.

Yes. There are two ways of doing this.

First way:

1. In the TDS 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 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. 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

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. If CIS is set to “None”, the item is ignored. Otherwise it is deleted/recycled.

• 

Yes you can.

You can have the build split the update package TDS 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 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.

• 

With TDS 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 and MSBUILD to deploy your Sitecore items and .NET code automatically. Because TDS has some advanced features, such as deploying and packaging, we've created our own .targets file that ships with TDS. 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.

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.

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 

When you tell MSBuild to build your solution, or TDS project, you need to pass a parameter with it.

Pass the following command line parameter to MSBuild:
IsDesktopBuild=false

• 

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

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 Project from the drop down

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

If not...
1. Go to properties of the TDS 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 reselect 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 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.

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

Right click on your TDS 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.

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

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

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

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

This means that your Sitecore License is expired or missing.

First, it is important to understand that the file path shortening feature is only available with TDS 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.

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

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 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 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 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 project a new GUID will be chosen for each deployment.

For the second TDS 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 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.

File replacements allow the deployment of environment specific files when the TDS 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 allows environment specific configuration files to be placed under Source Code Control.

Beginning with version 2.1 of Team Development for Sitecore, you can create a separate TDS project for each database you wish to connect to. Simply add a new TDS 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 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.

• 

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 Team Development for Sitecore you will need to bring the items under /sitecore/system/Aliases.

Users and roles are not items in the tree, and therefore are not items in the Core database.

TDS is designed only to work with items, so it cannot be used to sync the users and/or roles.

We are looking into ways to integrate this into TDS, since we have run into this limitation ourselves on the consulting projects we work on.

Workaround: You could go into the user or roles manager, and then you could serialize the users/roles from there. Manually move them to the next Sitecore environment and then restore them.

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