To build the current solution, press Ctrl+Shift+B. Alternatively, a build, rebuild, or clean can be started from the Build menu.
When running a build, the MSBuild or XBuild output is shown in the Build tool window (Alt+0). Once complete, the window displays errors and warnings.
By default, Rider optimizes build process with ReSharper Build, which tracks changes in your solution and only rebuilds modified projects and necessary dependencies.
If your solution includes non-MSBuild projects or projects with custom build steps, you need to disable ReSharper Build on the page of Rider settings (Ctrl+Alt+S) — in this case, Rider will delegate the entire solution build to MSBuild.exe.
How ReSharper Build works
When you run ReSharper Build for the first time, it builds all projects using multiple parallel processes according to your build configurations.
The next time you build the solution, Rider only builds projects that were changed. If the change affects public types used in other projects, the dependent projects are rebuilt as well.
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 latest installed MSBuild version and runs in 6 processes in parallel. If necessary, you can specify MSBuild version explicitly and change the number of processes on the page of Rider settings (Ctrl+Alt+S).
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 e.g. 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.
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.