.NET Tools
Essential productivity kit for .NET and game developers
ReSharper Build webinar: recording and Q&A
The recording of our recent webinar with Matt Ellis, Speeding up MSBuild: Tips, Tricks and ReSharper Build, is now available:
In this webinar Matt talks about some of the ways that help achieve faster build times in Visual Studio, including ReSharper Build introduced in ReSharper 10. The following topics are covered:
- MSBuild refresher
- Tips for speeding up MSBuild
- Common sense tips
- The CopyLocal myth
- HintPath for references
- Checking for slow targets and tasks
- XAML & multi-pass compilation
- Incremental compilation
- ReSharper Build
Questions and Answers
There were some popular questions asked during the webinar, as well as those that we didn’t get the chance to answer on the day.
Q: How does ReSharper Build’s public API surface monitoring handle InternalsVisibleToAttribute?
A: ReSharper Build will only rebuild dependent projects if an assembly’s public API has changed. The InternalsVisibleToAttribute allows other assemblies to see internal types and type members as though they were public. Unfortunately, ReSharper Build doesn’t yet work with this scenario – the public API monitoring is currently only for public types and type members.
To work around this issue, you can mark the referencing projects as "always build" in the ReSharper Build options page – this disables ReSharper Build’s heuristics, and always calls MSBuild on the project, where it will rebuild, based on timestamps. The issue is RSRP-450733, if you wish to vote, track or add any further details.
Q: Can ReSharper Build be used in a Continuous Integration server or as a command line tool?
A: The current implementation is targeted at reducing the solution build time in a running instance of Visual Studio, specifically at improving the feedback cycle for edit/compile/test or edit/compile/debug. At this point we don’t have any plans to extend these scenarios to include continuous integration or other kinds of usage outside of Visual Studio.
Q: What are the impacts (if any) when using TFS with multiple developers some of which have ReSharper and some which do not?
A: None. ReSharper Build optimises the solution build for running instances of Visual Studio, by skipping projects that don’t need to be built. It doesn’t alter the project files or the solution file, or anything else that can affect other developers, or a continuous integration process.
Q: If you already have everything set up with your build using Visual Studio, does ReSharper reuse these settings? I want to make sure if I start using ReSharper the output of the build (structure, etc) will be the same.
A: ReSharper Build uses MSBuild to build the projects in your solution, just like Visual Studio does. Put simply, ReSharper Build replaces Visual Studio’s solution build management with its own, which means ReSharper Build gets to decide if MSBuild should be called for a project, or not. It does not alter the project build itself – when a project is built, the normal build process is followed.
Q: How do I force a complete rebuild when for example changing a method that is only used via reflection?
A: The "Rebuild" menu item will rebuild a selected project, or the whole solution. Also, the consuming project that is performing the reflection can be marked as "always build" in the ReSharper Build options. This disables ReSharper Build’s heuristics, and always calls MSBuild for a project.
Q: What kind of speedup do you experience with the ReSharper solution?
A: This is a tricky question to answer, because it very much depends on the scenario. If a public API is changed in a project referenced by everything else, then there isn’t much of a speedup – everything is rebuilt, and it takes as long as MSBuild normally would.
However, if the change is an internal implementation detail to the same root project, then only that project is built and the speedup is huge – seconds instead of minutes. Similarly, if a public API is changed, but the build is triggered for tests, then only the projects used by the tests are rebuilt, and this can also have a huge (positive) impact on the build time. The speedups vary, and the only way to really see how much of an improvement you’ll get is to try it with your own solutions! But it’s worth pointing out this feature was initially written to make things faster for the ReSharper solution, and the whole team uses it!
Subscribe to a monthly digest curated from the .NET Tools blog:
