Build solution

Start ReSharper Build

By default, ReSharper Build is disabled. To enable it, do one of the following:

• Go to the Tools | Build | General page of ReSharper options (Alt+R, O) and choose Use ReSharper Build in the Build section.

• Open the Build & Run window ( ReSharper | Windows | Build Run), click Settings and choose Use ReSharper Build.

tip

The enabled/disabled state of ReSharper Build is saved in the layered settings, so you can use it on a per-solution basis.

When ReSharper Build is enabled, there are several ways to build your solution:

• Use any of Visual Studio build commands — for example Build | Build Solution Ctrl+Shift+B — all these commands and shortcuts are overridden by ReSharper Build.

• Click Build or choose other build command available in its drop-down menu on the toolbar of the Build & Run window.

• To build, rebuild or clean a specific project, right-click it in the Build & Run window and choose the corresponding command in the context menu.

ReSharper also provides its own implementation of NuGet restorer, which works with all Visual Studio versions. By default, ReSharper makes sure that all related NuGet packages are restored before each build, but you can disable it by clearing the corresponding checkbox on the Tools | Build | General page of ReSharper options (Alt+R, O). If the automatic restore is disabled, you can always run it manually by clicking Restore NuGet packages on the toolbar of Build & Run window.

NuGet restorer writes log to output if that is enabled on this options page. You can also configure log message level and view log information for restores on the Tools | NuGet Restorer page of ReSharper options (Alt+R, O).

Build process

When you run ReSharper Build for the first time, it builds all projects using multiple parallel processes according to your configuration. All build management happens out of process, so Visual Studio remains responsive while a build is running.

The next time you build the solution, ReSharper only builds projects where supported build items were changed. If the change affects public types used in other projects, the dependent projects are rebuilt as well.

The projects that are not affected by changes are skipped completely, including all additional build logic. If you want to execute pre-build and post-build events and/or BeforeBuild and AfterBuild MSBuild targets for skipped projects, use the corresponding checkboxes on the Tools | Build | General page of ReSharper options (Alt+R, O).

ReSharper Build maintains a dependency graph of inputs and outputs to MSBuild tasks, targets and projects, and efficiently monitors the file system for changes. When you start a build, ReSharper Build already knows if the timestamps are up to date, without having to invoke MSBuild: if a timestamp is up to date, the project is skipped.

By default, ReSharper Build uses the same MSBuild version as specified in Visual Studio settings and runs in 6 processes in parallel. If necessary, you can specify MSBuild version explicitly and change the number of processes on the Tools | Build | General page of ReSharper options (Alt+R, O).

Build process and summary are visualized in the Build & Run window:

All projects of your solution are visualized in a grid, each of them having specific color. You can also hover the mouse over a project to display a tooltip explaining the state. Colors represent project build states:

• Dark grey — the project is cleaned or never built.

• Grey — the project is not built for one of the two reasons: it is excluded from the solution build, or you only run build for specific projects and unrelated projects are not built.

• Light Blue — the project was built in the previous run and does not have any changes.

• Blue — the project was built in the previous run and does not have any changes; projects that it references only have private changes.

• Green — the project was changed or one of the dependent projects had public changes, then it was rebuilt successfully without warnings.

• Yellow — the project was changed or one of the dependent projects had public changes, then it was rebuilt successfully with warnings.

• Red — the project was changed or one of the dependent projects had public changes, then the project build failed.

If you need to cancel the current build, choose ReSharper | Build | Cancel Build from the main menu.

Analyze build results

Once a build completes, ReSharper displays build errors (and optionally, warnings) in the Build Results window.

By default, results only appear if there are build errors. If necessary, you can use the Show build results... selector on the Tools | Build | General page of ReSharper options (Alt+R, O) to display results with warnings, show results always or never.

In the Build Results window, you can further study build output in one of the following ways:

• Choose a convenient way to group the results using one of multiple options in the Group by selector.

• If there are build errors, only these errors appear in the window. If you also want to see compilation warnings, click Show Warnings on the toolbar.

• Use the Previous /Next buttons or Shift+F8/F8 shortcuts to navigate between build messages.

• To preview code that originated an error or warning, click Show Preview or press Ctrl+P. In the preview pane, which can be located either on the left or at the bottom of the window, errors and warning are highlighted either with red or with a blue squiggle.

• Double-click any error or warning to navigate to the corresponding code line in the editor.

Configure ReSharper Build

You can configure ReSharper Build on ReSharper options pages under ReSharper | Options | Tools | Build.

You can disable ReSharper solution builder by clearing the ReSharper Build checkbox on the Environment | Products & Features page of ReSharper options (Alt+R, O).

tip

Your build configuration preferences are saved using the mechanism of layer-based settings. Among other things, this mechanism allows you to maintain different preferences for different solutions as well as to keep these preferences under a VCS and automatically share them with your team members.

Supported build items

When evaluating changes in a previously built project to decide whether to rebuild it, ReSharper checks build items of the most common MSBuild items types:

"ApplicationDefinition",
"Page",
"Compile",
"Content",
"EmbeddedResource",
"Resource",
"SplashScreen",
"XamlAppDef",
"EntityDeploy",
"DesignDataWithDesignTimeCreatableTypes",
"DesignData"

Changes in build items of the type None and other types not listed above are ignored by default. If your project build relies on other custom build item types, names of these types should be registered with AvailableItemName in the .csproj/.vbproj file, e.g:

<ItemGroup>
    <AvailableItemName Include="CustomBuildItemType"/>
    <CustomBuildItemType Include="SomeFileToProcess.abcd"/>
</ItemGroup>

Supported project types and limitations of ReSharper Build

ReSharper Build supports most .NET project types and languages that are MSBuild-based (C#, VB.NET, F#, C++), including .NET Core projects. However, there are following limitations:

• Non-MSBuild projects. ReSharper Build cannot work with project types that are not MSBuild-based. This includes Web Sites (folder based projects, not MVC web applications), WinJS applications and DNX applications. If there are projects of these types in your solution, the whole solution build will fall back to the standard MSBuild build process.

• Custom build steps. Typically, custom build steps (including pre- and post-build steps in C++ projects) are the equivalent of calling a batch file, with several command lines being executed to, for example, copy files to the output directory. These are a black box as far as ReSharper Build is concerned — it does not know what is happening in the custom build step, so can’t track the input and output. Furthermore, if the project is skipped, the build step does not run, which could cause issues with the build (this is the main reason ReSharper Build is disabled by default).

  However, custom MSBuild targets and tasks WILL work with ReSharper Build, as long as the custom target and task supports incremental building, with a list of inputs and outputs that can be monitored for timestamp changes. Converting a naive custom build step to custom targets is highly recommended in order to get good results with ReSharper Build.

  If a custom build step cannot be replaced, the project can be added to the list of projects that should be 'always built', without having heuristics applied, meaning they are always passed to MSBuild, and MSBuild’s standard incremental build process will run. This can be configured on the Tools | Build | Heuristics page of ReSharper options (Alt+R, O).