2016-09-23 53 views
5

繼續從MS的this教程,我已經創建了一個Roslyn分析器。Roslyn分析儀規則不會失敗的版本

根據頁面,您可以標記該規則爲DiagnosticSeverity.Error,而這將導致構建打破:

In the line declaring the Rule field, you can also update the severity of the diagnostics you’ll be producing to be errors rather than warnings. If the regex string doesn’t parse, the Match method will definitely throw an exception at run time, and you should block the build as you would for a C# compiler error. Change the rule’s severity to DiagnosticSeverity.Error:

internal static DiagnosticDescriptor Rule = new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat, Category, DiagnosticSeverity.Error, isEnabledByDefault: true, description: Description);

在我的代碼,我已經創建的規則或多或少這裏詳細:

private static readonly DiagnosticDescriptor Rule = 
    new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat, Category, 
    DiagnosticSeverity.Error, true, helpLinkUri: HelpUrl); 

此規則正常工作。它拋出紅線,它顯示錯誤列表中的消息。但是,構建成功,並且我能夠成功運行該應用程序。

注意:我創建了這個規則來捕獲Thread.Sleep這個例子。

Code Capture

有保證的規則打破了構建需要額外的設置嗎?

回答

11

這是從VSIX文件運行的分析儀的一個功能。

If the IDE-installed rules ran as part of the in-IDE build, it would result in IDE builds and command line builds having potentially very different outputs. For example, a user with code-cracker installed as a VSIX could end up filing a bug report that an open source project does not build due to an analyzer error (or perhaps a warning when the project uses /warnaserror). They would be forced to either uninstall the analyzer extension or modify the rule set used by the project to disable some rule that only exists on one developer's machine.

In contrast, rules that are installed via NuGet become part of the project and part of the build. They run the same way across developer machines, and they run the same way in-IDE, on the command line, and in automated build environments.

Source: IDE rules don't fail builds

爲了使構建失敗的規則,則需要分析儀添加爲NuGet包到項目中。這將確保失敗會導致構建按預期失敗。