Re: Ini File vs Registry
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:5hhdd4996cpd83qjk281tjjoiojtns5s88@4ax.com...
You could easily store config file in the executable directory, just embed
the user's login name into the filename, and presto, you have per user
configuration in the same directory.
****
Not in Vista or XP. Generally the executable directory is protected. So
this solution
has a serious failure if the program is installed on a hard drive in any
site that has the
slightest concept of "security"
True, but we are discussing the config file for programs running off the USB
key, and then the exe directory is not protected. Putting the config file
in the exe folder makes it easy to xcopy that folder and have the whole
thing instantly available.
Why do you think the values are *not* per-machine? In fact, that is
usually the case. I
don't use the same settings on my laptop as I do on my desktop (different
screen geometry
and different usage patterns, for example, dictate different font sizes,
different screen
layouts, etc.). In fact, I've found that almost always the settings are
per-machine,
*especially* in our customer products (a failure mode: the serial port was
configurable by
the user, but on one machine it was COM1 and another it was COM3, and I
*had* done a
portable configuration file! This was clearly the WRONG decision in such
a case)
****
True, in that case there could be a global settings file which can be
overridden by a per-machine file. Most settings are global, including:
desired font face name, colors, app defaults such as help file settings,
etc.
My customer base wants install programs, and in fact really doesn't want
XCOPY deployment.
They feel very strongly about deliberately not supporting that. We've had
very few
requests to migrate app settings, and the few times we actually
anticipated this and did
migratable app settings, it turns out that they caused us more tech
support calls than we
wanted to deal with (yes, really).
Web apps are interesting, but they are not where I work. And where would
I store the
settings for a Web app anyway? At that level, a configuration file is no
different than
the Registry...if I store it in user\appdata or the Registry, the effects
are the same,
but it takes more work to create user configuration files in user\appdata.
I would say your customer's goals of locking their app to a given machine
may fit a niche market (do they have USB sentinnel keys also?) but I am not
discussing niche markets.
Web apps save your settings on the server.
Migratable app settings generated problems with getting the file in the
right place, not
overwriting a file that was already there, *merging* settings between two
files, deciding
which settings were per-user and which were per-machine (example: the COM
port selection
in one app was per-machine but in another context it was
per-user-per-machine, where each
user coming in over terminal services got a different COM port but if they
used it on a
different server it required a different COM port...and yes, we had more
phone calls and
redesigns on that one issue than was worthwhile! Copy the settings file
from the server
to your machine and the program failed; copy your local settings to the
server, the
program failed, and naming the settings as [user.machine] ended up
generating truly
MASSIVE .INI files with lots of problems about if you changed the settings
on machine 1
did the setting change for machine 2, or SHOULD it, and it turns out that
each site had
different requirements as to which settings changed this way...we ended up
ripping the
code out and putting it in the Registry, with Export and Import
functions).
This cries for xml files with support for hierarchy and not .ini files. It
pays to compare apples to apples.
You can't use XCOPY deployment on licensed software unless it also carries
the license key
with it, and that's something that virtually all of my customer base is
not willing to
accept. They want a very specific install scenario that deals with
licensing; I don't
write this code, but their (third-party) install packages work this way.
So I don't see
reasons to solve problems that my client base does not want me to spend
time solving.
Sure, tying software to per-machine is currently an accepted practice, but
it is not going to be in the near future. Users plainly are not tied to
individual PC's any longer. Recognizing that fact and removing the barriers
to more creative deployment scenarios is somewhat like adopting .NET instead
of MFC. It offers immediate rewards and will be the way things are solely
done in the future.
-- David