I'd recommend against a custom TFS check in policy. They get evaluated on the client meaning a) they interfere with developer workflow b) they can get overridden on the client (and it can be difficult to get notifications when developers override the policy), and most importantly c) you need to manage getting the assembly with your custom policy on it onto your developer machines and keeping it up-to-date.
The best thing to do, I think, is to integrate StyleCop with MSBuild so that you get build warnings or errors if StyleCop detects issues. There's a handy nuget package to get you started. This gives you a lot of flexibility to enforce code style rules. You can use this alongside the last-build-successful policy, or better use Gated Checkins so that the evaluation happens on the server.
Bear in mind the following:-
If you want to fail the build because of StyleCop violations, you'll need to set
<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
in your project file.From personal experience, I'd recommend only setting
StyleCopTreatErrorsAsWarnings
false on your release configuration(s). If your developers have to add xml comments before they can, say, check if something compiles, then you're going to have trouble!You'll need to spend a little time setting up which StyleCop rules you want to enforce for your project. Make sure they get source-controlled along with the .sln - you don't want to have to mess around with them on individual developer machines.
Start with a small ruleset that's quite permissive and expand as you go.
Don't waste expensive programmer time manually reformatting code files to match the style guidelines. Get resharper and set it up so that the code cleanup function tidies things up correctly.