Whether you keep the default Visual Studio AssemblyInfo.cs paradigm or the SharedInfo.cs method above, it’s just a matter of you picking and setting a new version number when you feel like it.īut now let’s see what we can do about having automatic versions. Automatic versionsīeing able to manually specify a version number is easy enough. Bonus, you can move all common assembly tags you want in your SharedInfo.cs, like Copyright, Product, etc. Now you only have one file to update your version information in, making it much more manageable. (In the “Add Existing Item…” dialog, click the arrow next to the “Add” button and choose “Add As Link”.) For all of your other projects, simply add that SharedInfo.cs as a link.Create a new file, say SharedInfo.cs in one of your projects (typically the one the builds first) and put the AssemblyVersion attribute there.Remove the AssemblyVersion attribute from AssemblyInfo.cs in all of your projects.By default, every code project in a Visual Studio solution has its own AssemblyInfo.cs, and each specifies their own version number that needs to be updated and maintained.īut there’s no reason we have to stick with that. So, what are my options? Sharing one version number The option for VS to auto-generate a build number (say for frequent builds that are released to beta testers).The option to manually specify a version number (say for infrequent builds that I release to the general public).Every assembly has the exact same version number.In no particular order, here’s what I want: I have a Visual Studio solution with multiple projects, that therefore generates multiple assemblies for my app. So how can we automate this task away? The Goal However, having to maintain version numbers manually across multiple projects can be an annoying, error-prone process, especially if you’re trying to build and release often. Having intelligible version numbers is one of the easiest ways for developers to keep track of their software in the wild.

Visual studio old versions