Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞
When developing ASP. NET applications, you can encapsulate the code into various classes that process the corresponding operations according to the specific requirements and design of the developed applications. To organize and manage existing code. This forms a lot of assembly in ASP. NET applications (that is, DLL files formed after compilation ).
In these sets, many encapsulation of the underlying code does not involve the Transaction logic of the application, so it can be repeatedly applied in various applications (code reuse ). For example, to encapsulate various common database operations and form a class specifically used for database operations, this class can be used in all database applications. There is also a problem that may make some changes to this class in different applications. As the number of assembly increases and the number of modifications increases, this will cause a lot of trouble in version issues. Even an assembly that is only used by an application may have different versions due to modifications, resulting in the same version. This problem is often encountered during normal development. The adjustment of a piece of code cannot produce the expected results, and errors can be found, finally, we found that some code in the original assembly was modified.
Some days ago, I wrote a document on the specification for version control of the Assembly. Here I will talk about some of my personal suggestions and hope to have some reference value.
First, we need a label and version number used to identify different versions of the Assembly. In the description of the version number in MSDN, a version number format consisting of four parts is recommended. [MajorVersion. MinorVersion. BuildNumber. Revision. Changes made to the primary or secondary version of the version number indicate incompatible changes. Therefore, version 184.108.40.206 is considered incompatible with version 220.127.116.11. Changing the type of some method parameters or removing a type or method is incompatible. Internal version. The internal version number is usually used to distinguish between daily versions or compatible versions with minor changes. Revision No. Revision number changes are usually reserved for incremental compilation required to fix a specific error. Sometimes, you will hear it called the "urgent error Fix", because when it is sent to the customer for fixing a specific error, the change is usually a revision number .) Part of the brackets above is taken from MSDN. Of course, you can adjust the format of the version number based on your actual needs. The version number format I used is: [main version number. minor version number. program compilation time. number of changes]. The main version number is used to identify major changes, the minor version number is used to identify minor changes, and the compilation time is used to identify the time when the assembly is compiled and archived, the number of modifications is used to identify the number of modifications to the assembly.
The lower part mainly describes two solutions for version control.
This article is an English version of an article which is originally in the Chinese language on aliyun.com and is provided for information purposes only. This website makes no representation or warranty of any kind, either expressed or implied, as to the accuracy, completeness ownership or
reliability of the article or any translations thereof. If you have any concerns or complaints relating to the article, please send an email, providing a detailed description of the concern or
complaint, to email@example.com. A staff member will contact you within 5 working days. Once verified, infringing content will be removed immediately.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
and provide relevant evidence. A staff member will contact you within 5 working days.