In the .NET projects, there are some different source file types though they have the same source file extensions such as .CS or .VB.
I would group them into two big categories, auto-generated and programmer-created. The latter is pretty straightforward and easy to understand. Let us focus on the former.
The auto-generated sources can have a few different types again. The first type is the AssemblyInfo source that was introduced in much detail in many early articles. As far as the C#, VB.NET and C++ projects are concerned, the auto-generated AssemblyInfo source file is a must; otherwise, or even with a tiny issue in the file, the project won’t compile. This kind of source files is not the concern of the Source Information Header at all, obviously.
The auto-generated sources include many designer source files as well. Here are a few examples.
Whenever we create a WinForm (including the AboutBox) in a C# project using the Form template provided by the Visual Studio, a designer file like FormX.Designer.cs will be added into the project along with the form class, FormX.cs here. The form designer file is created and maintained automatically by the Visual Studio IDE, templates, and wizards, so programmers are not supposed to touch on it though sometimes it is still necessary and the only easy way. So apparently, this kind of source file is not the concern of the Source Information Header either.
The same will happen to Settings generation. A designer file like SettingsX.Designer.cs will always be generated automatically when a Settings item is added into a C# project. This time, it is clearly stated at the top of the designer source that we should not touch on it at all:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.5448
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
So this kind of files (though they have the same .cs extensions as other source files in C# projects) is not the concern of Source Information Header either.
One more example is the Installer class. Something like InstallerX.Designer.cs will always be generated automatically into a C# project if the Installer item wizard/template is used, and is not supposed to be edited by programmers directly either. So The Source Information Header should not take this kind of source files into account either.
Fortunately, all these designer source files follow the same naming pattern like XYZ.Designer.Ext in which the XYZ indicates the item type like Form, Settings or Installer and the Ext source file extension such as CS, VB or CPP.
Another kind of auto-generated source files may be those code-behind sources for XMAL and they follow another naming pattern like WPFWindowOrControl.xmal.cs for C# XMAL definitions, but these XMAL source files are different from the above designer ones as obviously programmers have to manipulate many of such files quite often such as adding some more initialization code and implementing some event callbacks and Visual Studio does not likely override the custom code as it does to those SettingsX.Designer.cs as mentioned earlier. So the XML code-behind files are not the concern of Source Information Header either.
If readers observed any other types of auto-generated sources that were not covered above or followed some different naming patterns, please feel free to point out.
SourceHeader Updater of RevitAddinWidget can review source information headers of all applicable source files in the current project of C#, VB.NET or C++ and update the headers conveniently and flexibly in a single central place.
Recent Comments