I have a windows forms app developed in c# and have created a setup file for it.
.Net Framework used is 3.0.
Now, setup should force for admin rights for installation and then proceed else not.
I found articles on creating manifest file which works fine but when program is launched after installation it again asks for admin rights which is not i want.
And this prompt should also work on Windows XP SP 1 and above OS.
To prompt Installer to invoke the UAC prompt to the user you can do the following:
Right click your Setup Project > View > Launch Conditions.
Right click Launch Conditions > Add a new Condition in your Launch Conditions.
Right click the Condition, choose Properties Window.
Set Condition to AdminUser. (You can also try setting Privileged property)
Build and install
OR
Edit your .vdproj, change requiresElevation attribute to true
"MsiBootstrapper"
{
"RequiresElevation" = "11:TRUE"
}
Related
I have a project in c# which requires auto update functionality, since it has quite a lot of dependencies and runs a Windows service, ClickOnce installer is not suitable for this work. So I created a setup project for this application. Now I want to include an auto update feature.
My auto-update strategy is:
From the main application, check for updates every morning.
If an update is found, get the msi link
Application passes control to the msiexec and quits
Ex.
msiexec /i http://www.example.com/share/package.msi /L*V "C:\log\example.log"
Since my application is running on administrator account UAC prompt will not occur.
Are there any pitfalls that I haven't seen? Or there any superior way to do auto update gracefully?
Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions.
A couple of comments/answers:
"Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions."
But only if you increment the Version property of the setup project, accept the change in ProductCode, keep the UpgradeCode the same, ensure that the value of EveryOne or Just me is the same in the older product and the upgrade, and increase the file versions of files you need to update.
It's also not obvious to me that you won't get a UAC prompt because "running on an administrator account" does not mean the same as "running with administrator privilege". If the running process is not running elevated a prompt will occur, because UAC means that even administrators are running limited unless explicitly elevated. Even if you are elevated, calling msiexec as an external shell call will not result in msiexec being elevated. A shell execute does not transfer privilege to the offspring process. The other thing to consider is whether it's the current interactive user that is effectively doing this update, because there may be an issue trying to show UI if another user owns the desktop.
Anyway in general it's ok to do that, it's quite common, and signing the MSI would be more secure. Also, Windows Installer will sometimes prompt a repair, so that install URL needs to remain valid. A better approach would be for you to download the MSI to a location on the client system that you own and prompt the user to run it, or you run it - it's more friendly to offer that than pull the rug out and just do it.
So I have a WPF application and here is what I want it to do. I can right click on the executable, select Run As Different user, and get the Windows Security box with User Name and Password, as well as the Smart Card logon. I was wondering if there was a way to launch the Sysinternals Run as Different User to come up automatically, without having to right click and select Run As Different User. Any thoughts?
I was able to go into the Assembly Manifest and force it to run as administrator, but that isn't what I need. I really need the option to run it with Smart Card credentials. Thank you in advance!
AFAIK, the only way to do it that works is by using the RunAs exe as follows. The /savecred will cache credentials, but your user will still have to enter it the very 1st time (which might be annoying for your use-case).
runas.exe /savecred /user:<localmachinename>\administrator "path to your WPF exe"
or, if you're on a domain:
runas.exe /savecred /user:<DomainName>\<AdministratorAccountName> "path to your WPF exe"
Example: To Run Visual Studio 2012 in Admin Mode, I tried the following and it worked. I was prompted to enter my password just once, for the 1st time.
runas.exe /savecred /user:<My_DomainName>\<My_AdministratorAccountName> "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
Further Reading: Runas Documentation.
I have a c# application where I have to have read/write access to the root of the C drive. I realize I can compile the code and run the executable as administrator and it works. But I need to debug it and I am unsure as to how one would start the app within Visual Studio.
I have tried adding:
<requestedExecutionLevel level="asInvoker" uiAccess="true" />
to my manifest but I still get access denied error.
Here is the line of code that fails:
MemoryMappedFile mmf = MemoryMappedFile.CreateFromFile(#"c:\somemapnamefile.data", System.IO.FileMode.OpenOrCreate, "somemapname", 1000);
For now I have a work around but I'd like to know for the future.
Just run visual studio itself as an administrator. Any program you debug from there will also be run as an administrator.
VS must be run with admin right. however, a more elegant way is in the requiredExecutionLevel in manifest should set to 'requireAdministrator'.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
When you open the project and try to debug, the VS2012 will warn about the admin right and restart itself to admin right. And also the exe file will be marked as requiring admin right at the first place therefore when deploy you don't need to configure admin right requirement in file properties.
You can also set this administrator option automatically:
To answer the question in your title, you can just select Run as Administrator from the context menu when starting VS.
Now the checked answer will not working.
You should find an option for this in project properties Linker -> Manifest File -> UAC Execution Level. Set this to requireAdminstrator.
This will cause the default generated manifest to include the requestedExecutionlevel that you need, so that your users will be prompted automatically to elevate their privileges if they are not already elevated.
The "This task requires the application to have elevated permissions" error occurs because of The current user didn’t have a sufficient privilege to open Visual Studio.
As a temporary solution
You can overcome this issue by right-clicking on visual studio and select run as administrator at every time you intend to open it
As a permanent solution,
You can check the compatibility troubleshooting
Right, Click on Visual Studio > select Troubleshoot compatibility.
Select Troubleshoot Program.
Check The program requires additional permissions.
Click on Test the program.
Wait for a moment until the program launch. Click Next.
Select Yes, save these settings for this program.
For the detail steps with images, please check Visual Studio requires the application to have elevated permissions
I have a C# application, and a Visual Studio (2010) Setup Project with it. In my Setup Project, I am using InstallAllUsers = True. Additionally, my application needs to launch at Startup, so a shortcut is being added to the User's Startup Folder.
So I install my application as user Bob (from a share), and then I log off and log on as user Alice. Alice gets a dialogue that says:
The feature you are trying to use is on a network resource that is unavailable.
It provides the network path from which the MSI was installed. So, basically, it's looking for the MSI on a share that Alice doesn't have access to. This is repeatedly reproducible if Alice tries to manually launch the Startup link. However, Alice can directly launch the exe from the installation location, which works fine.
I don't fully understand why it is looking for an MSI, but I guess it makes sense that an application can not be completely installed by one user for another user, so the MSI is needed to complete the installation.
But if that is the case, then I don't understand why the MSI only seems to be required when launching from the Startup link, and not from the exe directly.
My question has several parts:
Is what I am experiencing expected behaviour for the InstallAllUsers option?
If so, how can I ensure that my application is fully installed for all users?
Is it necessary to copy the msi locally, and ensure that it does not get deleted before each user has had a chance to log on?
This is happening because the shortcuts are "advertised shortcuts" hence the greyed out target box.
More info here...
http://www.advancedinstaller.com/user-guide/advertised-shortcuts.html
When an advertised shortcut is launched it validates the checks
associated with the key resources. If any is missing it will fix it by
running the installation package and installing again all information
from the .msi file.
This is why its trying to run the msi.
You can turn off advertised shortcuts by reading this article...
DISABLEADVTSHORTCUTS=1 disables all shortcuts
If its an all users install, then the shortcut will probably want to reside in the all users start menu. Win 7: C:\ProgramData\Microsoft\Windows\Start Menu.
Eric, I would recommend taking a look at the shortcut file contents. You can do this by using Powershell, and there is a SO link to help you on your way:
Editing shortcut (.lnk) properties with Powershell
I'm creating a custom action that executes a script on a database. The problem is that the connectios uses intergrated security, so when I try to open the connection i get the error: Login Failed for user 'Domain\ComputerName$'.
When i check the identity on the custom action (using System.Security.Principal.WindowsIdentity.GetCurrent()) I always get "NT AUTHORITY\SYSTEM"
but I'm running the installer under my account which has enough privileges on the Database.
How can I run the custom action under the real user runnig the msi file or solve this problem in any other way?
Well, there's a simple solutions for this but maybe it's not suitable for all cases.
If you set the project property of InstallAllUsers
To true, the installer runs with "NT AUTHORITY\SYSTEM" Account, but if you set it to false it runs with the identity of the user who launches the installer.
Setting it to false worked for me, even that I was installing a Windows Service that runs for all users.
The short answer is that you're going to need to
Enable 'impersonation' for the custom action.
(On Windows Vista and Windows 7 systems) run the entire installation in an 'elevated' context (i.e. 'Run as Administrator').
How you accomplish #1 depends on what you are using to create the installation package. In order to easily deal with #2, I use a bootstrapper (created with Bootstrapper Manifest Generator) that is configured to run 'elevated'.