-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated files are missing a standard auto-generated header #535
Comments
Just read the issue, why doesn't it get excluded already. The filename is |
The file is also injected during the MSBuild pipeline, so the user can never see or edit the file |
@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. |
Not against the header, just wondering if there are other ways :) What about the |
@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? |
I definitely don't mind answering questions. 😄 We avoid checking 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. |
@SimonCropp Here are some additional examples of places where
It may have started with StyleCop, but it's become a de-facto standard since then. |
yes but none of those are temporary files |
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! 😄 |
@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 @SimonCropp Here are some additional examples of places where
Reply to this email directly or view it on GitHub: |
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.📝 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. 😄
The text was updated successfully, but these errors were encountered: