This project is read-only.

Stylecop runs after build, even with no modifications

Oct 7, 2010 at 6:33 AM

I am using StyleCop, Visual Studio 2008 on Windows Server 2003.

I have added the <Import> element into my csproj, to automatically run StyleCop after a the project builds.

If there are no changes in the project, and I start a build (using Shift-F6), Visual Studio is clever enough to not actually initiate a build.  However, StyleCop still runs afterwards, even though there are no changes to any files in the project.

Is there a configuration option that will prevent this happening?

Oct 25, 2010 at 9:01 PM

The bulk of this question is beyond me (I haven't set up StyleCop in this manner before and don't know of such a config setting).

However, the first time you open a VS and a solution, whether VS performs a build or not, you would still want StyleCop output to still show up and populate the VS errors area, right?  IE if there are outstanding StyleCop issues, should those still show up regardless of whether a source build occurred right there?

Oct 25, 2010 at 11:11 PM


I'm not sure I want StyleCop to automatically run when I first open a solution.  For most of my projects, that would mean I would sit around for several minutes waiting for it to complete.

My point is that if you have set up a project to automatically trigger StyleCop checks after a successful build (by using the <Import> element in the project file - click here to find out how), then it seems silly to have StyleCop run a check if Visual Studio has deemed that the project hasn't changed since the last build.

What I am looking for is some way for StyleCop to determine if Visual Studio has actually completed a full (re)build, and if not, then don't run StyleCop.

Does anyone know if this is possible.

Oct 26, 2010 at 8:40 PM

My question may seem strange, but why do you want to run StyleCop on every build then (I mean developer's build, while debugging)?

If your project is too large it makes sense to run StyleCop only when build happens on build-server, and developers can run StyleCop manually when they want.

P.S. I understand your very issue, and my answer is not a solution, I am just wondering.

Best regards,
Oleg Shuruev

Oct 26, 2010 at 8:54 PM

Hi Oleg,

There are two reasons for running StyleCop on each (actual) build.  The first (which won't change) is that it is a requirement of the development team that I am working with that StyleCop run on each build.  This is mostly because of the second reason, which is that sometimes developers 'forget' to run StyleCop before committing their code to the Build Server, which results in the build server picking up StyleCop issues.  Given the size of the projects we are working with, this can sometimes be hours later, often when the developer may have finished for the day.  With globally distributed teams, it means that other teams then need to investigate and resolve StyleCop issues, or you have to fix theirs!

I hope that explains things for you :-).



Oct 27, 2010 at 6:27 AM

Well, if you're using Team Foundation Server, there are check-in policies available that only execute before your code gets checked in. Our philosophy on it where I work is we don't care what your code looks like while you're working on it, as long as it goes into source control formatted properly. One benefit of this approach is any code you're working that you may not want to keep (testing a theory, etc) you don't have to worry about making it StyleCop compliant to test it. Some of our solutions are extremely large with 20+ projects and a few thousand files in each, so I understand where you're coming from.

If you're interested, the policy I wrote is hosted on CodePlex at:

Just a thought, good luck finding a solution!

- Jeff

Oct 29, 2010 at 4:04 PM
StuartBale wrote:
I hope that explains things for you :-).

In your case I would definitely recommend you using check-in policies (of course, it depends on your VCS), like Jeff has already suggested.
Then StyleCop will have to check only the changed files, not all the files.

Your current scenario is slightly strange - on the one hand you trust people, asking them to run StyleCop on their side.
On the other hand you are afraid that they will forget to check it and go home.

Seems that if you restricted committing wrongly formatted code, you would have much less problems.

Good luck!

Best regards,
Oleg Shuruev

Oct 29, 2010 at 7:31 PM

Oleg, you're right, my current scenario is slightly strange, however not for the reasons you suggest ;-).

Jeff, thanks for your suggestion. I don't have any control over the version control system in use, only the projects that I am coding, hence the adoption of the postbuild StyleCop check.

I guess either my suggestion to only run stylecop when Visual Studio has run a build must be a stupid idea, or that it isn't possible to do.

Maybe some future contributor to this codeplex project will find a way.  In the meanwhile, I'll work around it.


Oct 29, 2010 at 11:10 PM


There is nothing wrong with your idea, it just doesn't seem to be very popular.

However, I have another thought, at which you might pay attention.
When you run StyleCop manually, it has "Cache Results" feature. Does caching work when StyleCop runs after the build?

What I mean is that you could try the following simple test. In your large project execute "Run StyleCop" command - initial analysis will take some time. Then edit some file and run it once again - you will see that StyleCop will analyse only the edited file (and analysis will be extremely fast).

Does it behave in the same way when StyleCop runs through msbuild task?

Best regards,
Oleg Shuruev