Issue with action "Build VS.NET solution" and updating the AssemblyInfo.cs with new versioninfo

FinalBuilder Discussion
1

After creating a simple build script (Attached) which essentially does the following

1) Create a Property Set containing .NET Assembly VersionInfo (reading the version from a SolutionInfo.cs file which contains just the current assembly: AssemblyVersion("1.0.0.0")] to allow for reading it easily by FinalBuilder. SolutionInfo.cs is only used to ensure that all projects in the solution will get the same version number..

2) Assign it in the ".NET Version" tab in the "Build VS.Net Solution" action

According to a snip of the log in Team Foundation Server I can observe that the minor version of the property set is correctly incremented to 1, and it also looks like the "Build VS.NET Solution" action has detected that product version should be updated. 

[Load [VersionNumber] into [SolutionVersionInfo Property Set]]
      Scanning AssemblyInfo file C:\Build\DAS_Sandkasse\7\TFS2012 Finalbuilder Tests\FinalBuilderTests\Sources\SolutionInfo.cs
      Processing AssemblyInfo File : C:\Build\DAS_Sandkasse\7\TFS2012 Finalbuilder Tests\FinalBuilderTests\Sources\SolutionInfo.cs
      Assigning values to PropertySet SolutionVersionInfo
      Setting MajorVersion to "1"
      Setting MinorVersion to "0"
      Setting BuildVersion to "0"
      Setting RevisionVersion to "0"
    [PropertySet [ SolutionVersionInfo ] increment [ MinorVersion ]]
      Property MinorVersion is now 1
    [TFS build]
    [Build VS.Net Solution [ C:\TfsBuildDoWork\DAS_Sandkasse\7\TFS2012 Finalbuilder Tests\FinalBuilderTests\Sources\FinalBuilderTests.sln ]]
        ActionComment = 
        AllowUnsafe = False
        AllWarningsAsErrors = False
        AutoUpdateFileVersion = True
        AutoUpdateProductVersion = True

But when I examine the output in the dropfolder (which is just a simple WPF test app), the assembly version is still 1.0.0.0, which is the value in the assemblyinfo that was checked in.
To ensure that it was not my handling of the property set, I set the minor version, so it should always be 1, directly in the ":NET Version" tab, but the compile executable still has the assembly
version 1.0.0.0.

*) Do you have any idea what I might be doing wrong here?
*) Is the stuff specified in ".NET Version" supposed to be written to disk as well or how should it be communicated to the actual MSBuild invocation.


--------------------------------------------------------------------------

Furthermore, 

*) Do you have any procedure/best practice for maintaining the current version number in SourceControl.

The requirement is to have 2 TFS Build definitions
  - Increment Major Version and prepare solution for deployment
  - Increment Minor Version and prepare solution for deployment

These builds will be triggered manually.

My initial idea was to add the following actions

   - Check out SolutionInfo
   - According to custom argument passed from TFS build definition to FinalBuilder decide whether Major or Minor Version should be updated
   - Create propertyset and update the  

   - Write SolutionInfo to disc again and check it into Source Control
   - Trigger the build

Is this a feasible approach or is there another approach which would make more sense to use?


2

Hi Henning

Try changing the propertyset type to .NET AssemblyInfo, that will allow it to load the AssemblyFileversion info as well. As for storing the the value of the version info, I do not have a recommendation for how to do this with TFS. We don’t use TFS here and we’re not TFS experts (it would be safe to say we dislike TFS a lot, nothing is ever easy with it).

3

Hi Vince,

Thanks for you answer. I tried changing the type of the propertyset, but that did not fix the problem. So I am wondering if could clarify how the version-number is passed from the action "Build VS.Net Solution" and to the actual call to the MSbuild. I would expect it to be set as a command-line option to Msbuil, but inspecting the executed commandline from the log:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe with parameters : /t:Build /nr:false /logger:FinalBuilderLogger,"C:\Program Files (x86)\FinalBuilder 7\FinalBuilder.MSBuild.Logging.v4.0.dll" /noconlog /p:Configuration="Debug";Platform="Any CPU";OutDir="C:\TfsBuildDoWork\DAS_Sandkasse\7\TFS2012 Finalbuilder Tests\FinalBuilderTests\Sources\Binaries\\" /v:normal /m "C:\TfsBuildDoWork\DAS_Sandkasse\7\TFS2012 Finalbuilder Tests\FinalBuilderTests\Sources\FinalBuilderTests.sln" 

shows that it is not passed. 

I would expect checking the checkmark in "Update Assembly Info for .NET projects" in the "Build VS.Net solution" and then using the property set previously mentioned - which the log reveals is correctly created and updated in both cases - would add a "/p:VersionNumber=" (or something like that) to the parameter list.

I am running FinalBuilder (FB700_2176) and know this is not a final build. Might this have something to do with the missing versionnumber argument?

---

The question for a best practice has really nothing to do with TFS. What I meant to ask for is if there is any known best practices on using FinalBuilder in combination with any checkin-checkout VCS (SourceControl, Perforce, etc) to automatically manage the versionnumber using the VCS as persistent storage for the current version number.


4

MSBuild does not do anything whatsoever with version numbering. It just compiles your code, the version numbering comes from the assembly info attributes you provide in your code. I think the step you are missing is updating the SolutionInfo.cs file, use the Assembly Info Updater action.

I don’t believe there really is a best practice, whatever works for you is fine. There are so many ways to do things. We have our version info in an ini file, which we read at the start of the build, and update and commit at end of the build (this is on FinalBuilder Server, on Continua CI we let it deal with version numbers). Subversion users often use the commit revision number as the build number.