Generated code should not be analyzed

[wekempf]

Generated source code is being analyzed, and since the code is generated every build there's no simple way to fix the warnings/errors produced by these analyzers. I believe generated code should not be analyzed.

I'm new to Rosalyn, but as near as I could figure out there is no general (i.e. known best practice) solution to this issue. It looks like another project has a set of extension methods they use within their analyzers to ignore generated code. code-craker

[sharwell]

Hi @wekempf, and welcome to the project! 😄

Our intention is to not analyze generated code, and we have a number of mechanisms in place to prevent it from happening. We use a special set of rules which are designed to maximize the overall performance of the exclusions and minimize the number of files which are falsely excluded. The following will help narrow it down:

1. The ID of one of the analyzers which is reporting warnings in the file (e.g. "SA0000")
2. The name of one of your generated files which is reporting warnings
3. The header of the generated file (everything before the first namespace would be great)
4. The tool used to generate the file (if known)

[djheap]

Here's what I'm seeing in a WPF application:

2>C:\Projects...\obj\Debug\GeneratedInternalTypeHelper.g.cs(1,1,3,1): error SA1518: Code must not contain blank lines at end of file
2>C:\Projects...\obj\Debug\GeneratedInternalTypeHelper.g.cs(1,1,3,1): error SA1517: Code must not contain blank lines at start of file
2>C:\Projects...\obj\Debug\GeneratedInternalTypeHelper.g.cs(1,1,1,1): error SA1633: The file header is missing or not located at the top of the file.

The file itself just has 3 blank lines.

I believe it is generated by VS2015 for WPF code-behind or maybe resource elements (at least we aren't using any other build tools that I'm aware of).

[pdelvo]

I tried to repro this: I created a new wpf application, added the analyzers and recompiled. The file you are talking about was not generated. I search for it and found one here. When manually adding this file to the project it is correctly detected generated and excluded from analysis (there is an auto generated comment at the top). Could you maybe upload the file on your machine? Maybe VS15's version of this file looks different. Im not sure what I have to do to make it auto generate.

[djheap]

The contents are just 3 blank lines.

There is also a file very similar to the one you link to but named slightly differently (*.g.i.cs versus *.g.cs) -'GeneratedInternalTypeHelper.g.i.cs' and it has contents like the linked file with the auto-generated comment at the top.

However, the original 'GeneratedInternalTypeHelper.g.cs' problem file doesn't have it - it is just 3 blank lines.

I'm trying to repro it in a small project as well but no luck so far. It may have to do with 3rd party controls (we use Mindscape controls) that require a license -- I'll keep trying.

[pdelvo]

What happens if you clean the project/solution or delete that file?

[sharwell]

@djheap I agree those files should not be analyzed. I filed issue #1040 to address it.

[djheap]

Deleting it manually works until a rebuild re-generates it.

Oddly, it looks like it has the same contents as the other '.i.cs' file for while during the build but then gets stomped with 3 blanks at some point. They both appear and seem to be identical for a short while.

[wekempf]

The "tool" that's creating the generated file that isn't ignored for me is GitVersion. Create a new project and add the NuGet package as per the directions and you should be able to easily repro. The generated file is named GitVersionTaskAssemblyInfo.g.cs. There's nothing in the file to indicate it's generated, only the file name does. In my project it's generating 60 warnings, including the ids: SA1101, SA1201, SA1400, SA1401, SA1402, SA1508, SA1516, SA1517, SA1518 and SA1600. You can see why I just assumed no attempt was being made to ignore generated files. There is no namespace in this file, so no "header". If you need the whole file I can post the contents. If you need anything else, let me know.

[sharwell]

@wekempf Thanks. The project appears to be open source, so the first thing we'll try is sending them a pull request to use a standard <auto-generated> header which StyleCopAnalyzers will pick up. 👍

[wekempf]

I considered doing that as well, but it shouldn't be necessary for this project. The file name clearly indicated it was a generated file.

[wekempf]

I found where you're trying to ignore generated files. You make a minimal attempt at recognizing generated file names with the following code:

return Regex.IsMatch(
            Path.GetFileName(filePath),
            @"\.designer\.cs$",
            RegexOptions.IgnoreCase | RegexOptions.ExplicitCapture);

The other analyzer project I referenced has a more comprehensive check.

Regex.IsMatch(filePath, @"(\\service|\\TemporaryGeneratedFile_.*|\\assemblyinfo|\\assemblyattributes|\.(g\.i|g|designer|generated|assemblyattributes))\.(cs|vb)$",
            RegexOptions.IgnoreCase);

I'm not sure I'd ignore AssemblyInfo, so maybe that's not the best Regex either. However, g.cs and g.i.cs are extremely common "extensions" for generated files, and I'd ignore them.

[sharwell]

We originally used that check as well. However, I prefer to not make assumptions wherever possible. The one remaining check is in place because the Windows Forms designer does not add an auto-generated header and we have no control over it. I'll add more information later (out with friends now).

[wekempf]

I understand wanting to be conservative here, but personally I feel .g.cs and .g.i.cs exclusions are safe and sane. In any case, I made another suggestion in issue 1045 that would allow you to be super conservative while still allowing users some greater control here.

[sharwell]

@wekempf See GitTools/GitVersion#535 for the GitVersion issue I'm planning to resolve. 👍

[sharwell]

I submitted GitTools/GitVersion#537 to correct the issue.

[ghost]

When building Windows 8.1 Code, the Visual Studio 2015 compiler generates XamlTypeInfo.g.cs (to assist the XAML parsing). Obviously these generated files won't pass the analyzer's tests and the file does contain a <auto-generated> tag in the header. However, the latest release - 1.0.0-beta003 - is still attempting to analyze the generated code and is issuing warnings.

[sharwell]

Welcome to the project @DRAirey1 😄

Can you open a new issue since the tool that caused this is different? Also, can you include the following to help us narrow down the cause:

1. A copy of the file's header comment (from the beginning of the document to the first using or namespace declaration, whichever comes first.
2. The ID of at least one warning which is getting reported in the file.

[ghost]

Many apologies. As I was typing up the new issue, I realized the errors were CS errors and not SA errors. This looks like a Microsoft issue, not yours.

[sharwell]

Not a problem 😄

While you can't use #pragma warning disable in that generated code, you should still be able to use the old [SuppressMessage] attribute to disable them.

[shaunluttin]

Add #pragma warning disable to the top of all AssemblyInfo.cs files.

PS> Get-ChildItem -Recurse AssemblyInfo.cs | `
    % { @("#pragma warning disable", "") + (Get-Content $_) | Set-Content $_ }

[luiscaiano]

hi, i am using version 10.2, and for some reason i have a comment console wirte with message "... <auto-generated>", this disables the codemaind funcionalities
i worked around it by doing a string concat.