How to make successive version of a project in Microsoft Visual Studio 2010

Question

Maybe I just can't figure out the right keywords to get an answer out of Google, but here goes.

Say I have a Project I'm working on named "Project." For it's first version, I have it stored in the folder "Project_Version1", and have the name of it's solution, project, build exe, etc as "Project_Version1".

Now I want to make the next version of the Project, and call it "Project_Version2". To do this currently, I copy the original folder, and rename it to "Project_Version2", and I want to rename all of the other internal stuff to that as well. Currently, I have to do that with a combination of changing the names in windows explorer, and some of the various properties pages in my solution.

There has to be a better way to do this. How does somebody make a second version of their project, and store it's files separately from the first version? Is there a way to also rename appropriate files that contain version numbers?

Answer 1

You can do some pretty neat tricks with MSBuild. Let's say, for instance, that this is your project.

Program.cs:

namespace MyCustomBuild
{
    class Program
    {
        static void Main(string[] args)
        {
            System.Console.WriteLine("Hello World");
        }
    }
}

Create your MSBuild file as shown. build.msbuild:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <MajorVersion>1</MajorVersion>
    <MinorVersion>0</MinorVersion>
  </PropertyGroup>

  <Target Name="Default">

    <CombinePath BasePath="$(MSBuildProjectDirectory)"
                 Paths="Program.$(MajorVersion).$(MinorVersion)">
      <Output TaskParameter="CombinedPaths" PropertyName="OutputDir"/>
    </CombinePath>

    <MakeDir Directories="$(OutputDir)"/>

    <Csc Sources="program.cs" 
         OutputAssembly="$(OutputDir)\Program.$(MajorVersion).$(MinorVersion).exe"/>

  </Target>

</Project>

After running msbuild build.msbuild, this is the result:

Ways to make what I posted even better:

1. Use the MSBuild Extension Pack AssemblyInfo. This will allow you to change the version info if you have it defined inside an AssemblyInfo.cs file. Or you can look into the GenerateApplicationManifest Task, which can set assembly versions, but as of right now the file version of the executable will always be 1.0.0.0
2. Implement some sort of autoincrement system like this one
3. You can copy all your source files into the versioned directory using the Copy Task

It's a lot to take in, especially if you aren't familiar with MSBuild, but it's a powerful program that allows customization that Visual Studio can't even imagine! Note that a solution file (.sln) is a MSBuild file, even though it's not xml.

Hopefully this is what you are looking for. I do also recommend that you use an official version control, as others have mentioned, but you seemed to have a specific task you wanted automated, which is MSBuild's forte.

Answer 2

Indeed, there is a better way to do this, it is called version control.
If you check your source into TFS (or git or any other SCM software) all versions will be tracked over time.

If you then need to maintain multiple versions simultaneously (e.g. for a customer base where customers slowly migrate to the bleeding edge and patches are required to fix critical issues in older, supported versions) you can keep these versions as branches and selectively merge changes.

If you do decide source control is a good fit for managing your versions (It brings a lot of other benefits as well), consider reading some posts such as this git tutorial or why use version control.

---

If you REALLY can't use source control, for some reason, I suggest trying to reference as much as you can using language constructs which can be easily changed (e.g. with C# and a reasonable IDE, a quick refactor, or with other languages some rigorous de-duplication of version-specific data).
Ideally you would have just one definition of the version for your code along with a version definition in the project files (which could be set as a build variable to change quickly).

In this case you would copy the project, change the code version and the version variable for the project and, assuming good use of relative paths etc. (no hardcoded versions!), a quick rename of a couple of variables should get you going.

Ideally, the bulk of of the file-names would not reference the version. The only thing referencing the version should probably be the containing directory, the project/solution files and a few isolated references in your code.

Answer 3

Ideally, versioning your project should be done within a source control system since Visual Studio in and of itself is just an IDE.

In the situation of not using a source control system, unfortunately I'm not aware of a better solution than what you are doing currently.