Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created that contains attributes used to define the version of the assembly during compilation. Using assembly versions effectively enables various team members to identify deployed assemblies and helps troubleshoot problems that may occur in a particular environment (e.g. Development, Test, or Production).
When building the solution, there are two version numbers that need to be considered: the file version number and the .NET assembly version number. As part of the best practices, the AssemblyFileVersion attribute should be incremented automatically as part of the build process. It is therefore intended to uniquely identify a build. The AssemblyVersion attribute is the version that .NET uses when linking assemblies. In this blog post, we’ll learn how to use the build process to auto specify the AssemblyFileVersion and AssemblyInformationalVersion.
We recently came across this problem. One of the developers had created a new branch in the one of the source code repositories hosted on the Visual Studio Team Services aka VSTS. Other developers were unable to see this newly created branch in their visual studio team explorer pane:
In previous blog post, we learned how to do baby steps for implementing IaaC. We learned how to use ARM templates, Git and Visual Studio to code your subnets in the Azure. Now, there is no doubt that Git has taken over the world for source code management. And while it is good for managing versions of source code, those versions and details are confined to your local machine. If someday your local machine goes kaput, its all in water. For that, you need to sync your changes to a centralized source code management system. Also having centralized source code management allows more than one person to work on the same repository.