Filter Output of an Msbuild CreateItem for StyleCop Incremental Checking

Question

I am trying to modify the stylecop targets to support incremental checking on only files that have changed.

When debugging, I see that @(Compile) is the list of the files that are to be checked; however, I would like to filter this list to only files that have been changed (i.e, those that have a timestamp later than the target dll, which i know I can reference as $(TargetPath) ).

How can you recurse over the output of that createitem, "StyleCopFiles" and remove those files that have not changed?

Below is the target, that I would like to add a filter condition to:

<Target Name="SetUpStyleCopProperties">
        <!-- Determine what files should be checked. Take all Compile items, but exclude those that have
        set ExcludeFromStyleCop=true or ExcludeFromSourceAnalysis=true. -->
        <CreateItem Include="@(Compile)" Condition="('%(Compile.ExcludeFromStyleCop)' != 'true') and ('%(Compile.ExcludeFromSourceAnalysis)' != 'true')">
            <Output TaskParameter="Include" ItemName="StyleCopFiles"/>
        </CreateItem>

        <!-- Show list of what files should be excluded. checked. Take all Compile items, but exclude those that have
        set ExcludeFromStyleCop=true or ExcludeFromSourceAnalysis=true. -->
        <CreateItem Include="@(Compile)" Condition="('%(Compile.ExcludeFromStyleCop)' == 'true') or ('%(Compile.ExcludeFromSourceAnalysis)' == 'true')">
            <Output TaskParameter="Include" ItemName="StyleCopExcludedFiles"/>
        </CreateItem>
    </Target>

Answer 1

What you are proposing would be possible with the use of a custom MSBuild task. However, incremental StyleCop analysis probably wouldn't work as you seem to expect since failing StyleCop analysis won't necessarily prevent compilation. Imagine the following sequence of events under your proposed incremental analysis:

1. File A.cs is modified, including introduction of a problem that would cause a StyleCop warning.
2. The project is built.
3. File B.cs is modified, including introduction of a problem that would cause a StyleCop warning. (File A.cs is not modified.)
4. The project is built.

At #2, you would see a StyleCop warning for the problem in A.cs. However, at #4, you would only see the problem in B.cs, not the problem in A.cs. Is this really what you want?

If you really find that StyleCop is causing a problematic delay during developer local builds, there is another alternative: create an alternate build configuration that omits StyleCop. For example, I routinely create a "DebugCompileOnly" solution configuration that omits both StyleCop and FxCop analyses. Developers are free to use this as they wish on their local machines, but they are supposed to compile under the Debug configuration (which includes both tools) before a commit. The continuous integration build on the build server uses the Debug configuration, thereby ensuring that any failure to do so is identified very quickly.