Conditional set of .NET assembly version?

[zimbo]

I'm currently evaluating VisBuildPro and am very close to purchasing it. There's one thing left to figure out how to do.

I have a nightly build with an incrementing build number. I would like the assemblies that were rebuilt during the build to be stamped with the build number. Using the "Set the project version to a specific value" option on the Versions tab of the Make VS.NET step, I'm able to do that.

However, I only want to stamp the build number on an assembly that actually had changes made to it. In other words, for assemblies that are already up-to-date (no source code changes since last build), I don't want to update the build number.

So, what I need is the conditional functionality of the "Increment the version if the target executable timestamp changes" option but the ability of the "Set the project version" to set the version to a specific number rather than simply incrementing it.

How would I do this, keeping in mind that I'm building several solution (.sln) files each of which contains several project (.csproj) files?

Thanks,

--Steve Zimmerman

[kinook]

Unfortunately, we've found that the 'incremental build' option in VS.NET is really a misnomer, at least for anything except VC.NET projects. C# and VB.NET projects have an incremental build option, but even if checked, once a solution is closed and reopened after building (or built from the command-line), even if no source code changes were made, it will always rebuild the project (or at least regenerate the executable) when built again. If this weren't the case, then the 'increment version' option in the Make VS.NET action would do what you want, since it does compare the project's executable timestamp before and after building. I haven't seen any explanation from MS regarding this missing functionality, and I'm surprised that more people haven't complained about it.

We don't have any plans to implement true incremental build capabilities for VS.NET projects ourselves. First of all, for a true incremental build, projects whose source hasn't changed would have to be explicitly excluded from being built (so that the executable timestamp did not change), and this would be difficult to achieve within the existing VS.NET solution/project build mechanism. And to support the general case, it's not as simple as just comparing each project executable's timestamp with the source files mentioned in the project file (things like references, COM Interop, custom build steps, etc. would also need to be taken into consideration).

There are indications that this problem may be rectified in the next release of VS.NET, code-named Whidbey (via a new make tool called MSBuild which will ostensibly replace the existing black-box make functionality). Until then, you may want to consider being content with using the increment option even though all project executables will get regenerated and the version incremented on each build. You could selectively increment versions only on "official" builds to mitigate the impact (see 'field overrides' in the help index and the Master.bld/VisBuildPro.bld sample for how this can be done conditionally).

If this is really important to you and your projects are simple enough that just comparing the project file info will be adequate, here is one approach you could take:

1) Create a script function (i.e., ParseSolution) to parse a .sln file for its constituent .csproj files and store in a delimited temporary macro (using the vbld_AddDelimValue system script function).
2) Create a function (i.e., ProjectOutOfDate) that parses a .csproj file for its source files + the target executable for a given configuration, and compares the timestamp of each source file to the executable (if found). The vbld_FileOutOfDate system script function could help here.
3) Create a project or global subroutine with these steps:
3a) A Run Script step to call ParseSolution on the .sln file and store its .csproj filenames in a temporary macro.
3b) A repeating step loop to iterate over the filenames in the temporary macro (see the 'Repeat for file contents' section of the Misc.bld sample).
3c) Within the loop, a Group step with a build rule to build only if ProjectOutOfDate(next csproj file) is true.
3d) Indented below the Group step
3d1) A Get VS.NET Get Version step to retrieve the project's current version.
3d2) A Make VS.NET action, marked to not build and to set the version to the current version value incremented by one (see this thread for sample code to increment a period-delimited version field http://www.kinook.com/Forum/showthread.php?threadid=217).
3c) Following the loop, a Make VS.NET step to build the solution, marked to build and not set/increment versions.
4) In the main project steps, call the subroutine for each .SLN file to be built.