Automating ReSharper's Inspect Code

If you write C#, I hope you have ReSharper.

If you have ReSharper, I hope you have tried its "Code Issues" feature. It has lots of good suggestions, and I need all the help I can get.

Staying clean requires running the analyzer over your whole solution. ReSharper doesn't update its results automatically: you have to explicitly click to make it happen. I hate explicitly clicking. It's also slow.

I decided to see if I could run it automatically in a Continuous Integration build server. I have figured out how to do so using TeamBuild on Visual Studio Online (VSO). Here's how:

1. Create a new Repo in VSO. Clone it locally.
2. Add your solution
3. Connect to your VSO repo in Visual Studio.
4. Create the PreBuild.ps1 script you see below, to install ReSharper's command line tools
5. Create the TeamBuild.proj script you see below, to run InspectCode and build your solution
6. Team Explorer -> Builds -> New Build Definition. Select the Process tab
1. Set Build Process Template to GitTemplate.12.xaml
2. Projects = TeamBuild.proj
3. Pre-build script path = Tools\PreBuild.ps1
7. Run the script once on your machine to establish a baseline. Add it to Git.
8. Push

Now, when  the set of Code Issues changes, you'll get notified by the build.

	<?xml version="1.0" encoding="utf-8"?>
	<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
	<PropertyGroup>
	<SolutionPath>InspectCodeExample\InspectCodeExample.sln</SolutionPath>
	</PropertyGroup>
	<PropertyGroup>
	<!-- keep this in synch with Tools\PreBuild.ps1 -->
	<ResharperCltVersion>8.2.0.2151</ResharperCltVersion>
	</PropertyGroup>
	<!--=====================================================================-->
	<Target Name="Build">
	<MSBuild Projects="@(SolutionPath)" />
	<CallTarget Targets="InspectCode" />
	</Target>
	<!--=====================================================================-->
	<Target Name="InspectCode">
	<!--I found that this approach caused InspectCode to crash with cryptic errors -->
	<!--<InspectCode SolutionFile="$(SolutionPath)" OutputFile="$(TEMP)\InspectCodeOutput.xml" NoMSBuildOutput="true" />-->
	<Exec Command="C:\Chocolatey\bin\InspectCode /o=$(TEMP)\InspectCodeOutput.xml $(SolutionPath)" />
	<Exec Command="fc.exe InspectCodeBaseline.xml $(TEMP)\InspectCodeOutput.xml" />
	</Target>
	<!-- Required if you use the InspectCode target above -->
	<!--<Import Project="C:\Chocolatey\lib\resharper-clt.portable.$(ResharperCltVersion)\tools\InspectCode.MsBuild.Targets"/>-->
	</Project>

view raw TeamBuild.proj hosted with ❤ by GitHub

	#
	# keep this in synch with TeamBuild.proj
	#
	$ResharperCltVersion='8.2.0.2151'
	# UseBasicParsing is required if IE has never been run on the machine.
	wget -UseBasicParsing chocolatey.org/install.ps1 | iex
	if (!$?) { throw "failed to install chocolatey"}
	cinst resharper-clt.portable -version $ResharperCltVersion
	if (!$?) { throw "failed to install R# CLT"}

view raw PreBuild.ps1 hosted with ❤ by GitHub

I'd like to find a way to do this in Travis-CI, which would require running these tools on Mono. Let me know if you get it to work.

The last responsible moment may be right away!

In Agile, they talk about deferring work and decisions until the "last responsible moment". Later I will know more (so I can make a better decision), and maybe I won't need the work at all (avoiding wasted effort). There may be other reasons.

Recently I've noticed a handful of decisions that should be made really early. Some examples:

• 1-step build
• unit test infrastructure
• create a Git repo
• 0 warnings
• clean static analysis / lint
• slow build tripwire

Some of these are important because they're easiest if you do them before you have any code. 

For example, I've worked on many projects where build + test time was quite long. The slow edit/build/test cycle makes me less productive, so I'd like to optimize it. But the optimization work is expensive for the same reasons: because verifying the changes is slow. 

.@jaybazuzi In all honesty, my build spits out a warning when it gets above 5 seconds. I occasionally optimize as a result.
— James Shore (@jamesshore) April 29, 2014

The longest build I've worked with was 12 hours end-to-end. We all knew it *could* have been faster, but that optimization work seemed so daunting. I could optimize all day long, and get to 11h55m. 

I know there was a ton of duplicated code in different parts of the system. But refactoring to eliminate that duplication was also hard.

If we had maintained a fast build from the beginning, it would have been easier to keep it that way.

There is a balance to be struck. Maybe you're not sure if the idea you have is actually viable. You may want to spike it, or show a prototype to a user, before investing significantly in the idea. (See Lean Startup).

There are other tasks that should come soon but not necessarily immediately, like pushing that Git repo to another machine (so you don't lose it), or setting up an automatic CI build.