For in-house tools, the approach of writing to the program files folder is
fine. Here are a few ways that it can be problematic if the code goes out of
your team, such as to a customer:
1. Vista - Must run with elevated permissions to access program files folder.
2. 64 bit OS - Virtualization pottentially renames the folder, so you better
not assume it is c:\program files.
3. XP - Most organizations don't allow users admin priveledge, and the admin
people will not change the permissions on the program files folder.
4. Since this is a service, you are asking a lot from the IT department if
this is not run under "local service" account. On top of that, asking that
the local service account be given such broad permission, is not good.
I hate to ask, but does this other cavelier developer think that the
checkbox for "allow desktop interaction" is just fine and dandy for everyone
to do?
"Tom" wrote:
fine. Here are a few ways that it can be problematic if the code goes out of
your team, such as to a customer:
1. Vista - Must run with elevated permissions to access program files folder.
2. 64 bit OS - Virtualization pottentially renames the folder, so you better
not assume it is c:\program files.
3. XP - Most organizations don't allow users admin priveledge, and the admin
people will not change the permissions on the program files folder.
4. Since this is a service, you are asking a lot from the IT department if
this is not run under "local service" account. On top of that, asking that
the local service account be given such broad permission, is not good.
I hate to ask, but does this other cavelier developer think that the
checkbox for "allow desktop interaction" is just fine and dandy for everyone
to do?
"Tom" wrote:
I don't know if this is the best group to ask this in, but then again, I
don't know where to ask it either. So please be gentle ...
>
Anyway, my group has written several .NET Windows services over the past
year. Now typically, these services get installed in the program files
directory, and they almost always have configuration files that they
read/write from.
>
My argument is that any files that are read from/written to must go into the
application data directory (e.g. - XP: docs & settings\all users\applicati on
data\our company\). Another guy on our team just changes the permissions of
our directory under program files so that everybody can write to that
directory when our product is installed.
>
I keep telling him this is a bad idea, and that Microsoft made the
application directory specifically for this reason, but he always comes back
with that it's just a directory, and as far as security goes, it's just as
secure as writing to this application data directory, and then I don't
really have a good response to him.
>
So ...
>
What is the actual benefit to using the application data directory, and why
should we use it?
>
Thanks.
>
>
don't know where to ask it either. So please be gentle ...
>
Anyway, my group has written several .NET Windows services over the past
year. Now typically, these services get installed in the program files
directory, and they almost always have configuration files that they
read/write from.
>
My argument is that any files that are read from/written to must go into the
application data directory (e.g. - XP: docs & settings\all users\applicati on
data\our company\). Another guy on our team just changes the permissions of
our directory under program files so that everybody can write to that
directory when our product is installed.
>
I keep telling him this is a bad idea, and that Microsoft made the
application directory specifically for this reason, but he always comes back
with that it's just a directory, and as far as security goes, it's just as
secure as writing to this application data directory, and then I don't
really have a good response to him.
>
So ...
>
What is the actual benefit to using the application data directory, and why
should we use it?
>
Thanks.
>
>
Comment