2016-09-23 56 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包到项目中。这将确保失败会导致构建按预期失败。