0

For FxCop Integration with SVN,

Requirement: Whenever, a developer tries to checkin the code in SVN, Fxcop should run and check if all files are as per rules or not. If not, then file commit should not be allowed in SVN.

Implementation: Added a batch script in SVN at pre-commit hook. In the same firstly I pointed out to FxCop.exe, but it just open's up a fxCop window. Secondly, I pointed ..\Microsoft Fxcop 10.0\FxCopCmd.exe , but this time while committing any file in SVN it play around with some command prompt screen but eventually it gets disappears and along side SVN also allowed the file to check-in. Thridly, I pointed ..\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe, and the result process remains same as of second attempt.

For StyleCop Integration with SVN,

Requirement: Same as FxCop

Implementation: There is no such command exe in case of StyleCop, so don't know exactly what to point in batch Script(at pre-commit hook)

I seek a proper solution for same as everytime looking for this query, I only found ir-relevant links.

Thanks..

alroc
  • 27,574
  • 6
  • 51
  • 97
Apoorve
  • 1
  • 1

2 Answers2

1

You can't do this with TortoiseSVN. You need to configure a pre-commit hook script on your server so that it applies to every commit with no way for the user to bypass it, regardless of client.

Which means you'll need StyleCop & FxCop installed & configured appropriately on your Subversion server. And then a pre-commit hook to call them as appropriate. But to do that, you need a working copy of your code on the server that is kept up to date then has the changes in the transaction applied to it.

Once you've done that, you need to consider whether this is even the appropriate way to address your requirements in the first place. IIRC, transactions are not "serialized" in the pre-commit stage the same as they are for the actual commit. That is, if two users attempt to commit at the same time, whoever finishes pre-commit first (successfully) will get to actually commit - the second user may get rejected because they're now out of date.

If your pre-commit hook takes a long time to process, this could cause a lot of frustration for your users - even without the condition described above. With the condition above, the second user could get to commit first if their rules checks run faster than the first user.

But you'll also need a "fresh" working copy for each incoming commit transaction regardless, because you need to be sure that you're comparing the new state of the code to what's currently in the repository. Which means a fresh checkout each time you call pre-commit.

That's a lot of waiting for your users, a lot of space used on the server, and a lot of moving parts that can break.

So what do you do instead?

Enforcement of rules such as this are usually better managed after the commit via a continuous integration system which checks out the source, compiles, runs tests, etc. and then alerts the team as to who has broken the build. This way, you can keep people moving at a good pace and not slow them down while they wait for someone else's commit to complete. And when everyone knows that the whole team will find out that they've broken the standards (FxCop or StyleCop return "errors") or the whole build (the code fails to compile, or your automated tests fail), they'll start being a lot more careful with their commits.

Community
  • 1
  • 1
alroc
  • 27,574
  • 6
  • 51
  • 97
  • Thanks for your valuable suggestion and time. – Apoorve Jun 12 '13 at 13:29
  • Thanks for your valuable suggestion and time. FYI, we are using Team City, so what we can do is we can test for FxCop and StyleCop through Team City and then allow for executing build in Team City. Means, the build steps could be first fxCop then StyleCop and at last executing final code build. If the build gets failed then we can set for email notification to taht particular developer. But, most above all, have to try for integrating FxCop & StyleCop in Svn. And as you mentioned, we are following the all point but still nothing worked. If possible provide the pointer to implement same. – Apoorve Jun 12 '13 at 13:36
  • If you're already using TeamCity, you probably already have everything you need to implement what I describe in my last paragraph. Abandon the idea of doing your FxCop & StyleCop checks with Subversion entirely, and focus on doing it as part of your process in TeamCity. Fail the build if the Fx & Style report failures/violations, regardless of whether it compiles cleanly. – alroc Jun 12 '13 at 15:16
0

Most StyleCop checking is passive (invoked by the developer or in the build environment). I also wanted to be reminded during check-in that your code can be improved.

I've created a project that combines the TortoiseSVN Hook mechanism with running a console StyleCop instance.

It is fairly simple to do. Project files available at GitHub

gwallis
  • 1
  • 2
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient [reputation](http://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](http://stackoverflow.com/help/privileges/comment). – Blazemonger Mar 24 '14 at 15:12
  • @Blazemonger - The question asks for an .exe implementation to integrate stylecop with TortoiseSVN. I implemented the project specifically after I was looking for a solution to the same question. – gwallis Mar 24 '14 at 17:58
  • Have an article on [http://www.codeproject.com/Articles/748836/Check-StyleCop-Rules-on-TortoiseSVN-Commit] (Code Project) to explain how it is used and integrated. – gwallis Mar 24 '14 at 18:01