Introducing ReSharper Build

ReSharper has always wanted to speed up your code editing, refactoring and navigation. ReSharper 10 now wants to speed up your build.

ReSharper Build is a new feature in ReSharper 10 that will reduce the time it takes to build your solution. It replaces Visual Studio’s build management with a system that applies heuristics to only build projects that need updating. Note that it doesn’t replace MSBuild — your projects are still built normally. They’re just not built as often.

In this post, we’re going to take a deep look at how ReSharper Build works, and how you can make use of it in your own solution.

The benefits of a faster build are obvious — we all want to speed up the development feedback cycle. No one wants to be interrupted when they’re in the flow, and a slow compile can be a real productivity killer. The quicker we can get a solution rebuilt, the sooner we can get feedback from our tests, and the sooner we can move on to new code, or fix up tests. And if this happens quickly enough, we stay in the zone, and remain productive.

Furthermore, ReSharper Build is also an important part of another new feature — Continuous Testing. This is a feature of dotCover and ReSharper Ultimate which intelligently runs only the subset of tests that cover the code that you’ve just changed. In order to be able to do this, we need to be able to build the changed code as quickly and efficiently as possible. We’ll take a closer look at Continuous Testing in a future blog post.

Some of you power users might recognize ReSharper Build’s heritage — it’s the latest evolution of a (somewhat) hidden/internal feature that we’ve been using on the development team for several years. When the uber-solution to everything that makes up ReSharper Ultimate is 600 projects, and the everyday solution for feature development can be as large as 300 projects, you need something to speed the build up!

How does ReSharper Build work?

Put simply, ReSharper Build manages the build process, and decides if each individual project needs to be built, or not. When building a solution, if a project doesn’t need to be rebuilt, it is intelligently skipped — what’s faster than doing nothing?

There are three main optimisations:

  1. All build management happens out of process. Visual Studio has been moving more of the build pipeline out of process in recent versions, but even in Visual Studio 2015, the core build management is still hosted in-process. ReSharper Build is hosted out of process, meaning that Visual Studio remains snappy and responsive while a build is running.
  2. Efficient timestamp monitoring. MSBuild supports building incrementally, by comparing the timestamps of inputs and outputs of a target — it they are up to date, the target isn’t run. But an MSBuild process must still be run so that it can check the inputs of outputs of each target and check all of the timestamps — this gives us an overhead to do nothing!

    ReSharper Build maintains a dependency graph of inputs and outputs to tasks, targets and projects, and efficiently monitors the file system for changes. If a build is requested, ReSharper Build already knows if the timestamps are up to date, without having to invoke MSBuild. If it’s up to date, don’t build it.

    This optimisation alone can greatly improve the time your solution takes to build — but we can go one better.
  3. Public API surface monitoring. Traditionally, if a project is edited and rebuilt, Visual Studio and MSBuild will also rebuild all other projects that reference it. If we’re changing the public API of an assembly, then this is a good thing — referencing projects need to know if we change the name of a method, add parameters or remove an interface. But if we’re only changing the internal business logic of a class, we’re rebuilding the referencing projects unnecessarily — the generated code in the referenced assemblies won’t change.

    When a project is built, ReSharper will scan the just compiled output assembly. If its public API hasn’t changed, then ReSharper Build knows that it doesn’t need to build any of the referencing projects, and they are intelligently skipped. This has a huge impact on larger solutions. If a change is made to the business logic of a root assembly, then traditionally, that would require the rest of the solution to be rebuilt. ReSharper Build will only rebuild the root assembly, and skip the rest.

How do you use it?

It’s very easy. Once enabled, ReSharper Build replaces and overrides the standard Visual Studio build process, and is invoked whenever a build is required — building, rebuilding or cleaning the solution, running or debugging the project, or running unit tests. ReSharper Build is disabled by default, meaning you have to opt-in to the new build management (there are some edge cases that can cause issues, particularly custom build steps, so we’ve decided that you need to make an explicit step to opt-in. See below for more details).

You can enable ReSharper Build by first displaying the ReSharper Build & Run tool window, from ReSharper → Windows → Build & Run.

ReSharper Build tool window showing link to enable ReSharper Build

If ReSharper Build is not enabled, the tool window will show you that Visual Studio’s build process is being used, and provide a link to “Enable ReSharper Build”. You can also enable ReSharper Build and change the settings through ReSharper → Options → Build, and if you use the Save To button, you can enable/disable on a per-solution basis.

ReSharper Build and Run showing the projects colour coded for status

Once enabled, the ReSharper Build & Run tool window will show all of the projects in the solution, as coloured boxes. The colour of each box represents the state of the project, such as not requiring build, excluded from this build, skipped, built with errors, or successfully built. There are several more states available, and hovering the mouse over a project will display a tooltip explaining the state.

ReSharper Build and Run tool window showing tooltips for status

Once a build completes, any output from the build (errors, warnings, info and messages) are displayed in the ReSharper Build Results tool window, from which you can double click to navigate to the warnings and errors. We are still working on the UI during the EAP, so expect this window to change, as we will be adding support for keyboard shortcuts, and also grouping results.

Build results list tool window

Update for RTM: The Build Results tool window was removed from the final RTM release of ReSharper 10.0. We didn’t get the design and feature set finalised and working well enough to be included in this release. Instead, we have rolled back to the prototype implementation, which will automatically display build results as a tab in the Find Results window. While this location might seem a little surprising, ReSharper displays the window automatically, and whenever you double click one of the projects in the Build & Run tool window. Furthermore, the Find Results implementation offers more features, including grouping, filtering and keyboard shortcuts. The standard Visual Studio F8 and Shift+F8 shortcuts will navigate the errors, as will ReSharper’s standard previous/next shortcuts Ctrl+Alt+PageUp/PageDown (Ctrl+Alt+Up/Down for IntelliJ shortcut users). We will be re-evaluating how we display build results for a future release.

ReSharper Build overrides the standard Visual Studio build commands, meaning it gets invoked from the normal build keyboard shortcut, which will build the whole solution. Similarly, rebuild and clean keyboard shortcuts will build the whole solution.

When running tests, launching an application for debugging, or right clicking and selecting Build on the project’s context menu, ReSharper Build is invoked on a subset of the solution, and only processes those projects. Any other projects that need rebuilding are ignored, and marked in blue, showing they will be rebuilt in the future.

ReSharper Build tool window showing projects not built due to selection

Similarly, ReSharper Build is available under the ReSharper → Build menu option, which allows for building, cleaning and rebuilding the solution. It also offers menu items to just build, rebuild and clean the current selection. You can also cancel the current build, if it’s taking too long (although we don’t expect this to get used much).

ReSharper Build menu items

Update for RTM: The ReSharper → Build menu item has been removed – all options are already available on Visual Studio’s Build menu, with the exception of building a selection. This can be achieved from a project’s context menu, or automatically by ReSharper when building before running tests.

Configuring

ReSharper Build can be configured from ReSharper Options (ReSharper → Options → Build, or by clicking the “spanner” options icon in the ReSharper Build & Run tool window). You can set which version of MSBuild to use (Visual Studio’s, by default) and how many MSBuild processes to run for parallel build.

ReSharper Build options page

You can also configure which projects should never be built, and which projects should always be built. These two options can be very useful.

Excluding a project means it won’t get rebuilt, ever, 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!

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. See below).

Technical limitations

There are a couple of technical limitations that are due to ReSharper Build being based on MSBuild:

  • Non-MSBuild projects. ReSharper Build can’t 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. These projects will fall back to the standard Visual Studio build process, although the rest of the projects in the solution can continue to use ReSharper Build.
  • 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 doesn’t know what’s happening in the custom build step, so can’t track the input and output. Furthermore, if the project is skipped, the build step doesn’t 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 in the ReSharper → Options → ReSharper Build page.

Known issues

As well as continuing to work on the UI, there are still a couple of known issues. If you encounter any other issues, PLEASE let us know!

  • NuGet package restore is not currently supported. Right now, ReSharper Build does not trigger NuGet’s package restore functionality. To restore packages, go to the NuGet package UI, or temporarily switch to the Visual Studio build process using the “cog” icon in the ReSharper Build & Run tool window.

FAQ

  • Does this work with Copy Local? Yes.

    ReSharper Build also tracks copy tasks, and will replay them if timestamps have changed. So a project that is skipped will still get the latest version of any modified referenced assemblies in its output folder.

    For even faster build times, we recommend building to a single bin folder (and NOT disabling Copy Local). This results in far fewer files being duplicated and copied around, and as an added bonus, reduces the number of files being monitored by ReSharper Build for timestamp changes.
  • Does this work for changes in resource files? Yes.

    ReSharper Build monitors the timestamps of all inputs to targets, rather than changes to just source files. Any resource files (images, xml files, etc.) that are modified are flagged as timestamp changes, so the project is rebuilt.
  • Does this work with C++, F#, etc? Yes.

    ReSharper Build monitors the inputs and outputs of targets and tasks, and can apply the timestamp heuristic to these projects. It can apply the surface API heuristic to any CLR based project — ReSharper Build calculates the public API surface from the output assembly, rather than the source of the project, so can monitor any CLR based assembly for API changes. However, please remember that custom build steps are a black box that ReSharper Build cannot track. If your project has a custom build step, including C++ pre- and post-build steps, ReSharper Build cannot know when they should be run. You can either rewrite the custom build steps to use proper MSBuild targets and tasks, or exclude the project from heuristics in the options.

    Of course, if you encounter a project that doesn’t play nicely with ReSharper Build, please let us know.
  • Does this work with strong naming? Yes.

    When referencing an assembly, the version is embedded as part of the reference. When an assembly is strong named, the version numbers must match exactly, or assembly loading will fail. This means referencing assemblies need to be recompiled, even if the public API hasn’t changed.

    ReSharper Build considers the assembly version to be part of the public API. If the version changes, referencing assemblies are recompiled.

    The AssemblyVersionAttribute specifies the version of the assembly. If it’s set to a static value such as "1.0.0.0", the version doesn’t change with each compile, and ReSharper Build’s optimisations can be applied. However, if the assembly version is in the form "1.0.*", the version is updated on each compile, and ReSharper Build considers the public API to have changed, and the surface API heuristic no longer applies.

    The default C# project template sets the assembly version attribute value to be "1.0.0.0", which fits nicely with ReSharper Build’s optimisations. However, the managed C++ template sets the attribute value to "1.0.*", which will make ReSharper Build consider the public API as having changed. It is recommended to change the assembly version attribute to be a static value in order to get the most from ReSharper Build.
  • Does this require Solution Wide Analysis to be enabled? No.

    The public API build heuristic works on the compiled assembly, and doesn’t need to analyse source code at all. If you have excluded a project from building in the options page, Solution Wide Analysis can be very useful to capture compile errors that you wouldn’t otherwise see.
  • How does this work with Run Configurations? ReSharper 9.2 introduced Run Configurations, which are ways of defining targets to run and debug. These can be running an executable with different command line parameters, launching a project, or even debugging a static method.
    ReSharper Build tool window showing run configurations menu
    Naturally, ReSharper Build integrates nicely with Run Configurations, providing a drop-down of different configurations in the ReSharper Build & Run tool window. From here, you can select the default configuration that will happen when you run or debug, or define new ones.

And finally, a small tip to finish up — ReSharper Build monitors the public API surface of your assemblies. To reduce unnecessary builds, consider using “internal” instead of “public”. If a class, interface, method, etc. isn’t actually required to be public, making it internal reduces the API surface being monitored, and will reduce the number of unnecessary rebuilds.

Conclusion

We are very excited to launch a new feature such as this. We’re hoping it will have as much of a positive impact on your build times, as ReSharper has had on your development experience.

Please download the latest EAP and try it out with your projects, and PLEASE let us know if you encounter problems. This is why we run the Early Access Program — to get feedback on products before they’re finalised, to find issues before we release. Let us know if it’s working for you, and especially let us know if it doesn’t!

This entry was posted in How-To's and tagged , , . Bookmark the permalink.

79 Responses to Introducing ReSharper Build

  1. Mark says:

    D’oh! It was all sounding great till the bit about AssemblyVersion 1.0.* not being supported. We use that a lot as it makes it easy to ensure that our MSIs will always overwrite DLLs when upgrading a program.

    • Matt Ellis says:

      Unfortunately, assembly version is a part of the public API, and it can cause issues if we ignore it, especially with strong naming.

      Our suggestion is to use a static version number when developing, but specify a proper version at release build time. You can do this with something like TeamCity’s AssemblyInfo patcher build feature, which allows you to set the assembly version during CI builds, or something simple, like this:


      #ifdef DEBUG
      [assembly: AssemblyVersion("1.0.0.0")]
      #else
      [assembly: AssemblyVersion("1.0.*")]
      #endif

      This will use a static version during development, but calculate a version number when doing a release build.

      • Mark says:

        Thanks, neat idea with the debug flag, we could definitely use that! I realise the proper way would be something better on the build server, but for now it’s not something we could do.

    • Michael Geramb says:

      Hi mark,
      great feature! @”Unfortunately, assembly version is a part of the public API, and it can cause issues if we ignore it, especially with strong naming.”. Have your development team thought about batching depended assemblies on binary level instead of recompiling? It’s very simple, I have done this already, so if you are interested in a code snipped you can contact me. Kind regards, Michael

      • Matt Ellis says:

        Hi Michael. I’m not sure what you mean by batching. Could you explain a bit more, please?

        • Michael Geramb says:

          Hi Matt, sorry for the wrong spelling, should mean patching. It is possible to rewrite the referenced assemblies in a compiled assembly on binary level. So if an assembly which was recompiled becomes another version (e.g. be using AssemblyVersionAttribute(“1.0.*”)) and your great build tool knowns that a dependent assembly need no recompile, you can change in dependent assembly only the reference without recompiling. If the assembly is not signed, this works great, I don’t know if this works also for signed assemblies, but I assume you must to the patch before the assembly will be signed. If you are interested in a code snipped, write me an email.

  2. Carel Lotz says:

    How does this play along with other toolsets running in VS like Xamarin?

    • Matt Ellis says:

      It should work just fine, as long as the toolsets are using normal msbuild techniques that specify inputs and outputs, which allow us to track timestamps. Please let us know if you do encounter any issues – everybody’s builds are different, and we can’t necessarily test all combinations.

      Also, if you do encounter issues, you can mark those projects as “always build”, which means ReSharper Build doesn’t apply heuristics, and lets msbuild run the project as normal.

      • ian says:

        I just loaded the Xamarin starter Snake project and it refuses to build using Resharper build because “building from the command line requires a business license”.

        FYI.

  3. MichaelD! says:

    +1 to the AssemblyVersion * support.

    Otherwise, this sounds fantastic. MSBuild is a terrible technology and should be gutted from the inside out. Or really, in any manner possible. Looks like it has already begun to do just that. 😛

  4. Jan Kratochvil says:

    Will building UWP apps using .NET Native be supported?
    That’d be awesome as currently as the .NET Native build pipeline is currently not very performant.

    • Matt Ellis says:

      As long as the UWP build process is normal msbuild tasks and targets, then it will work. As I understand it, the .net native compilation only applies in Release mode, while Debug mode is normal .net compilation, so building in Debug mode should be faster than Release mode even without ReSharper Build.

  5. tobi says:

    Fantastic! I hope JetBrains will expand even further and cover even more of what developers do all day.

  6. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1948

  7. Looks great. Definitely a productivity booster.

  8. Markus says:

    Does ReSharper Build also work with VS2013? Or only with VS2015?

    • Matt Ellis says:

      We’re still testing full compatibility, but ReSharper Build works with all versions of Visual Studio that ReSharper itself supports, so that’s VS2010, VS2012, VS2013 and VS2015. Of course, if you encounter any issues with a particular version of Visual Studio, please let us know.

      • Markus says:

        I didn’t try it yet. I jst wanted to ask if it is generally possible.
        Nice to hear that also older VS versions support ReSharper Build. I will tray it as soon as ReSharper 10 is released…

  9. Pingback: Dew Drop – October 16, 2015 (#2113) | Morning Dew

  10. Jirka says:

    It would be fine to extend this example by providing concrete measure on Resharper solution itself. If i am right, it is about 200 projects, so there is space for measurements. Isn’t it?

  11. Richard Moss says:

    One thing I liked about the sadly defunct .NET Demon was that it automatically rebuilt each time I saved a file – I really miss this in VS2015 and even now I still forget regularly to manually build and wonder why my changes haven’t been applied.

    Is build-on-save something that this tool will offer?

    Thanks;
    Richard Moss

    • Matt Ellis says:

      Yes, although this is actually part of the Continuous Testing feature, as build on save only really makes sense if you use the compiled output for something. To enable this, go to ReSharper → Unit Tests → Show Continuous Testing Session, and change the Mode drop-down to one of the options – “On Save, Build and Run Dirty Tests” or “On Save, Build and Detect Dirty Tests”. We’ll look more at Continuous Testing in a forthcoming blog post.

      If you have any feedback on this, please let us know while the EAP is still in progress!

      • Richard Moss says:

        Thanks for the response.

        I don’t use Resharper’s unit testing functionality (in fact I disable it in the hopes of freeing some resources). For continuous testing I use NCrunch, so “Save and Build” works for me, “Save, Build and Do Something With Tests That I Don’t Care About” won’t. It could be that Resharper’s test stuff could supplant NCrunch in time, but it would have to be pretty exceptional to do that.

        I mainly use this feature for web applications – if I change server side code that needs compiling, I used to rely on .NET Demon recompiling the DLL, so all I had to do in the web browser was refresh the page. Now I have to remember to trigger a compile 😉

  12. Brian Sayatovic says:

    I’m excited and intrigued by the continuous build. I’ve installed EAP 5 to try it out, but the solution-wide build tells me many of my projects failed. When I look at the messages from it, there are no errors. And if I build the individual project, it succeeds. So I’m still intrigued, but now I’m also apprehensive.

  13. Vasily Kirichenko says:

    Is it possible to use only the build feature and turn off *all* other ReSharper features?

    • Matt Ellis says:

      Yes. Most features (such as code completion or inspections) can be disabled, or configured to use default Visual Studio functionality, so you can tune how ReSharper works for you.

      Furthermore, ReSharper allows a specific feature set or even a whole product to be disabled, in the ReSharper → Options → Products and Features options page. Feature sets can be something like navigation, unit testing or CSS support, while a product can be everything to do with dotTrace, or dotCover. ReSharper Build is a product, which means that while it shares common code with the rest of ReSharper, it can be enabled/disabled independently of the rest of the suite.

      So, yes, you can disable everything apart from ReSharper Build. Obviously, we’d like you to use some of the other features of the suite, too :). ReSharper is very configurable, and can usually be set up to fit most people’s coding styles and habits. If there’s anything you don’t like, or that doesn’t work for, please let us know!

  14. Pingback: F# Weekly #42, 2015 | Sergey Tihon's Blog

  15. Pingback: Les liens de la semaine – Édition #154 | French Coding

  16. Dave S says:

    Is this only for local builds? Or would it work for builds run through TFS?

    • Matt Ellis says:

      This is only for local builds. It’s an optimisation for msbuild to intelligently skip building when you don’t need to, by monitoring your environment between builds. It’s designed to make repeated local builds faster, rather than to speed up a CI system.

  17. Pingback: NYC’s subway needs system update, ‘Star Wars’ fans care about website performance, and JetBrains develops new tool—SD Times news digest: Oct. 19, 2015 - SD Times

  18. Ed Blackburn says:

    Have you guys spoken with the MSBuild team to pass in your learnings? I dislike MSBuild and am glad someone is tackling it head on. Now that MSBuild is open sourced perhaps MS will be ameanable to suggestions etc? That DNX doesn’t use it at all I hope means we can move on eventually and leave the xml fetish behind.

    • Matt Ellis says:

      This isn’t an msbuild issue. We’re replacing how Visual Studio orchestrates a build with a process that optimises based on extra information that ReSharper manages. There’s not much that can feed back into msbuild – nothing ReSharper Build does affects a command line build, for example.

  19. Is there a trial or evaluation version of this functionality? It sounds pretty useful and I’d be very interested in evaluating it. We use Resharper although we’re not on the latest version.

  20. Daniel says:

    Is this present in version 9.2 or only in the 10 EAP?

  21. Fellow says:

    The build process doesn’t feel a lot faster, maybe we’re running into some of the caveats you mentioned, so I’d like to investigate.

    Matt, can I see what MSBuilds are triggered? It looks like the output window stays empty.

    • Matt Ellis says:

      Not as such, there isn’t a log file or anything. However, you can use the ReSharper Build & Run tool window to see what projects are built or need building. The colours of each box shows what has happened, and what will happen. Hovering over a project’s box will show a tooltip that explains why it’s been rebuilt – due to a dependency that has a change in public API, for example.

      Hopefully, this will be enough to show you why a build was triggered, even if it doesn’t tell you exactly what has changed – that is, you know the public API has changed, but not what in the API has changed. If you need more details, could you log an issue, please? Details of what you’d like to see would be brilliant.

      Also remember that compilation isn’t sped up – compilation takes as long as it ever did. ReSharper Build simply tries to make it so that you don’t compile when you don’t need to. So if you make a change to the public API of a root project, then your whole solution will likely need to be rebuilt, and that will take as long as it ever did.

      • Fellow says:

        So as of EAP 7, I see the output, and from the colors too I can see that it identifies the changed project correctly. However it still takes much, much longer to run the build (12s from VS Build vs. 50s in R# build).
        I have since filed an issue..

  22. Cole Werner says:

    When using Resharper build I seem to be getting build errors related to projects that are not set to build under my active build configuration. Compilation seems to cease when this error is encountered in an erroneous project. Is this a known issue or am I doing something wrong here?

    • Matt Ellis says:

      ReSharper Build will stop after it encounters the first project with errors – this is because it knows it can’t build anything else, as this project is broken, so it stops.

      As for ReSharper building projects that should be excluded, do you mean they are set to “never build” in ReSharper Build’s options? Would you mind logging a YouTrack issue with more details? (and a repro is always an enormous help!)

  23. ian says:

    In the released version the menu has changed. It is still in Windows menu but called “Build and run”. It’s missing an icon, and I’m not a fan of the name as it sounds like an action (i.e. it will build and run if you select “build and run”).

    Finally, I’ve closed the build warnings/errors window and now I can’t find a way to reopen it.

    Good work though, I think it will be helpful.

  24. lochness says:

    Is it possible to get resharper to inform you of how long the build took so i can compare it to the normal visual studio build as well as incredibuild?

  25. Daniel says:

    What about starting the build after a file is saved? .NET Demon used to do that but Red Gate discontinued the product because some similar functionality is/would be included in VS 2015. But not everyone is switching to VS 2015.

    • Matt Ellis says:

      This is implemented by dotCover’s Continuous Testing feature. We’ll have a blog post on this soon, but in the meantime, you can enable Continuous Testing from the Unit Tests menu, and from the Continous Testing Session window, you can select to build on save, run tests on build, etc.

  26. Pingback: Resharper 10 MVC Problems - A Blog about Coding

  27. Jan-Pieter says:

    The build doesn’t work if an Azure Host project doesn’t have a default configuration. Error WAT200: No default service configuration “ServiceConfiguration.cscfg” could be found in the project.

    Sad, because this is how all projects are setup and a perfectly legitimate way. Not sure how Visual Studio handles it though.

  28. WHat happen if we are using PrivateObject in UnitTest or any other way like reflection, typically in UnitTest.
    What’s happening ?

  29. This is an amazing tool, finally I can carry on working whilst building. Currently you can’t build solutions with web projects though even if they’re not set to build. I have a large solution with one web project which i’d love to use with your tool, i never actually need to build the web project but do need it to remain part of the solution for ease of access to aspx files etc.

  30. Alex Sanseau says:

    Excellent new feature to ReSharper, I can’t wait to try it out.

    Good tip as well about making classes/interfaces internal instead of public (which we should do anyway if it’s not used outside the assembly, regardless of using ReSharper build), but does it support InternalsVisibleToAttribute attributes which are sometimes used to make internal methods visible to a test assembly for instance?

    Would ReSharper Build know a change to an internal method could affect the test assembly and that it would need rebuilding as well as a consequence?

  31. Jeff says:

    hi Matt,

    Is it possible to customize the layout of project boxes in ReSharper Build ?

    like, change font size, or re-grouping these project boxes by different rules ?

    Cheers,

  32. Jirka says:

    Added comment related to web site project types to the mentioned issue request https://youtrack.jetbrains.com/issue/RSRP-450339

  33. Nicolas says:

    Hello,

    Is it possible to call resharper build from command line (maybe with devenv.exe call or ReSharper Command Line Tools ?)

    Thanks

  34. Ralf says:

    How can we force build order?
    I have a solution with a wixlib project. The output has to be embedded into another projects output. WIth default VS build manager I can manually set the dependency and force the wixlib project to be build before the depending project. Build & Run ignores this and the build fails.

  35. Werner Hartinger says:

    Great feature, but I´m missing the log output. Obviously ReSharper build catches it, as I see the last (maybe 200) lines if the build is successfull. But I cannot see it, while the build is running (gives you a good feedback) nor do I see it in case of an error or a warning (helps in analyzing some tricky errors)

  36. THIS IS AWESOME SAUCE!

    I’m annoyed I have only just now found out about this.

    Is this available as a stand-alone console tool?!

  37. Bradley Vause says:

    Hi,

    When building and debugging and android app on a Genymotion emulator, the Resharper build took twice as long as the Visual Studio build.

    Just an FYI

  38. Dam says:

    Hi, is there some way to remove the ‘green’ background of the Windows Task bar when the build is done? Disable the ‘Task bar: show build progress in windows task bar’ does not remove the green background when the build is done.

  39. Pingback: Visual studio performance tips – maesterz

  40. Pingback: Why Visual Studio keeps rebuilding my projects for no good reason - Michael's Coding Spot

Leave a Reply

Your email address will not be published. Required fields are marked *