Take the tour ×

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?

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

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


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

Create your MSBuild file as shown. build.msbuild:



  <Target Name="Default">

    <CombinePath BasePath="$(MSBuildProjectDirectory)"
      <Output TaskParameter="CombinedPaths" PropertyName="OutputDir"/>

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

    <Csc Sources="program.cs" 



After running msbuild build.msbuild, this is the result: enter image description here

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
  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.

share|improve this answer
I think this might be what I need, but it will take a bit to fully understand what is going on. I do use version control (currently a local repository of tortoiseSVN), but I have mostly used it for having the ability to roll back when errors occur or functionality breaks or something like that, not for official versioning. Or am I mixing up version control and source control there? The scheme I'm asking about was mostly to break off and store versions that have been officially released into the wild, while I use the source control for the programming between released versions. –  Xantham Jun 13 '12 at 16:00
As you describe it, MSBuild does fulfill what you desire, so I would take advantage of it. MSBuild and git (or other similar software) can definitely co-exist. –  Nick Babcock Jun 13 '12 at 17:26
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer


