Settings file location by version --- WHY???

[John J. Hughes II]

Ok now I guess I am supposed to save my user setting in the new setting
file. Which is placed in the users application directory under the company
name based on version number. I really truly don't understand the logic
behind this unless MS assume every other company waits half a decade to
release new software.

First of all is there some method of migrating from the last installed
version?

Second debugging is a real pain... every time I make a change to the
application it forgets all the setting and I have to start over.

The of course my customers really don't want to have to reset all their
setting every time they reinstall.

My system currently has 25 directories for setting files which unless I
manually delete them will stay forever. This seems like the same logic MS
did with registry values, I have 100s of those items, it's no wonder the
registry on so many computers is screwed up.

Could someone please explain why?

Regards,
John

[Joshua Flanagan]

I can't help you solve the root problem (where the settings file is
stored), but I can help you make it easier on yourself.

In AssemlbyInfo.cs, notice that the AssemblyVersion attribute is set to
auto-increment every time you build. This is very bad, and considered by
many to be a bug in Visual Studio. You should only be incrementing your
assembly version for distinct "releases" of your code, since the version
is considered part of the code identity. Needlessly incrementing the
version number causes a LOT of problems, including the one you've
discovered.

Your customers still have the problem in that they lose all of their
settings when you deploye 2.0.0.0 over 1.0.0.0, but at least you won't
have that problem during development, where you really don't need to
differentiate between 1.0.2342.1234 and 1.0.2345.5212.
John J. Hughes II wrote:

Ok now I guess I am supposed to save my user setting in the new setting
file. Which is placed in the users application directory under the company
name based on version number. I really truly don't understand the logic
behind this unless MS assume every other company waits half a decade to
release new software.

First of all is there some method of migrating from the last installed
version?

Second debugging is a real pain... every time I make a change to the
application it forgets all the setting and I have to start over.

The of course my customers really don't want to have to reset all their
setting every time they reinstall.

My system currently has 25 directories for setting files which unless I
manually delete them will stay forever. This seems like the same logic MS
did with registry values, I have 100s of those items, it's no wonder the
registry on so many computers is screwed up.

Could someone please explain why?

Regards,
John

[John J. Hughes II]

Thanks for the response. I can see you point but if I can't fix the problem
for my customers then its pointless. Oh well I guess I will continued to
handle it directly.

Regards,
John

"Joshua Flanagan" <jo**@msnews.com> wrote in message
news:OM**************@TK2MSFTNGP09.phx.gbl...

I can't help you solve the root problem (where the settings file is
stored), but I can help you make it easier on yourself.

In AssemlbyInfo.cs, notice that the AssemblyVersion attribute is set to
auto-increment every time you build. This is very bad, and considered by
many to be a bug in Visual Studio. You should only be incrementing your
assembly version for distinct "releases" of your code, since the version
is considered part of the code identity. Needlessly incrementing the
version number causes a LOT of problems, including the one you've
discovered.

Your customers still have the problem in that they lose all of their
settings when you deploye 2.0.0.0 over 1.0.0.0, but at least you won't
have that problem during development, where you really don't need to
differentiate between 1.0.2342.1234 and 1.0.2345.5212.
John J. Hughes II wrote:

Ok now I guess I am supposed to save my user setting in the new setting
file. Which is placed in the users application directory under the
company name based on version number. I really truly don't understand
the logic behind this unless MS assume every other company waits half a
decade to release new software.

First of all is there some method of migrating from the last installed
version?

Second debugging is a real pain... every time I make a change to the
application it forgets all the setting and I have to start over.

The of course my customers really don't want to have to reset all their
setting every time they reinstall.

My system currently has 25 directories for setting files which unless I
manually delete them will stay forever. This seems like the same logic
MS did with registry values, I have 100s of those items, it's no wonder
the registry on so many computers is screwed up.

Could someone please explain why?

Regards,
John