Directory.build.props file improvements

[AlexUstinov]

This PR enables usage of the build number version component for custom versioning.
Also, the file is reorganized for simplicity.

[alex-kulakov]

This changes packages versioning globally. I don't really like it.

It is said that this is done for custom functionality but it is applied for our build server building process.
Old versioning set build number on build server, otherwise 0. Build number was also ignored for NuGet package version.

Custom versioning seems to be not really custom.

I assume you need build number to differentiate private packages between our public releases. Can we use something like following:

• If $(BUILD_NUMBER) is not empty the building is considered to happen on a build server. In this case do not include build number to the package version.
• if $(DoVersion) in Version.props contains build number then use it for assembly version and for package version. Consider this as custom build.
• If none of previous items haven't set then build number is 0 an package version does not contain build number. This is usual build which is built on, for instance, developer machine.

Any problems for you in case of such algorithm?

As an option the build number from $(DoVersion) in Version.props can override everything (it will be placed as package version automatically), if it does not exist we use $(BUILD_NUMBER), then 0. Last two variants should have no effect on package version.

[AlexUstinov]

I decided to always use the $(DoVersion) value as the Package Version. It is also being used as the Assembly File Version but in case the $(DoVersion) value lacks the revision component it is being complemented with 0. However, in case, the $(BUILD_NUMBER) parameter is defined it always overrides the revision component of the Assembly File Version.

This must keep the current behavior but could allow extending the package version with the Revision component when needed.

[alex-kulakov]

Yes, such algorithm keeps current behavior for us.