A few suggestions

May 6, 2009 at 6:43 PM
I just found this add-in and I must say it has some really cool features.

I do however have a few things that I think would make it even better :)

First of all, when comparing to visual studios own version incrementer I noticed one thing. When having multiple projects in a solution where the projects depend on one "master" project, the master version is only updated when the master project has actually changed. That means that you can change and build files in all the other projects without changing the master version, because VS doesn't build the master project unless something has changed. I don't know if it's even possible to check this from an add-in, but it would be great to have this kind of detection in this add-in also :)

I also think it would be cool to be able to specify different increment styles for each configuration name. This way one could for example set "debug" to increment the revision number and "release" to increment the build number.

Anyway, thanks for a great add-in and keep up the good work!
Jul 23, 2009 at 3:10 PM

I would like to add a 2nd vote for styles for each configuration: one for debug to update the revision # and one for release to update the build number.

I was going to post the same suggestion; but, first I clicked through some of the existing and found that someone beat me to it!

Pete

Sep 30, 2009 at 1:42 PM

3rd vote for adding different types of increments on different configuration types. I'd love to be able to increment revisions on Release/Update and increment minor when on Deploy. I'm looking at the source code but I have no idea how Visual Studio addins work.

Dec 18, 2009 at 9:15 AM

Add my vote to this. Also the ability to increment the build version and reset the revision to 0 when I do a Release build.

Feb 15, 2010 at 2:34 PM

Hello all!

I'm very much interested in a solution for the problem with not changed projects, but which are still incremented. I would expect to have this functionality with setting "Increment Before Build" to False, but I suppose that I haven't understood the meaning of this setting perfectly. Do you have any news?

Anyway all issues mentioned in this discussion are exactly what I'm missing to use this tool in my project in an easy and automatic manner, so I hardly wait to get a feedback.

Thank you!

Ioana

Coordinator
Feb 15, 2010 at 4:34 PM

I've probably spend days to figure out a way to detect if Visual Studio is about to (re)compile a project or use the last output since when there are no changes. Either it's buried deep inside (Visual Studio documentation isn't that good) or it's simple not possible via Visual Studio. The only way I know that will work is by either check all files on access time every time a build is started or by hooking in on every code change that occurs (like a source control addin) and mark a project as modified. Both methods will turn this lightweight addin to something pretty heavy.

The recommended settings is only incrementing on a Release build (when you're shipping) since it doesn't has much use to keep track of versions on debug versions.

The "Increment Before Build" setting allows you to increment versions before or after the compile action but has nothing to do with detecting changes in projects.

The 2.2 version (I hope we will have a beta soon) will contain an option where you can execute the increment manually (solution or at project level). This allows you to always increment when a certain configuration build is selected (eg Release) and perform increments on other builds when you desire.

With a little luck vs2010 has beter support for detecting modifications.

Hope this helps.