Thanks Ronnie, but virtualization won't help me: the whole reason for trying
to find somewhere shared (both in the registry and in the file system) that
I can write information is so that other uses will pick up changes made. If
user a tries to change the registry key (e.g. which we use to point to the
newest data store filespec), then s(he) will presumably be able to access
the key subsequently and get the path (because it got virtualized, and
subsequent reads by that user will go to the virtual version first).
However, other users will end up reading the HKLM version of the key which
will now be out of date.
I can get around the need to change the registry key (by just always using
the same filename and have it set by the installer which has adminstrator
privileges), but not the need to modify a file on the file system, which any
potential users need to be able to do. Again, if file virtualization
happens, then the other users won't pick up the change.
I appreciate the fact that "limited user" means don't hurt anyone else, but
I'm just surprised that there's *no* system location where this is allowed.
There are "Public" folders, but no "Public AppData", which I think there
Ultimately, I think we're going to have a work-around by having the
installer change the permissions on the [CommonAppData]<companyName>\<app
folder> folder to give "Full Access" permission for "Everyone". [the
installer developer says he's able to do this].
However, something else is bothering me: the assembly that does the reading
writing of the registry key and files in [CommonAppData] is in the global
assembly cache. According to MSDN magazine (Nov 05), "The GAC is Full
Trust". So here's what confuses me: The installer needs administrator
privileges in order to even install that assembly in the GAC, it needed to
be strong named to go in the GAC, the user had to "Fully trust" it during
during installation... so why with all this doesn't it have permission to
write registry keys when it is used by a client application.
I even tried to use:
RegistryPermission rp = new
RegistryPermission(RegistryPermissionAccess.Create , strRegKey);
in the GAC assembly to fake the system out that it has permission and not
check the apps higher up the stack, but it just throws a Security Exception
Is this because DLLs (even in the GAC) can't use SecurityPermissions?
"Ronnie Vernon MVP" <email@example.com> wrote in message
> Vista uses Virtualization for older applications that need full write
> The path for the data file is C:\Users\username\AppData\Local\Virtual
> Store\Program Files\program name.
> See these articles for more information.
> Developer Best Practices and Guidelines for Applications in a Least
> Privileged Environment:
> User Account Control:
> Ronnie Vernon
> Microsoft MVP
> Windows Shell/User
> "Bob Eaton" <firstname.lastname@example.org> wrote in message
>> I'm having trouble porting something to Vista because my C# assembly (in
>> the global assembly cache) needs to have a location where it can
>> read/write/modify a file.
>> With Administrator accounts, it works fine, but with a limited account it
>> can't write to the location where the file is stored (which originally
>> was in C:\Program Files\Common Files...).
>> I tried moving it to [CommonAppData], but on Vista (at least), the
>> limited account doesn't have priviledge to modify files in that location
>> (i.e. C:\Users\All Users\... or C:\ProgramData\... I can't tell which...
>> there are duplicate copies in both locations).
>> Is there anywhere I can put a data file so that all users wil have
>> modify/write priviledge?