dotCover allows you to build your solution incrementally using multiple parallel processes. You can use ReSharper Build as a replacement to native Visual Studio's build management.
Note that dotCover does not replace MSBuild - your projects are still built normally. The difference is that projects that do not need updating are not rebuilt.
In this topic:
- Starting ReSharper Build
- Build process
- Analyzing build results
- Configuring ReSharper Build
- Supported project types and limitations
Starting ReSharper Build
By default, ReSharper Build is disabled. To enable it, do one of the following:
- Go to the page of dotCover options and choose ReSharper Build in the Build Engine section.
- Open the Build & Run window () and then click Enable ReSharper Build.
When ReSharper Build is enabled, there are several ways to build your solution:
- Use any of Visual Studio build commands - e.g. (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 ReSharper Build & Run window.
- To build, rebuild or clean a specific project, right-click on it in the Build & Run window and choose the corresponding command in the context menu.
dotCover also provides its own implementation of NuGet restorer, which works with all Visual Studio versions. By default, dotCover makes sure that all related NuGet packages are restored before each build, but you can disable it by clearing the corresponding check-box on the page of dotCover options. 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 it is enabled on this options page. You can also configure log message level and view log information for restores on the page of dotCover options.
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, dotCover 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 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 page of dotCover options.
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.
Analyzing build results
Once a build completes, dotCover 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 page of dotCover options to display results with warnings, show results always or never.
- 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 warnigs, 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 on 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.
Configuring ReSharper Build
Excluding items from build
If you do not need to build some projects when you build your solution, you can exclude them to reduce build time. To do so, go to the page of dotCover options and mark projects or solution folders that you want to exclude in the Projects that should never be built section. You can use the search box in this section to filter the solution tree to show only matching items.
Excluding a project means it won’t get rebuilt, even if source files are out of date or a referenced project has public API changes. This is quite drastic, and can lead to uncaught compilation errors, but can be useful to temporarily exclude a project that is slow to compile, and not used in your current development task. It’s similar to unloading a project in Visual Studio so that it doesn’t compile, but the source files are still available to ReSharper to allow for navigation and refactoring. We recommend reenabling and rebuilding before committing to source control, or using solution-wide analysis to show compile errors as you type.
Forcing specific projects to build
ReSharper Build does not build projects if they were built successfully before, and have not had any changes since them. If you need to build some projects independently of changes in them, you can force build them. To do so, mark projects or solution folders that you want to force build in the Projects tha should always be built section. You can use the search box in this section to filter the solution tree to show only matching items.
Marking a project as 'always build' tells ReSharper Build to never apply heuristics to this project, but to always pass it to MSBuild. This does not mean that the project will always be rebuilt and recompiled, but it means MSBuild is always called - MSBuild will still check timestamps and might perform an incremental build. This is useful for projects that have custom build steps that ReSharper Build can’t track (although it would be better to rewrite the custom build steps as proper MSBuild targets that support incremental build.).
By default, when you start ReSharper build, the Build & Run window is brought up and build progress is also shown in the Visual Studio status bar. If necessary, you can configure this behavior on the page of dotCover options.
Supported project types and limitations
ReSharper Build supports most .NET project types available in Visual Studio, including CLR-based projects in different languages (C++, F#, etc.). 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 Visual Studio 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. 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 page of dotCover options.