F
Family Tree Mike
Guest
RE: Application Data
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:
> 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\application
> 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.
>
>
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:
> 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\application
> 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.
>
>
