Assembly version control [up]

Source: Internet
Author: User
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 2.0.0.0 is considered incompatible with version 1.0.0.0. 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.
[Unfinished]
The lower part mainly describes two solutions for version control.


Related Article

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

Contact Us

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: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.