---
title: Using continuous integration with Visual Studio
related:
  - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md
  - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/continuous-integration-repository-structure.md
  - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

This page contains best practices and tips for developing projects in Visual Studio in combination with a _Team Foundation Version Control_ or _Git_ source control repository and the Xperience [continuous integration](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md) solution. Many of the recommendations also apply generally when using continuous integration with any type of source control system.

For detailed instructions and additional information, please refer to the following resources:

- [Use Team Foundation Version Control](https://www.visualstudio.com/en-us/docs/tfvc/overview)
- [Use Visual Studio with Git](https://msdn.microsoft.com/en-us/library/hh850437\(v=vs.120\).aspx)

## Setting up workspaces

When using a _Team Foundation Version Control_ repository, developers need to set up their Xperience project and _CIRepository_ folder within a **Local** workspace. Server workspaces are not supported.

See the [Decide between using a local or a server workspace](https://www.visualstudio.com/en-us/docs/tfvc/decide-between-using-local-server-workspace) article for more information about the workspace location types.

> **Note:** **Note**: The _App\_Data/CIRepository_ folder and its file content does not need to be included in the **CMSApp** Visual Studio project. However, the folder still must be mapped to your source control (we strongly recommend having the entire Xperience project folder mapped).

## Creating and deleting objects

When you add a new object or delete an existing one in Xperience, the system creates or removes the corresponding XML files. You may need to perform additional actions to correctly track such changes, depending on the type of your source control repository:

- **Team Foundation Version Control** – by default, changes that create new files or delete existing ones appear in the list of _Excluded changes_ in the _Visual Studio Team Explorer_. You need to view the detected _Add_ or _Delete_ operations and _Promote_ the changes before you can check them in to the source control.

  > **Info:** **Info**
  >
  > _Team Foundation Version Control_ by default excludes the _\*.class_ and _\*.user_ file extensions. These extensions appear as part of certain directory names in the _CIRepository_ [folder structure](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/continuous-integration-repository-structure.md), for example, _cms.user_ or _cms.class._ As a result, files contained in these directories will not show under _Pending_ nor _Detected Changes_ in the _Visual Studio Team Explorer_.
  >
  > To fix this issue, you need to [add a .tfignore](https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/add-files-server?view=vsts#customize-which-files-are-ignored-by-version-control) file with the **!\*.\*** rule to the root of the _CIRepository_ folder, which tells the version control system not to ignore any changes made under the specified location.
- **Git** – when viewing _Changes,_ files representing new objects appear in the _Untracked Files_ section (delete operations are tracked automatically). You need to _Add_ the files before you can _Commit_ and _Push_ them to a shared repository.

## Changing object identifiers

Identifiers are values that the continuous integration solution uses to determine the names and locations of files representing objects in the _CIRepository_ folder:

- In most cases, objects use their **code name** as the identifier.
- Object types that do not have a suitable code name use other values (a notable example are pages, which use their _alias path_ as the primary identifier).
- Identifiers may also include values of related objects, such as the code name of the parent object, the name of the related site, etc.

Avoid making changes to object identifiers if possible, particularly for objects that have a large number of child objects or affect the identity of other objects (such as sites). This also includes operations that change the identifier indirectly, for example moving a child object under a different parent.

When an object's identifier changes, the continuous integration solution _**deletes**_ the file representing the object in the file system and creates a new one based on the new identifier. This causes a _**loss of the file's version history**_ in the source control and makes it difficult to merge changes made to the same object by other developers.

## Checking in changes

When checking in (committing) changes to your source control, we strongly recommend including **all** detected file changes in the _CIRepository_ folder. It may not be obvious which files correspond to specific changes made in the Xperience administration interface. Certain objects are represented by multiple files and changes may also affect related objects or relationships between objects.

To learn more about how objects are represented in the _CIRepository_ folder, see the following pages:

- [Continuous integration repository structure](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/continuous-integration-repository-structure.md)
- [Object types supported by continuous integration](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md)

## Getting new versions of the repository content

Whenever you load a different version of any files in the _CIRepository_ folder from your source control, you need to:

1. Merge any files that conflict with your instance's local versions. See also: [Resolving object conflicts](#resolving-object-conflicts)
2. [Restore the objects into your database](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md).

The restore operation ensures that your instance's database is consistent with the file system repository. If you continue working on the instance without performing the restore operation, changes to local data may overwrite the new versions of the files that you loaded from the source control.

## Resolving object conflicts

You may encounter object conflicts when getting or checking in _CIRepository_ files. Conflicts happen if your local folder and the opposing folder contain a file with the same name, but different content. File names are based on unique identifiers of objects (in most cases the object's code name).

For more information about the identifiers of _CIRepository_ files, see the [Changing object identifiers](#changing-object-identifiers) section and [Continuous integration repository structure](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/continuous-integration-repository-structure.md) page.

**Planned conflicts** can occur if you need to create _**the same object**_ across your entire development environment. For example, multiple developers may create a web part category with the same name when starting development of custom web parts. Even if the objects have completely identical values for all configurable properties, a conflict will occur during synchronization, because the object's GUID (globally unique identifier) value is different for each developer.

The best solution is to have one developer create the object and check in the resulting XML files to the central source control. Other developers then load the XML files from the source control and [restore the object](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md) to their local database. This approach completely avoids object conflicts and file merging.

If you cannot avoid an object conflict and need to merge XML files, always use the GUID value that is already checked in to the source control and replace your local GUID. Do NOT push your local GUID values to the source control – this could cause conflicts for all other developers in your environment.

> **Note:** **Note**:
>
> - The XML elements and attributes used in the content of _CIRepository_ files are _**case sensitive**_. Make sure you preserve the letter case if you edit the XML content when merging files.
> - If you change an object's GUID during conflict resolution and then [restore the object](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md) to your database, you may need to manually fix broken references on your local development instance. For example, object and page fields that allow uploading of files store the GUID of the selected metafile or attachment object.

**Unplanned conflicts** occur if developers unintentionally create _**different objects**_ of the same type with matching identifiers (typically code names) and then synchronize through the source control. In such cases, you need to contact the developer who checked in the conflicting XML file and one of you must delete and recreate the object with a different identifier (or rename the identifier values). We strongly recommend changing the local object that is not checked in to the source control yet, which prevents potential conflicts for other developers.

## Undoing changes

We do not recommend using the Visual Studio **Undo** action for changes that create new files. Undoing changes may lead to inconsistencies between the state of the file system repository and the database. You can instead delete the given object in the Xperience interface, which also makes the corresponding changes in the file system.

If you undo a delete or modify operation and revert an XML file to its previous state, you then need to [restore the objects into the database](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md) to reverse the object changes in Xperience.