I added an app.manifest to a C# Windows Forms project because I needed the .exe elevated. Worked fine. I deleted the manifest because I no longer needed the app elevated. I changed to create application without manifest in properties.Re_Built...the app still needs admin elevation to run.
Works fine if I right-click run as admin. What gives?
The app just dies unless it is run as admin.
Well, despite what you say, it seems that your program carries out actions that do require elevation. Perhaps you write to a location that standard user does not have rights to. Or perhaps you write to registry keys under HKLM.
To get to the bottom of this you need to do some debugging. Find out what it is that your program does that requires elevation. Use the IDE debugger, or a tool like Process Monitor.
Related
Seems like a simple question but I am facing some weird problems.
I am using Visual Studio 2015, Enterprise Edition and Install Shield to create setup of my software, this is my first time making a general purpose software. Everything goes according to plan but I get these 2 problems.
Problems are:
Shortcuts don't work
Application doesn't launch until I run from root directory as admin
Problem 1:
I create the setup and do everything asked, I put the primary output into setup, which by the way contains 2 files. the .exe file and a .config file and I choose the primary output in "add" button to create a shortcut but when I install that setup, the Desktop shortcut doesn't work, in no way.
Problem 2:When I simply double click on the software's main .exe file, it doesn't run. No response but when I run it as Admin, it responses and opens. The problem is weird cause this doesn't happen in debug or the release files of the software.
Is there something I am doing wrong? maybe the way I insert the primary output?
This doesn't appear to be an installation problem. Your statement "..when I run it as Admin, it responses and opens" means that your program requires admin privilegs to run correctly, and running it from a shortcut does not automatically run it as administrator. The usual way to say that a program needs elevation when it runs is to give it an elevation manifest as here:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
with requireAdministrator. The program will then show the standard dialog requesting elevation.
The most likely reason for your program doing nothing when it fails is that it silently crashes and goes away, and that's probably because your code isn't explicitly making sure that everything you do is actually working. For example, if you try to create/modify a file in Program Files (and you're not elevated) it will fail, and your code should check that access was denied.
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.
What is the best way to install a .msi in a c# application in silent mode. I want to install a .msi file using msiexec, but I don't know how to do this. The problem is for using msiexec with /qn, you have to run it in a cmd.exe process start "as a administrator" and I don't know how to accomplish something similar with a c# application (for more details, a wpf project in VS 2010). The best I come to is :
Process p = new Process();
p.StartInfo.FileName = "runas.exe";
p.StartInfo.Arguments = "/user:Administrator cmd";
p.Start();
A windows will pop and ask for a password, but I found this behavior pretty ugly. I mean, I don't want to ask the user for his password. Is there anyway way to start my project, set it as a kind of "run as administrator" (the UAC will pop-up, but that's ok) and just run the msiexec command ? Or is there any other way to make a silent install of a .msi file ?
Thank you
Despite somebody voted down without comment, this is a very thorough answer IMO:
Maybe somebody misunderstood, because the answer is quite long.
Recommendation for short reading: Take option 2) .
First, generally, try to avoid RunAs as often you can. With RunAs you are creating a mixed user situation which is not supported by all scenarios and applicatons/processes. With operating systems newer than XP it is not really necessary. Requiring admin rights with UAC (e.g. the correct manifest in the .exe) is at least MS recommendation !
(Just a security remark: Most secure way is still having the admin account completely separated so that neither RunAs nor UAC are normally needed.)
1) The most easy (but not my recommended) method to assure admin rights for a MSI install is doing nothing and let UAC work.
If the MSI needs admin rights, UAC will normally come up itself after some time (not every part of the install process needs admin rights, so it will take some time.
To ensure, that UAC requests come up in child processes, kinda UAC-inheritance, you have to use ShellExecute in the baseline. This is a Windows thing, has nothing to do with MSI or C#.
In C# you can do this like this:
ProcessStartInfo startInfo = new ProcessStartInfo(exeFile, arguments);
StartInfo.UseShellExecute = true;
This is of not much use, if you want a silent installation with no installation dialog (e.g. "/qn") at all.
Moreover the UAC so late has small disadvantages, so the following is recommended and very much safer:
2) Admin rights from the beginning, e.g. in the bootstrapper .exe:
If it is sure, that a setup should be started, or in general, your app needs admin rights for it's own or child processes, the best idea ist to assure, that your app itself has already admin rights from the beginning.
In other words, UAC comes up when starting the app. Then your child processes have admin rights too, and it works also for CreateProcess-type child processes and not only for ShellExecute-type.
To achieve this, just add a manifest to your app containing the following line.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
How to do it?
Given the fact that the whole Windows 7 evangelism was based on manifests ("What is the sense of life? Giving applications a manifest."), Visual Studio in it's different versions of the last years has not really done an excellent job of supporting this. Every version is different, and it is different for C#, C++, VB apps.
For VS 2010 and C# the way to go is:
(For VB.Net, it's in 'View Windows Settings' in the solution's Application tab, I've read here.)
In Solution Explorer, right click on the project and select "Add New Item", "New element" and choose "Application Manifest File".
Open this in VS by clicking and you will find the existing node of together with comment lines describing the alternatives. If you don't know about them, it is a good point of googling to learn one of the most important things about modern Windows.
Change the line so that level="requireAdministrator" is configured, and you are done. Your app now needs elevated rights. Try out after build.
(The "uiAccess" attribute, you can ignore, until your app shall control/automate the UI of other apps like in a remote control or UI testing app.)
Start the MSI install normally with "msiexec.exe ...". Don't forget the quotes at the right places and to catch the return code for errors and reboots.
An alternative to msiexec is using the MSI API (socalled external UI), but it is more complicated.
3) No admin rights at all. Unfortunately this is not possible or would break security policies for standard applications which should be installable machine-wide in the programs directory. There is a lot more to say to this in detail of course.
I am working on a windows appliciation in which i create a folder at runtime and save some xml files in the folder....
Every thing works fine in Windows XP but when i run this in Widows 7 / Vista i get the error saying Access to the path is denied..
i am creating the folder in C:\Programfiles\MyApplication\
Please help me in resolving this
Windows 7 (and Vista) set access permissions on the Program Files directories and will not allow a normal user to write to those directories.
Either your program has to be run by an administrator, or you can change the permissions on your app's Program Files entry, or save the data somewhere else.
It might be an idea to use the special folders .NET provides for this type of data. This should work:
Directory.CreateDirectory(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + #"\AppName\test folder");
Then write your data to this folder.
Is your application running in the context of administrator?
Is visual studio running as administrator?
To do this right click VS and select run as administrator, to do it permanently, right click, propertys and select the run as admin check box.
When your debugging your app through VS, it will need the permissions, else the application its self will.
Its probably just a permissions based thing...
You can enable XP mode for an executable.
Please find the settings below
link text
Long time Windows XP developers should consider reading UAC,
http://en.wikipedia.org/wiki/User_Account_Control
It was first added in Windows Vista, and now becomes a central part of Windows family.
You SHOULDN'T write to Program Files. It's a bad habit and only installers should write there. What you "want" is bad for the whole ecosystem and just plain wrong. Don't do it.
I've got a WinForms application that I am working on. There is one small piece of functionality that needs to be run as an administrator in Vista/Win7. I understand how I can set the requestedExecutionLevel for the application in the manifest. The trick is, I don't want to require the user to run the entire application as an administrator, just one part of it. So I would like to have most of the functionality run asInvoker.
If I put the admin functionality in a dll, is there a way to mark it as requireAdministrator? I tried to use MT to add a manifest to the dll, but that didn't seem to work. What do I need to do?
No there is no way to differentiate the execution level of an application on a DLL by DLL basis. This is a process wide setting. You'd have to invoke another process within your application that runs the code in that DLL with elevated privs.
One option you do have though is to use either the rundll or rundll32 program to run the DLL directly. This is a standalone windows program designed to load and run a particular DLL. You could elevate the rundll process and get the isolation you desire.
Googling for rundll will give you plenty of advice on how to use it :).
Elevation is per-process, so you can't have a DLL elevated by itself. You need to look at hosting the DLL in a separate, elevated process; or you can look at the elevation COM moniker, and do it that way.