I have a French client with the French version of Windows 10. However, our Installshield-built installer is looking for C:\Users\username\Local Settings\Application Data, and fails with "Error 1320. The specified path is too long"
We tried to see if we could connect to the appropriate Local Settings\Application Data folder (in English), but it is either not accessible or even as admin we don't have privileges to go there (even from an admin command line).
I understand Windows 10 has some sort of invisible aliases or compatibility for these standard folders?
Are there any tricks we could use to get the software installed?
Disclaimer: this is a hack and the correct answer was provided by slugster - rebuild the MSI
Now that that's out of the way I do have a suggestion for you that might be able to resolve the problem for you. You can try creating the path that the installer is looking for and then creating a symlink to link that folder to the correct folder on the users machine. no guarantee that this works but might be worth a shot. If you need more info on creating symlinks check out hte TechNet page for MkLink
Related
I have an executable file to install a software in Windows 7, which will unzip a number of folders inside it.
I tried with 1 computer and it worked. I tried with another computer and there left a number of folders that were not unzipped.
I assume this is some sort of Windows 7 security settings but I failed to google for a satisfactory solution.
Thanks.
I would need more specifics about the different machines you are using it.
If it is a security issue, you will be able to successfully run it as an administrator. Do this by right clicking on it and selecting Run as administrator.
If the user you are using is not the administrator you will be prompted for an account and password, otherwise you will see just an extend UAC warning message you can accept.
The nature of the .exe could determine why it might not successfully unpack as well as the location the files are going to when being unpacked.
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.
I've nearly completed developing a game for Windows and I'm curious where I should have the installer install it. I know it used to be in "Program Files" but has that changed under Vista?
I know that World of Warcraft now installs under Users/Public/Games... what is the Microsoft-recommended location for games?
In Vista, the recommended directory is still %PROGRAMFILES%.
Note that in Windows 7, Microsoft has enabled the creation of true per-user installations, including support for per-user Program Files. This is a feature of Windows Installer 5.0, and you can read more about it here:
http://msdn.microsoft.com/en-us/library/dd408068(VS.85).aspx
You should use the Environment variables.
Namely %PROGRAMFILES% for you.
Just read the question a little more thoroughly. From my experience of Vista, most of the gubbins still install to %PROGRAMFILES%. Perhaps the /users/public... path is somewhere where things can install (and update) without having to get admin perms all the time. (A complete guess)
Looks like you should use SHGetKnownFolderPath to ask for the location of the FOLDERID_Games KNOWNFOLDERID.
EDIT: Nope, doesn't look like that is right. This thread has a discussion of FOLDERID_Games and notes that it is a virtual directory. This knowledgebase article discusses the Windows Vista Games Explorer. And this article has some more Vista specific information.
Sorry - this has turned into a non-answer but maybe the links will help you find the answer.
The recommended directory is still Program Files, as everyone has said. However, if you want a per-user install, you could install it in the AppData folder. I know Google Chrome does this to allow installation without being an administrator, and also for user-specific installation.
I was reading the post Installation file names in Windows Vista when I thought about Installation File Names. I'm a addicted software downloader, and frequently I've got installation names like "setup.exe" or "install.exe", that says nothing about the program to be installed.
I think that an installation file must be like:
Install[ProgramName][ProgramVersion][Platform].[exe|msi|etc]
or
[ProgramName][ProgramVersion][Platform].Setup.[exe|msi|etc]
What your thoughts?
I much prefer descriptive install file names. Sometimes, you want an emergency 'restore' disk to get a machine up and running even without internet connectivity. When all your installs are named "setup.exe", you either have to rename them all, or create a directory with a descriptive name for each one.
An example of where such a disk would have been really handy was when I took my brand new laptop in to work to use while I upgraded my desktop to Vista 64, and then Windows 7. I only have one wired LAN point, so my laptop needed a wireless connection for internet access, to download my installs. I had to download them all on my desktop, and then transfer by flash drive to my laptop. Very inconvenient.
Not sure this is entirely programming-related... but installer files are usually meant to be transient. You download them, run them, and delete them. (Or at least, I think most people do) So it doesn't matter much what the filename is.
I don't think there's any reason not to give the installer a descriptive name... but I certainly wouldn't say it "must" have one.
For CD-Rom based installation, I'd suggest sticking with SETUP.EXE which helps with autorun detecting software to install from the disk.
For downloadable files, just add the appropriate manifest to the EXE and Vista won't have a problem with it. I'd suggest something semi-descriptive, but there's no need to go into great detail unless it's something like hardware drivers that a person may archive off for reuse, otherwise the file name is confusing to non-technical people.
I read in this article:
http://technet.microsoft.com/en-us/library/cc709628.aspx
That Windows detects Installers through file names, following this tip, Is it better to include setup in the file name for the installer
I mean ProductSetup.msi is better than Product.msi???
It's hard to think that Windows does this kind of detection :-)
This only applies to EXE files. If you've got an MSI file, it's up to the MSI file to specify which parts of the MSI require elevation or not.
That's news to me, but it does seem like Windows Vista treats files differently when they have "setup" in their name. It will probably just prompt you for administrative rights up front if it detects that it's an installer, which is what you'd want.
Also worth reading is How User Account Control Affects Your Application, to ensure that your setup runs as administrator embed the correct manifest into the setup EXE. This way it doesn't matter (to Vista) what your installation is called.
That said however, if you expect the application to be installed on a terminal server then if your installer is called something like SETUP.EXE or INSTALL.EXE Terminal Server will automatically kick into "install mode". Should save you some headaches from those customers who don't know they should be in install mode first, or choose not to install via Add/Remove Programs (which also kicks install mode in automatically)