This documentation is archived and is not being maintained.

Import Element (MSBuild)

Imports the contents of one project file into another project file.

<Import Project="ProjectPath"
    Condition="'String A'=='String B'" />

The following sections describe attributes, child elements, and parent elements.





Required attribute.

The path of the project file to import.


Optional attribute.

Condition to be evaluated. For more information, see MSBuild Conditions.

Child Elements


Parent Elements




Required root element of an MSBuild project file.

The Import element lets you reuse the code that is common to many project files. When you move common blocks of code into other project files, it lets you maintain code and propagate changes in a central location. For example, Project A and Project B set the specific item and property values for their builds and Project C contains the common build processes. Project A and Project B can import Project C, and any changes to the build processes are only made to one file.

Common imported project files are saved as .targets files by convention, but are standard MSBuild project files. MSBuild does not prevent you from importing a project with a different file extension, but the .targets file extension is recommended for consistency.

All relative paths in imported projects are interpreted relative to the directory of the imported project. Therefore, if a project file is imported into several project files in different locations, the relative paths in the imported project file will be interpreted differently for each imported project.

All MSBuild reserved properties that relate to the project file, for example, MSBuildProjectDirectory and MSBuildProjectFile, that are referenced in an imported project are assigned values based on the importing project file.

If the imported project does not have a DefaultTargets attribute, imported projects are inspected in the order that they are imported, and the value of the first discovered DefaultTargets attribute is used. For example, if ProjectA imports ProjectB and ProjectC (in that order), and ProjectB imports ProjectD, MSBuild first looks for DefaultTargets specified on ProjectA, then ProjectB, then ProjectD, and finally ProjectC.

The schema of an imported project is identical to that of a standard project. It is possible that MSBuild can build an imported project but it will probably fail because the imported project does not usually contain information about which properties to set or the order in which to run targets. The imported project depends on the project into which it is imported to provide that information.


While conditional import statements work in command-line MSBuilds, they do not work with MSBuild hosted in the Visual Studio integrated development environment (IDE). Conditional imports are evaluated using the initial configuration and platform default values set when the project is loaded. If changes are subsequently made that require a reevaluation of the conditionals in the project file, such as changing the platform, Visual Studio reevaluates the conditions on properties and items, but not imports. Because the import conditional is not reevaluated, the import is skipped.

To work around this, place conditional imports in the .targets files or place code in conditional blocks such as a Choose Element (MSBuild) block.

The following code example shows a project setting several items and properties and importing a general project file.

<Project DefaultTargets="Compile"



        <CSFile Include="*.cs" />

        <Reference Include="System" />
        <Reference Include="System.Data" />

    <Import Project="$(CommonLocation)\General.targets" />