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]

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

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:[color=blue]
> 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
>
>[/color]

[John J. Hughes II]

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

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" <josh@msnews.co m> wrote in message
news:OMuF3QR$FH A.1288@TK2MSFTN GP09.phx.gbl...[color=blue]
>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:[color=green]
>> 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[/color][/color]