The VersionNumber is an Assembly property. It is the [assembly: AssemblyVersion("x.x.x.x")] attribute that is typically stored in the \Properties\AssemblyInfo.cs file of the project.
You can either edit that file directly, or you can go to:
Project (menu) -> Project Properties (menu item) -> SQLCLR (tab) -> Assembly Information... (button) -> Assembly Version (fields)
If you do not have an \Properties\AssemblyInfo.cs file yet, then entering any info into the Assembly Information popup will create that file upon clicking the OK button.
Please note that there is a bug in SQL Server that prevents the version number from being displayed in the sys.assemblies system catalog view IF the Assembly is not signed:
"version" incorrectly showing as 0.0.0.0 in sys.assemblies and ASSEMBLYPROPERTY(name, 'CLRName') for unsigned SQLCLR Assemblies
Signed Assemblies will show the correct version number in sys.assemblies. When using Object Explorer in either SQL Server Management Studio (SSMS) or Visual Studio to look at the Assembly properties, the correct version number is displayed even if the Assembly has not been signed. Still, it usually best to sign Assemblies anyway, so just sign them and you won't have any issues here (especially because MS might never fix it; I did report that bug on 2016-01-28).
In terms of auto-incrementing the version number, you can use an * in the last position to do that. For example:
[assembly: AssemblyVersion("1.2.3.*")]
or:
[assembly: AssemblyVersion("1.2.*")]
Beyond signing the Assembly, you should be aware of complications in loading the Assembly into SQL Server starting in SQL Server 2017. SQL Server 2017 introduced a new security feature ("CLR strict security", an advanced option) that is enabled by default and requires that ALL Assemblies, even those marked as SAFE, be signed with either an Asymmetric Key (i.e. strong name) or Certificate and have a Login (based on whatever was used to sign the Assembly) that has the UNSAFE ASSEMBLY permission. For details on how to make this work, with or without Visual Studio / SSDT, please see the following two posts of mine:
Please avoid the new Trusted Assemblies "feature" as it has many more flaws than benefits, not to mention it being entirely unnecessary in the first place given that existing functionality already handled the situation "Trusted Assemblies" was meant to address. For full details on that and a demo of the proper way to handle existing, unsigned Assemblies, please see: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment.
