I have a Basic MSI Project in InstallShield 2012 Spring. This project installs sample documents to the current user's Documents folder (Not the Public Documents folder). When I then log onto another user, I see the application installed, but I do not see those sample documents in the second user's Documents folder (this makes sense). My question is, is there a setting in InstallShield or a way to have the sample documents install for this second user when the second user launches the application? Can launching the application detect that there are files missing in the user's Documents folder and then trigger a repair?
While this is possible, I would not recommend it. The user should control what goes in his or her documents folder; the large number of applications out there that do not respect this is not a good reason for another not to do so. Instead the application should have a way to browse the samples, open them as templates, etc., and then allow the user to save them in the documents folder. If you need them to start in the documents folder, have the application copy them in, and track somewhere that it has done so.
If you do try to automatically install these through Windows Installer, the simplest approach is to make per-user components with key files reflecting the documents location, and ensure your application's shortcuts are advertised. Launching through an advertised shortcut will scan for missing key files, and then auto-repair will install them. But auto-repair is not an experience that users like, and this approach will replace the files if the user deletes them all. (Alternately you can use a per-user registry key as the indicator, which may be less likely to be deleted.)
Related
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.
Hi have an application running separateley (1 instance for customer) in different folders, 1 per each customer.
Each customer is a separate user on my machine.
At the moment I have the source code in each of these folders where I rebuild the code per each instance. Would it be better if I do something like the following?
create a shared folder where I build the code
deploy the binary in each user folder.
allow permission for each user to access the source code in READ ONLY mode.
when it is time to debug, by using gdb in each user folder will allow to read the source code and debug will happen.
Do you think that this could be a better approach or there are better practice?
My only concern is that each user has the chance to read the source code, but since the user will not access directly his folder (it is in my control) this should not trouble me.
I am using CENTOS 6.4, SVN and G++/GDB.
in different folders
There are no "folders" on UNIX, they are called directories.
I rebuild the code per each instance
Why would you do that?
Is the code identical (it sounds like it is)? If so, build the application once. There is no reason at all to have multiple copies of the resulting binary, or the sources.
If you make the directory with sources and binaries world-readable, then every user will be able to debug it independently.
We are using VS 2012 with TFS 2012.
We want to prevent some users to view particular source files in a project,
We know how do this,Actually by right clicking on the files on the source control window and manage permissions in security tab.
The problem is that when we prevent a user to view or change a file such as HomeController.cs
the user can't build the project and the vs IDE says that the file does not exist,
How we prevent access a file with the ability of successful building project for the user
If you prevent read / view permission then how can the compiler access the file in order to build it? If the compiler can see the file then so can the user.
Are you sure that you want to prevent these users from even seeing the file, or do you just want to prevent them from changing the files? If it's the latter then you can simply remove the permission to check-in.
There is another avenue that may be of use in your situation. Split the project up into libraries and only combine all the libraries on the build server.
The developer can build but not run on their machine. With gated check-ins the build is made available.
This works especially well if the project is web based and the build server deploys the assemblies to a web server that the developer can view.
Otherwise the notes on obfuscation and decompiling stand.
In my application, every user has its own settings, that I save to a subdirectory in that user's Application Data directory. During uninstall, I want to delete those settings for every user on the computer. How can I do that in Inno Setup?
In other words, I need to get a list that contains Application Data directory for each user (not the shared Application Data directory), so that I can delete the MyAwesomeApp directory from there. Is there some way to do that?
You can't, due to the design of Windows.
The same design stops you accessing the profile folders too.
On top of this, it's accepted best practice to leave the user's data behind in case they want to reinstall it, roaming profiles, etc.
Assuming that your uninstaller runs with administrator priviledges, you can just get the User directory and then enumerate all the user directories there.
You can run an executable from Inno Setup written in whatever language you want. In it you can first get the current user's Application Data directory, using the SHGetSpecialFolderPath function. It would look something like this for Win7:
c:\Users\MyUser\AppData\Roaming\
You can use GetUserName to get the user's name (MyUser in this case), and find the parent directory and split the string to the parent directory "C:\Users\" and "AppData\Roaming\". You can then use FindFirstFile/FindNextFile to enumerate all users directories, and just append the second part "AppData\Roaming\" to them, and check if the file exists. By splitting the directory you get from SHGetSpecialFolderPath you ensure it would work both in XP (which would return something like C:\Documents and Settings\MyUser\Application Data") and in Win7. Basically you just replace MyUser with all the users' names in the string returned by SHGetSpecialFolderPath.
I have no idea if this avoids OS security or if it works with roaming users.
I have an installed and configured squirrelmail in my linux server which i used to send and receive emails.
Now i have to format the linux server... then before formatting how can i backup my emails and configuration so that they can be used again ?
Backing up your email messages is not a SquirrelMail issue. SquirrelMail is an IMAP client and does not store email itself. You need to determine what kind of storage is used for your particular email system. If it's a very simple/default *nix email setup, you might start by looking in /home/ for a directory with a name indicative of the purpose, such as "Mail", "Maildir" or similar. You might also look in /var/mail or /var/spool/mail
There is some starter information on some ways to migrate email between servers here: http://squirrelmail.org/docs/admin/admin-11.html#ss11.2
Also, you might want to re-think why you need to format the whole system. *nix systems don't need to be treated like Windows systems do. They can usually be rearranged, expanded, tweaked and otherwise changed without the need for reformatting.
As for SquirrelMail itself, there are a couple things you may want to back up, which would be any configuration files for SquirrelMail itself (in its "config" directory) and any plugins you'd installed (you can usually just copy the entire plugin directory for most typical plugins and transport them to the new system with minimal hassle), any custom themes you may have had in the "themes" directory, and finally, all user preferences. The location of your user preferences depends on your configuration - might be in a database or might be wherever the "$data_dir" setting points to (find this by looking in "config/config.php" or by using SquirrelMail's configuration tool ("config/conf.pl"). If you have user preferences stored in a directory, you can normally just copy the whole directory. Note that even if you have SquirrelMail configured to keep user preferences in a database, some plugins will still use the data directory setting for some purposes, so it's advisable to back up that directory no matter what.
The wiki page at SquirrelMail detailing upgrades is the same thing you need: http://squirrelmail.org/docs/admin/admin-4.html
When backing up and migrating things like this between servers, you need to be very careful about file/directory ownership/permissions on both your email data and your application configuration and preferences data. If user and system account names and UIDs are not the same between the servers, you'll want to be very careful that you adjust the ownership of the files to suit the destination server.