Programs | control when developing ASP.NET applications, you can encapsulate code into a variety of classes that handle the appropriate actions, depending on the specific needs and design of the application being developed. and to organize and manage the existing code. This creates a lot of assemblies in the ASP.net application (that is, compiled DLL files).
In these assemblies, many encapsulation of the underlying code, which does not involve the application's transaction logic, can be reused in a variety of applications (code reuse). For example, the encapsulation of a variety of common database operations, which forms a class specifically for database operations, can be used in all applications that require a database. There is also a problem with this, which may make some changes to the class in a variety of applications, so that as the number of assemblies increases and the number of modifications is increased, there is a lot of trouble with the version issue. Even some assemblies that are only used by an application may have different versions of it because they have been modified, resulting in the same version of the problem. In the ordinary development of the often encountered such trouble, the mode of a piece of code is always unable to produce the expected results, wrong looking to find, and finally found that the original is used in the assembly of some code has been modified.
Some days ago, I wrote a document about the specification of the version control of the assembly, and here's some of my personal suggestions, which I hope will be of some reference value.
First, we need to have a label, version number, that identifies the different versions of the assembly. For a description of the version number in MSDN, it is recommended to use a four-part version number format. [MajorVersion.MinorVersion.BuildNumber.Revision], the specific description of these four parts is as follows: (major or minor version.) Changes made to the major or minor versions of the version number represent incompatible changes. Therefore, under this Agreement, version 2.0.0.0 is considered incompatible with the 1.0.0.0 version. Change the type of some method parameters, or the entire removal of a type or method is an incompatible change. Internal version. The build number is typically used to differentiate the daily version or to change a smaller compatible version. Revision number. Revision number changes are usually reserved for the incremental compilation required to fix a particular error. Sometimes you will hear it called the "emergency Bug fix" number, because when you send a fix to a customer for a particular error, the change is usually the revision number. The above brackets are partially excerpted from MSDN. Of course, you can make appropriate adjustments to the format of the version number, depending on your actual needs. The version number that I use is in the following format: [Major version number.] Minor version number. program compile time. The number of revisions, where the major version is used to identify a larger change, the minor version number is used to identify a minor change, and the compile time identifies the time that the Assembly was compiled and archived, and the number of modifications used to identify the assembly was modified several times.
[Not finished]
The lower half will focus on two scenarios that implement version control.
