Winforms: The comments generated by the designer do not make sense, please cancel

[maikebing]

I recommend canceling the designer to generate comments, or not internationalization,
Because different language programmers generate comments in different languages when they adjust the interface, there are a lot of changes when they are submitted to git, which is actually of little practical significance.

[KlausLoeffelmann]

I think I know what you mean, but could you give an example, so people not so familiar with CodeDomSerialization (I assume your talking about the Windows Forms Designer?) would better understand?

[maikebing]

Yes ，Both of Windows Forms Designer and Resources Designer

[zsd4yr]

@maikebing could you supply specific examples of comments which you feel do not make sense? Can you supply the text and where it is being generated?

[maikebing]

While I'm involved in the international software work, developers in different countries use visual Studio in different languages, and each time the window form is modified, the designer generates comments in different languages, and when submitted to git, it produces a lot of meaningless modifications and deletions! So, I think we should delete these comments.
I've written an example, please click here.

https://github.com/maikebing/winforms228/commit/2d59c1ccabd931a3570207b7f770052bdc1ecb80#diff-0d7de1b9e902ff0b0b4f122b49c169d2

[zsd4yr]

Diff tools can be configured to ignore code comments, which would handle the majority of these. Is that not a viable solution to your scenario, or is it an inconvenient one?

[maikebing]

Very inconvenient.

[jnm2]

The diff tools I most commonly use are Visual Studio, the git CLI, Visual Studio Code and TFS 2018's and GitHub's PR review UIs. I think it makes the most sense to cater to the common denominator when it comes to diffing.

Then there's the matter of the git blame when way too much of the file is touched for each tiny change.

[sharwell]

Yeah, this is a massive bug which essentially blocks all non-English-speaking users from contributing to projects. It is imperative that it get fixed. There are three partially acceptable solutions:

1. Generate code in the project directory with an invariant culture
2. Generate code in the intermediate output directory during the build with an invariant culture
3. Generate code in the intermediate output directory during the build with the current culture

With these in mind, understand that option (3) is not viable for deterministic builds (which is the default for SDK builds, and recommended for all builds).

Diff tools can be configured to ignore code comments, which would handle the majority of these. Is that not a viable solution to your scenario ... ?

No, it is not a viable workaround. Code review and update tools are not designed to handle this situation since the situation should never have occurred.

[wjk]

@sharwell I would go for option 2 personally. Once Microsoft/msbuild#2221 is resolved, this will become a lot easier (at least for resx files), although it can still be done today on full-framework MSBuild only. I use the MSBuild targets file for my projects:

<Project>
  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>

  <PropertyGroup>
    <CoreCompileDependsOn>PrepareResources;$(CoreCompileDependsOn)</CoreCompileDependsOn>
  </PropertyGroup>

  <Target Name="_AutoSetResGenMetadata" DependsOnTargets="PrepareForBuild;PrepareResourceNames" BeforeTargets="CoreResGen">
    <Error Message="DefaultLanguageSourceExtension not defined" Condition="'$(DefaultLanguageSourceExtension)' == ''" />
    <ItemGroup>
      <EmbeddedResource Update="@(EmbeddedResource)" Condition="'%(EmbeddedResource.GenerateCodeBehind)' == 'true' or '%(EmbeddedResource.Generator)' == 'MSBuild:PrepareResources'">
        <StronglyTypedClassName Condition="'%(EmbeddedResource.StronglyTypedClassName)' == ''">%(FileName)</StronglyTypedClassName>
        <StronglyTypedFileName>$(IntermediateOutputPath)%(EmbeddedResource.ManifestResourceName)$(DefaultLanguageSourceExtension)</StronglyTypedFileName>
        <StronglyTypedLanguage>$(Language)</StronglyTypedLanguage>
        <StronglyTypedNamespace Condition="'%(EmbeddedResource.StronglyTypedNamespace)' == ''">$([System.Text.RegularExpressions.Regex]::Replace('%(EmbeddedResource.ManifestResourceName)', '\.[a-zA-Z_][a-zA-Z0-9_]+?$', ''))</StronglyTypedNamespace>
      </EmbeddedResource>
    </ItemGroup>
  </Target>
</Project>

I would then set the Generator of all resx files that need code-behinds to MSBuild:PrepareResources (and delete the old *.Designer.cs file, if required).

Also, why is option 3 not viable for deterministic builds? Isn't the only thing that varies the language used to generate comment text, which should have no effect on the built product?

[merriemcgaw]

This is a great idea everyone, thanks for the suggestions! This repo doesn't track designer work so I am creating a workitem in our internal AzDO instance. I think we'll try to get it on the schedule for an upcoming preview of VS Dev16 (tentative of course). We'll circle back when there's news to update. Note that if you want to give design time feedback, the best way is through the VS feedback tooling. This will get your issue on our radar and automatically send us quite a bit of diagnostic information that we can use to troubleshoot issues.