This project is read-only.

UpdateVersion Limitations

Mar 24, 2009 at 12:14 AM

Not sure if anyone contributes here or not, this is the first post.  I've been using this project for awhile and had some suggestions or maybe they are problems with the way I am using the tool.  Here are my observations.

1.  Latest version has a bug in the code: In VersionUpdater.cs, options.PinVersion is null throws an exception, need to wrap:

// if pin version build number is invalid
if (options.PinVersion != null)
    if (options.PinVersion.Build == -1)
        calculator.BuildNumberType = options.BuildNumberType;
        calculator.BuildNumberType = BuildNumberType.Fixed;

2. When using this utility, what is the best practice for updating a source tree.  I've looked at the samples and don't see a sample for running this with a build system.  It would be nice to use this in conjunction with MSBuild to update a group of files.   Something like this:


Set the AssemblyInfoFiles items dynamically -->
CreateItem Include="$(SolutionRoot)\**\$(AssemblyInfoSpec)">
Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
Exec WorkingDirectory="$(SolutionRoot)\Sage" Command="UpdateVersion.exe -b $(AssemblyInfoFiles)" />




This would allow the developer a way to update all the AssemblyInfo files in a directory Hierarchy in one fell swoop.  The only alternative to this that I see is having to run Pre-Build Events like:

"$(OutDir)UpdateVersion.exe" -p -b BuildDay -r Fixed -v Assembly -i $(ProjectDir)Properties\AssemblyInfo.cs -o $(ProjectDir)Properties\AssemblyInfox.cs
"$(OutDir)UpdateVersion.exe" -p -b BuildDay -r Fixed -v File -i $(ProjectDir)Properties\AssemblyInfox.cs -o $(ProjectDir)Properties\AssemblyInfo.cs

I don't see a way around calling this twice as the Input can't be the same as the Output.  Wouldn't this be the normal use case however, to simply Update the AssemblyInfo files?

Oct 26, 2009 at 7:01 AM

I have admittedly neglected this project, but it's one of those things that doesn't usually require much care and feeding... well, when it's correct ;-)

I just corrected the null reference error. That one's my fault for only testing pinned versions. This speaks to the fact that the entire code base should really have some testing done. At the time I first started using it, I didn't do too much automated testing. Right now, I just don't have the time to invest. I'd love it if someone else could donate some time, tho. The biggest pain point is the dependency on System.Console. The entire solution needs some DI/IoC love.

UpdateVersion was initially built as a command line utility so it could be called from anywhere (i.e. Visual Studio, make file, Nant). Based on this, we've stayed out of providing custom guidance for different systems. I do believe MSBuild is big enough to warrant its own guidance, tho. Unfortunately, I'm not too familiar with it -- and have no interest in it. I've replaced XML-based build tools with PowerShell scripts that are much more powerful. If someone would be interested in providing the code for a custom MSBuild action, I'd gladly include that in the source. With that said, I've seen both MSBuild Exec actions and post-build events. It really just depends on what you're most comfortable with.

I will say we should probably add the ability to update both assembly and file versions. Seven years ago, when the tool was created, not too many people used both assembly and file versions. Heck, I don't think most people even realize what the differences are. If anyone has ideas on how to improve this and/or wants to submit patches, please let me know!

Thanks for getting in touch. Sorry for the delay in responding.

Oct 26, 2009 at 7:03 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.