工作中，我们发现了微软.net WinForm的一个Bug，会导致窗体设计器自动生成的代码失效，这个Bug从.net4.5到最新的.net4.7.2都存在，一直没有解决。最初是我在教学工作中发现的，后来工作的时候该Bug也常现。
- 重现步骤：
使用VisualStudio2013/2015/2017/2019创建一个新的Windows窗体程序（使用C#或者VB.net都可以）
新建的默认空白的窗体程序，点击运行，可以正常运行：
这时，我们往窗体拖一个ListView控件，手动添加两列，名称分别为Id/编号、Name/姓名：
运行程序，报错：
点击错误详情，他给出提示让人丈二金刚摸不着头脑，这就是Bug所在，姑且认为窗体自动生成的代码有误，删除改行，程序正常运行：
可是，一旦对窗体的任何控件进行更改（调整窗体大小，修改窗体属性等），又会导致编译无法通过：
该Bug在DataGridView中也同样出现：
解决方法：
- 联系微软在下个版本中修正Bug；
- 不使用Name作为表格列的名称。
题外话：
微软在给我们带来便利的同时，也带给我们很多的麻烦：）
---------------------------------------------------------------------------------------------------------------------------------------------------------------
补充：
有些朋友觉得这不是Bug，觉得不符合设计预期的不是Bug，那么，如果设计本身就有问题呢？
我们再来一个实验，我们把刚才那个窗体的Name属性，改为Name：
运行程序，一切正常：
好，我们把名字改回来，再把DataGridView的属性，改为Name，编译，报错了：
好，同样都是Windows控件，在同样的地方设置属性，一个能用，一个不能用，你说这不是设计上的问题？不是Bug吗？
——“这有两根金条，你告诉我，哪根是高尚的？哪根是龌龊的？”
P.S.
感谢Build_Werther提供的情况，这回，我们在相同的地方，把窗体的Name设置成为Program，编译后这回他报错了：
同理，我们把DataGridView命名为Program，编译、运行，却又一切正常：
园子里有很多“大神”指出了问题的原因，那么，指出了问题的原因，就能否表明他不是个Bug呢？留给诸位思考。
.net工作札记系列：
[工作札记]02: .Net Winform控件TreeView最简递归绑定方法
[工作札记]03: 微软Winform窗体中设计上的Bug，会导致程序编译失败，影响范围：到最新的.net4.7.2都有