Question

I know that a software engineer usually isn’t screaming, hey all I’m not getting an error, can you help me get one! But currently I need this error to show up locally because it’s failing on our CI build. It’s much harder to suppress (and please trust me I just need to suppress it because it’s generated code from a WF workflow) when I’m not getting the error locally because the syntax for the member name is at best, painful.

The build server’s CI build uses the Release configuration, and I’m building locally in Release, so ideally I’d be getting the same errors (an generally do).

Here is a snapshot of my Release section in my project file:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>bin\</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  <RunCodeAnalysis>true</RunCodeAnalysis>
  <CodeAnalysisRuleSet>..\..\SolutionAnalysis.ruleset</CodeAnalysisRuleSet>
  <StyleCopEnabled>true</StyleCopEnabled>
  <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
  <NoWarn>1591</NoWarn>
</PropertyGroup>

And on the build server I’m getting this error (type and path names removed for security):

obj\Release\WorkflowName_BeforeInitializeComponentHelper.cs (18): CA1822 : Microsoft.Performance : The ‘this’ parameter (or ‘Me’ in Visual Basic) of ‘WorkflowName.BeforeInitializeComponent(ref bool)’ is never used. Mark the member as static (or Shared in Visual Basic) or use ‘this’/’Me’ in the method body or at least one property accessor, if appropriate.

I hope that y’all can help me figure out why Visual Studio isn’t surfacing the error during a Release build locally … oh the INSANITY!

Answer 1

Okay, so I’m getting this error locally now by upgrading my local version of StyleCop. I’m not sure why that has any bearing on code analysis but honestly all of these tools just don’t play well together because we’ve also got ReSharper installed organization wide and it causes a lot of grief.

So, that being said, the way I ended up solving this anyway was to build partial classes for each WF Activity, i.e. XAML files**, that look something like this:

// ReSharper disable CheckNamespace
namespace {namespace}
// ReSharper restore CheckNamespace
{
    using System.CodeDom.Compiler;

    /// <summary>
    /// Sets up the [GeneratedCode] attribute for the generated workflow class so that code analysis isn't performed.
    /// </summary>
    [GeneratedCode("", "1.0")]
    public partial class {classname}
    {
    }
}

You can gather the {namespace} and {classname} from the x:Class attribute in the XAML that makes up the WF Activity (right-click on the XAML file and select “View Code”).

** You don’t need them for WF Services, i.e. XAMLX files