Im trying to create a per user installation for my program made in vb.net
I have .net 4 as a prerequisite which im going to download if its not installed
The problem ive run into is admin rights is there a way to install the framework as an admin/elevated user then install my application as the current user so basically
user launches bootstrapper -> pre-reqs run as admin -> application runs as current posibbly limted user.
Im making the installer for my application using Wix (3.5), then im using dotNetInstaller to bootstrap and deal with the prerequisites.
If an admin installs application from the limited users profile he takes over the installation, which is what I dont want, but if the .net isnt installed the admin has to do this.
The admin could install the pre-requesites then close the bootstrapper then the user could install the application but this doesnt seem like a great idea.
Appreciate any help/advice anyone can give.
I think if dotNetInstaller is run un-elevated, and you will start a pre-req which needs elevation, it will automatically show a UAC prompt. But the dotNetInstaller will remain un-elevated. So your installer will also run un-elevated.
See also Configuring dotNetInstaler 2.0 to install custom prerequisites and then run a custom exe with elevated privileges which explains how to run dotNetInstaller un-elevated.
Related
We are creating a MSI installer for a windows application using WiX (and DevOps pipeline), which asks users (non-admin) to enter admin credentials to install it and updates on their machine.
However, now our objective it to not to force them entering admin credentials while installing the updates.
After going through some (old) articles, I came to know it is possible using patching, however, have not got any concrete examples.
Highly appreciate if someone can guide or give pointers or if there is a better alternative to patching.
We have developed a Windows .NET+WPF app and a .msi installer. The app is always installed for all users by admin. We would like the app to be automatically updated from predefined location (a shared folder in a network) on start. I think we can just have a code in the app which downloads a new .msi from the shared folder and then starts it. But the .msi needs to have administrative privileges to install for all users. Is there any way to give right to all users to update the app to a new version? Can we give them something during the initial installation, what everybody can run but it runs "as administrator" to install the new version of the app?
As I recall, that's the standard behavior when doing a minor upgrade. See:
https://learn.microsoft.com/en-us/windows/win32/msi/authoring-packages-without-the-uac-dialog-box
For major upgrade, UAC elevation will be required each time unless you can also write a helper service that advertises / blesses the MSI using the msiexec /jm command.
I have programmed a Bootstrapper application with WiX 3.8, which installs IIS Express 8.0 and activates IIS-features.
But the feature-activation only works, when the user is a local administrator at least.
How can i check in a WiX-Bootstrapper, if the user has admin rights?
Thanks in advance!
See:
Burn Built-in Variables
•Privileged - non-zero if the process could run elevated (on Vista+)
or is running as an Administrator (on WinXP).
This is similar to the Windows Installer Privileged property.
Also check that you are using the PerMachine attribute on the ExePackage element if you are using it.
I'm trying to certify a desktop application for Windows 8.1 using Windows App Certification Kit 3.1.
Everything is fine with the exception of the uninstall. I created the MSI file using Wix Toolkit 3.6. When the application installs it creates an entry in Programs and Features as well as a shortcut for uninstalling.
When I trigger the uninstall from either of these locations it works properly and all the files and registry entries get removed.
However, when the WACK launches the uninstall process, the MSI starts the installation process instead.
Is there a specific command from msiexec I need to test that WACK might be using to cause this?
I really do not understand why the Kit will launch the installer again.
Thank you,
Fernando
I found the problem and my solution.
The WACK calls the uninstall process using the Change option instead of Uninstall. You can test this by going to *Programs and Feature*s and clicking Change.
Since my application does not support changing or repairing, I simply set ARPNOREPAIR and ARPNOMODIFY to "Yes" and now WACK only calls uninstall.
The other option is to offer the Change/Repair dialog on your setup project and have the Remove check-mark available.
Hope this helps.
Cheers,
Fernando
I am working on a project that has been using 2 VD projects to distribute admin and user versions of installations, and now I need to switch to WiX. It was a bit painful experience with lack of documentation and all, but I managed to make something of it.
However, there is still one problem: I want to make only one .msi which will allow user to choose whether he wants to install as admin or as user. If he chose user, I don't want to ask him for elevation (as he doesn't need it), also if he chose admin, I don't want the installation to crash but to ask for privileges.
My current solution crashes in admin mode if I set InstallPrivileges to limited because the user doesn't have the permission to install, and it prompts for elevation in user mode if I set it to elevated.
My opinion is that there is no way to fix this because of compatibility with MSI, but perhaps there is some way to change privileges from elevated to limited in install time that I'm missing.
In conclusion, I want to know these things:
Is it possible to change privileges at install time
If there is no way to do so, what is the best workaround for this problem (exporting 2 .msi files or something)
One solution is to build two separate installers and then launch them via a custom WiX bootstrapper (aka Burn). The bootstrapper would be in charge of displaying the UI and launching the appropriate .msi.
Or you could separate the "admin" features into a separate .msi and then use a custom bootstrapper to install both .msis if the user selects an admin install.