Generated files are missing a standard auto-generated header

[sharwell]

Several source analysis tools look for an "auto-generated" tag in the header of generated files in order to suppress analysis for these files. One example of such a tool is StyleCop. Here is an example of a suitable header. The specific part of the header which the tools look for is the substring <auto-generated. The remaining part is informational, but frequently included in such headers.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     GitVersion
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

📝 I'm planning to submit a pull request soon with a proposed implementation of this. But if someone wants to beat me to it, that's fine too. 😄

[JakeGinnivan]

Just read the issue, why doesn't it get excluded already. The filename is GitVersionTaskAssemblyInfo.g.cs which indicates it's a generated file already?

[JakeGinnivan]

The file is also injected during the MSBuild pipeline, so the user can never see or edit the file

[sharwell]

@JakeGinnivan We avoid making assumptions regarding generated files according to the filename to the maximum extent possible. There is one tool which ships with Visual Studio which we don't have control over (the Windows Forms designer), so it's the one exception to this rule. If you look at the output of the XAML designer (which creates .g.cs files during the build), you'll see that they each contain the header I mentioned. We use that header as opposed to the filename for excluding them from analysis.

Since StyleCopAnalyzers is tied directly into the compiler, it can't tell the difference between files in source control and files added during the build process. If the file is part of what gets compiled, it's automatically included for analysis as well. This is actually one of the amazing features of the new compiler toolchain, because it makes it very easy to write accurate analyzers without worrying about details of the build process.

[JakeGinnivan]

Not against the header, just wondering if there are other ways :)

What about the [CompilerGenerated] attribute?

[SimonCropp]

@sharwell it seems StyleCop has allowed the convention taken by historical designer implementation to leak into a feature of StyleCop. Now you are trying to push that convention back into other tooling.

As @JakeGinnivan wouldnt also supporting [CompilerGenerated] be a better approach?

[sharwell]

I definitely don't mind answering questions. 😄

We avoid checking [CompilerGenerated] because it (in theory) would only apply to portions of a source file. This was actually proposed in the original submission of DotNetAnalyzers/StyleCopAnalyzers#670. The problem with this mechanism is it prevents us from using a per-document cache to improve the performance of this check, resulting in walking the syntax tree looking for reasons to exclude particular results. Several of the StyleCop analyzers require looking at a large number of elements in every file (e.g. several of them look at every whitespace token). Any use of an attribute exclusion would result in a substantial performance impact on the tool. Considering our target audience includes projects with tens of thousands of source files, it just wouldn't work in practice.

The document header exclusion is extremely efficient in our current implementation. If you're interested in the way we cache results, looking through the comments of DotNetAnalyzers/StyleCopAnalyzers#670 would be a great place to start.

[sharwell]

@SimonCropp Here are some additional examples of places where <auto-generated> is added as described in this issue:

• Code generated by the XAML compiler (already mentioned)
• Code generated for the designer files used by the RESX tooling
• Code generated when you use the Add Service Reference feature
• Code generated by Entity Framework tooling
• Many third-party tools

It may have started with StyleCop, but it's become a de-facto standard since then.

[SimonCropp]

yes but none of those are temporary files

[sharwell]

The code generated by the XAML compiler is emitted to the intermediate output directory (e.g. obj\Debug). Although for the purpose of indicating the content of a file is generated I don't understand why "temporary" or "not temporary" would make a difference.

Time for 😴 will check back (and send a PR with my proposal) tomorrow! 😄

[gep13]

@sharwell as a side question....

I am a long term user of StyleCop, and I haven't had a chance to use the new StyleCop Analyzers. Do they support usage of the Settings.StyleCop file?

Sent from my Windows Phone

---

From: Sam Harwellmailto:notifications@github.com
Sent: ‎26/‎07/‎2015 07:42
To: GitTools/GitVersionmailto:GitVersion@noreply.github.com
Subject: Re: [GitVersion] Generated files are missing a standard auto-generated header (#535)

@SimonCropp Here are some additional examples of places where <auto-generated> is added as described in this issue:

• Code generated by the XAML compiler (already mentioned)
• Code generated for the designer files used by the RESX tooling
• Code generated when you use the Add Service Reference feature
• Code generated by Entity Framework tooling
• Many third-party tools

---

Reply to this email directly or view it on GitHub:
#535 (comment)