I'm withdrawing my objection to the implementation change. It should be possible to set this command line option through the build targets.

I maintain my objection to the rationale for the change. One case where this feature should not be used is for the situation described in the original post. If the tool is failing to generate the <auto-generated /> comment by default, then the tool has a bug that still needs to be addressed after this change is merged.

@sharwell : So you would suggest to change the tool itself to always add the autogenerated line at the top? For clients, that would even be less of a hassle then.

@pgrawehr I see two options here:

1. Always add the comment (which would need to precede the header, otherwise if the header contains a blank line then the auto-generated comment would not be found)
2. Implement the auto-generated comment as a default header that is used in cases where the --file-header argument is omitted (i.e. users who provide a custom file header would need to make sure it included this comment)

Each option has advantages and disadvantages. Option 2 seems particularly safe and addresses the needs of most users without requiring other changes.

Option 2 sounds ok for me. I'll try to provide something.

Awesome!

FWIW, historically this comment was generated with the following form:

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

The only part that the tools actually look for is the sequence <auto-generated, so you can decide whether to use the short form or the full form as the default.

Yea, I've seen this before - I've even seen it being translated to the user's language (I tend to have all tools, even compilers installed in german). So I might need to search for the matching resource.

📝 Translating the strings will cause problems in two cases:

1. The generated code ends up in source control, e.g. when .resx is converted to the .Designer.cs file
2. Attempting deterministic builds (the build now depends on the current culture)

💭 This may have been one of the reasons why the long comment was dropped. Not sure about that though.

That's also what I've observed before 👀
So better keep it simple. I've got no problems with that.

@sharwell Added code to always include a header in the file, unless the user specifies its own (and as long as it's C#)

@sharwell Any further work required? It would be good if this could be merged soon, as dotnet/iot depends on this working (or all the StyleCop stuff we've done over there will get broken again because the builds can't be enabled to fully test the rules)

@pgrawehr it looks fine to me, but I'm not a maintainer on this repository so someone else will need to do the final review and merge.

I think this looks fine though ASP.NET Core wouldn't use this because we use --header-file (for a license header). Suggest @ericstj as a "real" reviewer.

Looking...