Delete files from hidden folder during uninstall (WiX, Pyinstaller) - wix

I would like to delete file (that was created by pyinstaller in C:\Users\User\AppData\Local\VirtualStore\Program Files (x86)\App\tmp )
during Uninstall (using WiX). Any idea on how to do that?
Does anybody know why pyinstaller creates that file and if I can control that?

A partial answer: That virtual store location is where Windows redirects file output when the program is not privileged enough to write to a location, and does not have an elevation-type manifest that shows it is UAC-aware. This might help:
http://sourcedaddy.com/windows-7/uac-virtualization.html
So it appears that pyinstaller assumes it is being run as administrator, but it isn't, and is writing to a location that's virtualised. Instead of trying to remove those files I'd look at that installer and how you are running it and (since it seems to require admin privilege) how to have it run with admin privilege. I assume it's old technology because an updated version would presumably include an elevation manifest saying that it requires admin privilege.

Related

Proper way of installing per-user files during a per-machine installation

I have a per-machine WiX installer (InstallScope="perMachine" InstallPrivileges="elevated") and I need to create a folder and copy a few files to the Documents folder of each user running the application. At the moment I install the files to a personal folder of the current user, but that's wrong and I get the ICE91 verification warning:
ICE91: The file 'SomeFile' will be installed to the per user directory 'SomeDir'
that doesn't vary based on ALLUSERS value. This file won't be copied to each
user's profile even if a per machine installation is desired.
I want the files to be automatically copied to the Documents folder of each user. Could someone post the step-by-step instructions how to do that?
UPDATE: I will be on holiday until September, during that time I will not be able to respond to any comments.
Windows Installer will do this - it's what advertised shortcuts will do. If you install a file to a user specific folder location and a different user logs on, then that file will be missing for that user and repair mechanism of the advertised shortcut repair will install it from the original MSI file. In your case the PersonalFolder property is the user's Documents folder.
To arrange this, the file must be the keypath of a component, and that component must be in a feature with an advertised shortcut. When the shortcut is used the component and containing feature are checked for "self healing" and the missing file installed. This works for users that don't yet exist. Older Office installers once did this to install user-specific items such as templates.
The MSI must obviously be available for this to work, and there is no mechanism to remove the files at uninstall time.
An alternative (or if there are no advertised shortcuts) is to add code to the app that calls MsiProvideComponment (or equivalent p/invoke) passing the ProductCode, feature name, Component id (of that documents file) and use INSTALLMODE_DEFAULT, which will install the file if it's missing as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370356(v=vs.85).aspx
and it will be missing and therefore will be installed for a user who has not run the app before.
Why would you want to do this this way? What if there are 10000 (just for example) users on the machine? You want to copy the files to all 10000 documents folders taking up potentially GBs of space (depending on the size if the files copied)? If these are configuration options needed by your app, the app itself should create default files in the user's documents location on the first run if they are not present otherwise load the settings from these files. You should not put the default files there for every single user on the machine at install time.
This approach also fails for new users added after you install. How will they get the files in their documents folder? Do they have to reinstall the product?
Consider a per machine install of per user installers with shortcuts that interested users could launch. For example, templates.msi, examples.msi.

Windows VB.NET Application exe run as administrator

I created an application that is installed from the setup file which installs all the files required by the program. When I update the application, I can only share the exe files of the update application to the user and not the entire installation package/setup file(not possible due to constraints)(Reason: so that he can run the application with out me having to make a new installation package/setup file and user having to install from the setup file) I am unsuccessful in my attempts so far. Can any one suggest if this is possible or if I am doing something wrong?
P.S : I have added the manifest file with privilege of always working as an administrator with out which I am unable to run my base application ( Error : Access to the path c:/xxxx/Tnsnames.ora denied)
Manifest file is the answer.
Manifest file is a file in VB project which contains the information
about the contents of file distribution. It may contain checksum or
hash to verify that file is original and isn't modified in any way.
Modifying a file will change its checksum value.
You need to replace asInvoker with requireAdministrator or highestAvailable
Updated link:
Full tutorial

What does warning "warning LGHT1076 : ICE91" mean?

I have per user installation.
Application will be installed to user's AppData directory.
There is following warning during build of wxs file:
warning LGHT1076 : ICE91: The file 'app.exe' will be installed to the per user directory 'INSTALLDIR' that doesn't vary based on ALLUSERS value.
This file won't be copied to each user's profile even if a per machine installation is desired.
What does it mean that file won't be copied to user's profile?
As I can see my application is isntalled without any problems. File is installed to user's AppData directory.
Normally, when you install a file to a user profile location and another user uses the app in a per machine install, you want all the files there. Otherwise you have an app that works for the installing user (because the file is there in the user profile folder) but it won't work for other users because the file is missing. If the MSI file was built "correctly", another user would log on, use a shortcut (for example) and Windows would notice the missing file and install it, therefore every user account (even those that are not yet created) will get a copy of the file in their user profile folder. If you're doing a per machine install and you want every user (not just you!) to get a copy of the file you should fix it.
CE91 posts a warning if a file, .ini file, or shortcut file is
installed into a per-user only directory. These warnings are harmless
if the package is only used for installation in the per-user
installation context and never used for per-machine installations.
You may wanna take a look into the docs.
If you want to suppress that warning msg take a look into this SO

Cannot overwrite files in ProgramData\myApp installed by MSI

I am about to create a MSI package.
During the installation (launched e.g. via double-click on the MSI) some files contained in the MSI are deposited deeper under c:\ProgramData (resp. the CommonAppDataFolder), e.g. c:\ProgramData\myCompany\myApplication.
Later when the installed application is run by the user the application may need to modify these file.
The problem is that neither the running application nor the user e.g. via Windows Explorer has the right to modify any files under c:\ProgramData\myCompany\myApplication created during installation.
The files do not have a readonly attribute set.
The strange thing for me now is: If I install the MSI via msiexec /q /i then I have write permissions on these files.
My MSI is created with WiX, my os is Win 7, the user is member of the administrator group.
Can anyone tell me why that is so, and how I can gain write permissions to these files w/o having to use /q /i?
Thanks
Jan
EDIT 2014-03-24: Damned. I missed to specify the InstallPrivileges attribute on my element, I just didn't know about it.
Setting it to "limited" does not show up a UAC prompt when installing to ProgramData! And now the user / my application is allowed to overwrite files in the destination folder :)
I don't know why that behavior would be different regarding access to that folder unless you have a custom action that does something that is only in the UI sequence. That's the only functional difference I can think of - the UI sequence is suppressed in a silent install.
However the common app data folder is not normally writeable to limited users. I'm not sure how much you know about UAC, but it doesn't matter if the user running the program is an admin or not because by default admins run with limited privileges. If the app needs admin privilege to run then it needs building with an elevation manifest so it asks for elevation to admin privilege. Either that or run it as administrator from a shortcut.
Windows access control is extremely complicated to deal with. In every version of Windows there is something new and changed to deal with, and it looks like the default write access in ProgramData now includes some sort of special ACL / DACL. If this is indeed the problem you can apply new permissions there and open up for regular users to write. Please note that I am not quite aware of exactly what newer versions of Windows apply as default. The tool I generally use to set permissioning is subinacl.exe. A real handful of a tool with a command line that can scare the most experienced system administrators. Some command line samples are here. You can also use the LockPermissions table in MSI, but somehow there are some issues with how these permissions are applied to the file system object. subinacl.exe is more complex, and more capable.
More on file and folder permissioning:
http://technet.microsoft.com/en-us/library/bb727008.aspx
http://support.microsoft.com/kb/308419
With regards to where you should put different types of files on the system, please check this thread.

Redcar Install Direct Options

Is there a way to direct the install of redcar to a user defined location other than a user home directory?
I have a jruby install on a USB drive, E:\jruby-1.6.2. Redcar installs the gems to the E:\jruby sub directory but then installs the user files to ~/ on c:.
Is there a way to direct it to e:\fakehome. I want to keep all installation files on my USB drive.
I do not have a Redcar-specific solution, but here is a general solution that may work for you.
PROBLEM:
The user has an application that installs application data files to a fixed location, but the user wants the files in a different location (such as a removable drive or a standardized app data directory).
SOLUTION:
Use a Junction Point or Symlink to simulate the presence of the pre-configured directory.
STEPS:
install the application normally
locate the pre-configured directory that you wish to have relocated (e.g. c:\users\foouser\appdata\fooapp)
create an empty directory with the same name in your alternate desired location (e.g., e:\myusbdrive\appdata\fooapp)
terminate the application you just installed if it is still running
move all of the files out of the pre-configured directory and put them in the desired directory
delete the toplevel pre-configured directory
create a junction that points to the toplevel pre-configured directory you just deleted from the alternate desired location
restart the application and use it normally, making sure that it still behaves normally.
If all goes well you should be finished.
Here i a link to a junction creator (for older versions of Windows (TM))
http://technet.microsoft.com/en-us/sysinternals/bb896768
HTH
This response from Matthew Scharley directly answers how this can be done for redcar.
For the moment it is hard coded. Thankfully it is easy to change:
https://github.com/redcar/redcar/blob/master/lib/redcar.rb#L211