0

20個のc＃プロジェクトを含むソリューションがあります。最近まで、StyleCopは、自動生成されたファイルを除くすべてのファイルに対してすべてのプロジェクトで実行され、検出された問題を報告していました。最近（正確な時期は明確ではありませんが）、どのファイルに対して問題を報告するかについて慎重になっています。

特定のプロジェクト内で、意図的に同じ欠陥を複数のソースファイルに追加すると、StyleCopが問題を報告する場合もあれば、報告しない場合もあります。

同じコードの以前のブランチは、10月以降ほとんど変更されていませんが、この動作は表示されません。ソースコードだけを変更することで、最新のコードに存在する問題を示すことができますが、10月以降のコードにはありません。

スキップされたファイルには、StyleCopにスキップさせると予想される「自動生成された」マーカーが含まれておらず、スキップされたファイルと分析されたファイルのどちらにも共通点がありません。

ソリューションファイルはブランチ間で変更されず、csprojファイルへの唯一の変更はソースファイルの追加/削除です。

誰かがこの動作を引き起こしている可能性のあるアイデアを持っていますか？

4

1 に答える 1

3

だから、かなりのチョコレートの消費と多くの罵倒の後、私は答えを持っています：

最近、すべてのソースファイルの上部に著作権表示を挿入しました。一部のソースファイルには、ファイルの先頭にバイト順マーク（U + FEFF）があり、通知がこの文字の前に挿入されていたことがわかりました。

StyleCopはこの文字の存在に不快感を与え、ファイルの残りの部分を黙って無視します。

キャラクターが正しくVisualStudioIDEによってレンダリングされていないことを考えると、それを見つけるのに3日かかりました:(

編集（2013.01.14）：ソースファイルからBOMを削除するPerlスクリプトを作成しました：

#!/usr/bin/perl -w
use strict; 
use warnings;
use File::Find;

my @dir = "C:/TopLevelSourceCodeDirectory";

find(\&edits, @dir);

sub edits() {

    my $file = $_;

    if( (-f $file) 
        && 
        (
            ($file =~ /.*\.cs$/)
            ||
            ($file =~ /.*\.xaml$/)
            ||
            ($file =~ /.*\.whatever$/)
        )
      ) {

        #Open the file and read in the data
        open (my $in, '<', $file) or die "Can't open $file: $!\n";
        my @lines = <$in>;
        close $in;

        #Open same file for writing
        open (my $out, '>', $file) or die "Can't open $file: $!\n";

        #Walk through lines, putting into $_, and remove BOMs
        for ( @lines ) {
            s/\xef\xbb\xbf//g;
            print $out $_;
        }

        close $out;
    }
}

最後に1つ。特定の文字列を貼り付けたときに、メモ帳がファイルの中央にBOMを追加しているように見えたため（もちろん、これらの文字列にはBOMが含まれていなかったとしても）、このスクリプトの作成に多くの問題がありました。 。マッチャー文字列の中央に非表示のBOMがあることがわからないのに、正規表現が一致しない理由を理解するのは楽しいことではありません。

于 2013-01-11T15:57:50.597 に答える