There is no automatic (built-in) way to do this. A possible workaround, which I use in my projects is to generate publish and assembly version information using a custom msbuild task.
Some projects available as nuget packages aim to solve these issues, but there's nothing very complete out there. Take a look at SemVerHarvester and CroMagVersion ...
Both the above have many issues:
- SemVerHarvester is tied into git/hg and sources version information from a git tag
- It does not actually write a AssemblyInfo.cs file by itself, but relies on the Msbuild Community Tasks
- The AssemblyInfo.cs file is always 'touched' which means each rebuild is a full rebuild rather than an incremental rebuild. CroMagVersion gets around this partially - it defines a #define in release builds and will regenerate an AssemblyInfo.cs only if this define is present...
- Neither project directly sets the ApplicationVersion/ApplicationRevision properties used by the ClickOnce system for publishing
I've got workarounds for all of the above, which I intend to open-source on github soon...in the meantime I'll descibe what I've done:
I made a custom msbuild task, that reads version information from git, then creates an in-memory AssemblyInfo file based on this information. I check the existing AssemblyInfo.cs file (i.e. a file which has AssemblyVersion and other attributes) and overwrite it if and only if the in-memory version is newer. This allows for incremental rebuilds. Lastly I also output ApplicationVersion, ApplicationRevision and other properties to support ClickOnce.
If I were to opensource my workarounds as a stand-alone solution, I'd probably allow for version information to be sourced from a text file, git, hg etc
Issues I still have not found good solutions to:
ClickOnce does not directly support multiple release channels - like debug/beta/custom_feature/whatever which makes me wonder whether I should ditch clickonce and use Shimmer instead.