I have a Visual Basic 6.0 application that I want to install for All Users, for example, the setting are held in a single spot regardless who logs into the computer. I have the following code to locate the common location:
Const ssfCOMMONAPPDATA = &H23
Dim strAllUsersPath As String
strAllUsersPath = CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self.Path
On Windows XP, this path points to C:\Documents and Settings\All Users\Application Data\ folder. The setup copies the settings file there and everything is great. The Visual Basic 6.0 app can change it at any time.
On Windows 7, this path points to c:\ProgramData folder. The setup, which requires administrator privileges, copies the file there. However, when my Visual Basic 6.0 application starts and accesses the file, Windows 7 copies the settings file to a C:\Users{USER LOGIN}\AppData\Local\VirtualStore\ and performs all the operations on it there. As a result, because for each user, Windows 7 copies the settings file to a separate user directory, the users end up having a different settings file.
Am I storing the file in the wrong location? Am I doing it in the incorrect manner?
This one has bitten me too. The ProgramData folder has shared Read Access, no shared write access. You can of course change the permission on the folder during install, but I think that goes contrary to how Microsoft meant it to be.
See this other question for some useful links
How Microsoft thinks it should be done.
Related
I have a visual studio setup project which installs my files to the program files folder and also writes some stuff into the registry and in addition some of the files are com visible (so there is more confusing stuff written to the registry).
Therefore I have to install it as an administrator - this works fine. And this administrator and every other administrator is able to start the program. But using a standard user I am not able to start the program.
All registry entries are there for the standard user - and it also has enough rights to access the file in the Program Files folder.
Could there be a problem with the ComVisibility? (Which is needed because it's actually a DLL working as a plugin for Solidworks)
You just need to look at the code in your app and see what it does that limited users can't do. Installing it for all users does not mean that it automatically allows limited users to violate security. Just find out what it's doing when it gets the security error (which is what you believe it is).
Limited users have never been able to write to restricted areas such as the ProgramFiles folder, CommonFiles folder, HKLM etc. That's a common reason for limited user issues with apps.
Until Windows Vista I saved my application data into the directory where the program was located. The most common place was "C:\Program Files\MyApplication". As we know, under Vista and later the common user does't have rights to write under "Program Files" folder.
So my first idea was to save the application data under the "All Users\Application Data" folder. But it seems that this folder has writing restrictions too!
So to sum up, my requirements are:
The folder should exist under Windows XP and above.
All users of the system should have read\write\creation rights to this folder and its subfolders and files.
I want to have only one copy of file\files for all users.
It's often good to use environment variables so you keep things more generic.
Vista has changed some things, with NTFS Junction Points. See http://www.svrops.com/svrops/articles/jpoints.htm
Anyway, using %appdata% should automagically put files in the proper place on xp/vista/7
There is no such location. Even on Windows XP (and probably 2000 as well) no such location ever existed; we just think it did because we all ran with administrative privileges. It is not until Vista forces us to run as limited user that we realize our incorrect assumptions. You're going to have to explicitly set the permissions on your directory.
I would create a subfolder like All Users\Application Data\YourAppName\Shared, so that it's clear that just that folder will contain files writeable by all the users, setting up the privileges in the installer.
I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.
I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).
Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.
I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.
My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.
Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)
Not really.
The directory that serves as a common
repository for application-specific
data for the current roaming user.
AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.
You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).
You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.
If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.
If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData
You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.
Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?
Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.
On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.
It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of
%userprofile%\AppData\Local\Programs\Microsoft VS Code
This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation
Windows 7 folder structure is deeply inspired on Unix structure:
/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user
Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).
It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.
When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.
Please install executable files to the %programfiles% folder in Windows - a simple MSI based install package can perform an active setup for any new user who logs onto the machine to create the user specific files and folders in their profiles %appdata% folder. You see this behaviour for Internet Explorer, Adobe reader, etc. - It's the little MSI installer window that pops up the first time you log onto a machine which has those applications installed. - Thanks - a system admin :)
My opinion, for what it's worth, is that user-specific program files is just asking for trouble and is a damn stupid thing to do.
A much more sensible approach is to install different versions of your program to:
\Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe
I would then place a bootstrapping launcher at:
\Program Files\Your Program\ProgramLauncher.exe
Then, the user application data folder will only contain data, including an INI/XML/Settings file that indicates the version of the program that this user is working with.
Such an approach satisfies the core tenant of keeping data and executing code separate, allows every user to run a specific version of the code, and offers a small amount of de-duplication by ensuring the same executable code is not copied multiple times across user folders.
Otherwise, go right ahead with installing programs to AppData and undoing the years it has taken us to achieve clean separation of code and data. I found this thread because I noticed that Chromium and DropBox are installing code to AppData. I'm going to uninstall those program, and change the permissions on my AppData folder to exclude execution to ensure I can easily spot other programs attempting the same BS.
We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.
What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.
As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.
When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).
If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.
Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.
For more information, see this TechNet Magazine article.
Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?
Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.
Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.
The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:
http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista