Global Settings (set once and forget)

Aug 15, 2009 at 5:50 PM
Edited Aug 16, 2009 at 4:32 PM

This is an awesome product. The only thing I found that works. Great job!

I am new to this product; perhaps there is already a way to do this...

I am looking for a "universal" configuration, so that it won't be necessary for me enable build number incrementing for all my many projects, next time I open any of them. Frankly, I'm afraid I will forget to do it to every solution or project I open.

I'm a single developer, not on a team, and it would be neat if this add-in could increment every project I ever work on without having to specify settings for each solution.


I can see how this can be implemented relatively cleanly...

The global default settings feature could be accomplished by adding a node in the treeview above the solution node (the parent of the solution node, in other words the root), which represents "all solutions". The solution or project settings would (could) over-ride this global default setting, if their "Update Assembly Version" or "Update File Version" properties were True.

It looks like you are already evaluating an enumeration to configure when, or under what conditions, to increment the Assembly or File versions. In your evaluation of this new feature, if you decide some projects may need to never increment (regardless of the global default's value), the Boolean data type of the"Update Assembly Version" or "Update File Version" properties could become an enumeration with values "Always" (old True value), "Never" (old False value) and "Inherit" (or "Use Parent Setting"). The default value of these properties on never-before configured projects /  solutions would need to be "Use Parent Setting" in order for this feature to work for my request here; otherwise, I'm back where I started.

And of course the default global setting would be False (or Never) on both properties, so it would behave by default as it does today,

and be backwards compatible.

Thus, the fine-grain control ability is maintained, but for one-man shows like me, one can set once and forget... :)


Jan 29, 2010 at 1:56 PM
Edited Jan 29, 2010 at 4:58 PM

I very much appreciate the addition of global settings!
It saves me time in setting up settings for new projects.
I am honored that my request made it into the project!
I also think that you implemented it neatly, considering all the other considerations you had from other users.
I do understand why you did it the way you did. 




However, I am still trying to set one time and forget, b/c I am forgetful. Due to the "Use Global Settings" on each project defaulting to "False", if I forget to change this on a new or yet to be configured project, I will not get my preferred settings enforced. I wish that forgetfulness was not part of the equation, but unfortunately with me it is. lol.



Under the Global Settings node,
perhaps you could add a new property called "Use These Settings"
with a type of enumeration (Always/Initially/OnlyWhenChosen)
with a default value of "OnlyWhenChosen".
Other people could leave it alone and it would be 100% backwards compatible for them.
I could change it to "Always", and let it remember for me, for all new and existing projects / solutions I have, whether they are previously configured or not.

  • "OnlyWhenChosen" - leaves "Use Global Settings" property on each project alone
  • "Always" - changes "Use Global Settings" property on each project to true. If they set it to False within the project, it stays set on True.
  • "Initially" - initializes the "Use Global Settings" property on each new or yet to be configured project to true, but leaves it alone after that


If you do this, I would also recommend beefing up the help text for the "Use Global Settings" project property to include something like "This property stays True if the "Use These Settings" property of Global Settings is set to "Always".


Again, many thanks to you for this addin, and for considering my feedback.
That was way cool to see that Global Settings in there.
What an ego trip! haha. :)

Jan 31, 2010 at 8:39 PM
Edited Jan 31, 2010 at 8:53 PM

Hi Robert,

Thank you for taking the time to answer my request!
My apologies in advance for the long answer here.
Well, my goal has always been to set up my add-in one time, and then not ever have to go into the add-in again.
Ultimately, my only request was the ability to do this, and how that gets accomplished was not my concern,
but I was trying to be helpful by suggesting a way.
Since you have added the "Use Global Settings" boolean at the project/solution level,
which refers to global settings, 
any setting on the global node that speaks about when global settings apply to projects could be inconsistent
if it said "Always" and the project "Use Global Setting" remained "False".
I was saying "Always" would override any project's "Use Global Settings" false value and make it True,
simply to keep the two settings logically consistent and in sync, and to prevent that confusion which you speak of.
I admit, it would be confusing for a short moment if someone set it to "Always" globally,
then went into a project and tried to say "Use Global Settings"=> False,
only to see that it was stuck on true. But I think that confusion would go away quickly.
That stuck on true behavior would help teach them what that global setting "Always" does,
and if the help text for the "Use Global Settings" project property was expanded to explain that behavior,
that help text ought to be where this user would look first to explain the unexpected behavior, 
and they would realize they need go into Global node to set it to something besides "Always".
The "Use These Settings" help text could also spell out what each enum value does.
You could also add a label to the bottom of the dialog box that is visible when global settings are in effect.
That label could say "Using Global Settings". It could be colored to draw attention.
This situation would not happen by default, but only for users that went in and set it to "Always"
and did not understand at first what they were doing, since "OnlyWhenChosen" would be the default.
Also, they would have to ignore the help text and documentation to be confused.
Understand that I am not saying I would like to see the project's other property values get over-riden.
By coding it the way you coded global settings,
what you did (whether you intended to or not) was give the ability to 
temporarily use global settings and then revert back to the specific project settings.
I consider that a feature.
The only project property value that would change as a result of "Always" would be "Use Global Settings".
The add-in would keep remembering the specific individual settings of each project as it does today.
You said:
"If you're importing projects, you'll have to set it one time to true and forget afterwards."
Unfortunately, my forgetfulness is not at the project level, but at the global level.
I merely forget the add-in is there, and that I need to apply it to each new or yet to be configured project.
I have forgotten to do this many, many times since I downloaded it in August 2009.
I have 100s of projects. It's only a great tool if I remember to use it.
My strength is creativity and logic in the present moment, not memory of any routine thing.
Memory is my weakness.
If all you end up being able or willing to do is "OnlyWhenChosen" and "Initially", I will set it to "Initially".
In that case I ask that you use any internal function you have which determines
if the project has been incorporated yet into your add-in,
and if not, consider that also a project to "Initially" configure (I'm talking about the "not yet configured" projects),
in addition to the new ones.
In that case, a boolean would do.
However, note that if you make it an enumeration, it won't cost you anything, 
and you give yourself the flexibility to expand later,
if you ever dream up another value you could make use of.
Many times in my projects, I have left room for expansion when I thought I would not need to,
and then ended up needing to. It seems change is the only thing that doesn't change. :)
A property name of "Use These Settings" leaves it open to multiple values;
a property name of "Use global settings as default" seals it as a boolean, 
as this property name actually contains the property value in the property name ("Use global settings as default"),
and merely asks whether or not they want that value.
But anyway, I think now you understand at least where I'm coming from,
and I'll benefit from whatever you do.
My emotion has been, is and will continue to be just gratitude.
And you should have seen my 12 year old son's eyes when I showed him 
how you put my request into your project!
You helped me show him that he can make a difference in the world if he tries to be helpful.
Have a wonderful day,
Jan 31, 2010 at 8:50 PM
Edited Jan 31, 2010 at 8:51 PM

I had an after thought:

If you have the "Always" value,
and they try to set the "Use Global Settings" project property to "False",
you could throw a new ArgumentException with a message something like "Can't set Use Global Settings to false when Global Settings "Use These Settings" value is always" and make the message as helpful as possible.
What this does is make the property grid throw up a dialog box containing the error message
that can be used as more help text.
This might be more clear and less confusing or frustrating than if the property grid merely ignored them.
Feb 1, 2010 at 8:42 PM
Sounds good.
I am not yet familiar with the difference between "Set As Default" and "Copy As Default",
but I am sure that will become clear.
I, of course, will be using Enforce. Thanks in advance!

I do hope I'm not the only one that would be helped by this feature.
It seems logical for a small one-man show like me,
but sometimes my logic is not in sync with the rest of the world.
I appreciate all the thought you are putting into it.
Mar 8, 2010 at 9:09 PM
Thank you very much.

I tested build v2.2.10065.1524 in vs2005
and this feature works when
  • Launching a program with the Debug menu, Start Debugging or Step Into commands
  • Building a project seperately
It does not increment the build number with the Build menu, Build Solution command.
Jan 24, 2012 at 3:38 PM

I just re-installed version 2.4.11046.2045 (Beta) at a new job,

and I just wanted to thank you again for all your efforts.

I'm still using this, and the global settings really help a lot.

Now, if I could just figure out how to use SVN without making a big mess... lol.

May 15, 2012 at 6:05 PM

I basically had to stop using the addin but I think it may not be a problem with the addin, but rather visual studio.

I have a solution with 29 projects and complex dependencies between them, some multi-levels deep.

I got strange errors when the build numbers got out of sync.

Has anyone dealt with visual studio errors (of any kind whatsoever) b/c the build numbers got out of sync?

If so how did you fix it, or is there a work around?

I don't remember the specific error and I'm too scared to turn the addin on (it was a mess fixing it the last time),

but I seem to recall the nature of the problem was that it was 1 build number behind on some projects and due to the complex web of dependencies,

multiple versions of the same dependent project were being referenced in from different sources.

After all that trouble to get this feature working, all my projects are at version


I'm not blaming, I just may be doing something wrong.