I'm working on the bootstrap application of a new installer for some of our products. So far, I've been relying on two things that I read about somewhere:
Applications whose name contains "setup" or "install" will run elevated by default.
Applications that run elevated will launch other applications in elevated mode.
Recent testing has found that one or both of these statements is false, because one of the applications that I'm launching is a third party installer that requires elevation, and it's failing because of the elevation requirement.
How do I set my application to require elevation? I know it has something to do with the manifest file. As I'm working in Visual Studio 2008, and the manifest file is generated, I'd like to know what to enter into the project's properties and where to make it require elevation.
When I couldn't find application manifest as a new item that could be added to my project, I went into the online help and found this:
configure the VS2008 in Configuration Properties - Linker - Manifest File - UAC Execution Level (requireAdministrator)
That did the trick.
In VS2008: Add new item; application manifest file (app.manifest; the comments in the template file tell you how to demand more access).
You can now specify the manifest in project properties on the Application tab (but you need to uncheck "Enable the Visual Studio hosting process" to debug it).
Related
I have been able to successfully install a simple program using an Installer Project on Visual Studio Community 2017. However, I can't find out how to create a fully working deployable uninstaller for an end user.
The Installer Project was set up to only create an Application Folder (in C:\Program Files...) with the Program .exe, and nothing else. This it does successfully. I would like an installer because later I plan to make some registry keys upon installation.
To test uninstallation, I have run the original .exe file built by the Installer Project with the "Uninstall" option. This removes the Application Folder but does not remove the program from the Add/remove programs list in Windows - Leading me to believe there are other registry entries that have not been removed.
I have tried to uninstall purely from the Add/remove programs list, but then I get an error:
C:\WINDOWS\system32\msiexec.exe
"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
In Visual Studio, I can click "Uninstall" from the Installer Project right-click menu which does successfully remove both the Application Folder and the Add/Remove Programs Item, but this is not a deployable solution.
Notes:
OS: Windows 10
Using Visual Studio 2017 Community
Looking at the application Folder, there is neither an install nor uninstall .exe file in it. The Installer Project .exe is only in the original build location, and I cannot find how to get a copy in the Application Folder (not sure if a copy there would work).
I have tried configuring the Installer Project as x86 and x64 with no change.
I have tried using both Debug and Release build configurations with no change.
From looking around, WiX seems to have more features and flexibility, but I haven't yet dug into that. Is there an easier solution?
Has this issue occurred to anyone else? My hopes were that Installer Projects were the simple way to learn and handle installation.
Looks like I jumped to conclusions in the comment above, however I think I found the issue: I cannot uninstall the program from the Windows Apps & Features window in System Settings, but uninstalling from Control Panel\Programs\Programs and Features works fine.
When typing in "Remove" using the windows start button, the default item that comes up is "Add or Remove Programs" in System settings (This looks like a Windows 10 thing). When you click that, it forwards you to the "Apps & features window. I am now learning that for some reason this has different functionality than the control panel window. Or maybe it has lower permissions, although I am the admin and only user of this computer...
Because it can be uninstalled from Control Panel, I think this would be the preferred solution. My assumptions about the other window in system settings was my real issue. I just wish the Apps & features window aligned its functionality/permissions with control panel.
I also learned that uninstall is successful when I run msiexec.ex /I{PACKAGEID} in cmd. Not sure how relevant this is, but documenting here.
Installs and uninstalls are transactional, they either work completely or roll back completely. If you do an uninstall but the entry remains in Add/Remove Programs then it's likely that the uninstall did not in fact work.
When you do the install, if it has a UAC elevation dialog then the install is running with elevation and installing files/registry entries to locations prohibited to limited users. Removing files from those locations also requires elevation. You haven't said exactly how your uninstall works, but most likely it requires elevation to succeed, and your program isn't running elevated. If your program uninstalls silently the uninstall will fail silently, so it's possible that your program isn't actually checking that the uninstall worked.
I'd also guess that your Visual Studio session may be running elevated so uninstall from there works fine.
Apart from privileges, an uninstall from a running installed program tends not to work very well because the uninstall process cannot remove your running program or its folder because it's in use. So while you could get it to work (with elevation) you might find that your program and its folder are left behind until the next reboot. If people really want to do this, one of the strategies is to copy an uninstall program to the temp folder and fire it off asynchronously, so everything can be removed.
Uninstalls from Add/Remove Programs&Features generally work fine. Without some context that error message doesn't mean much. It's not a message that comes out of Windows Installer, so it's perhaps coming out of a custom action. Otherwise it may be an issue specific to the test machine.
There is never an uninstall exe in a Windows Installer setup. When you remove a product the system just calls the Windows API to remove the product. Windows Installer is part of the Windows OS with API support for everything that needs doing. Only non-MSI setups require an install and uninstall exe to do anything.
None of these issues seem to be related to your choice of tool. They all create MSI files and if an MSI design is not optimal it doesn't matter what tool you use. There's nothing wrong with WiX, but to install literally a few files it's overkill compared to Visual Studio.
Background:
My C++ application developed by VS2008 and use the VS setup project to create installer for that. After installation it will create two shortcuts to application. one is in user desktop and second one is in start menu. Application(myApp.exe) installed to the Program files directory.
Question: If I right click on the icons in the start menu, there is a option Run as Administrator for most of them. But if I right click on the shortcut that related to my application. It doesn't show Run as Administrator. How to fix this?
Edit: But if i right click on the myApp.exe in the Program files, it shows "Run as Administrator".
Set your embedded manifest to require administrator. On the project property page:
...on the (highlighted) UAC Execution Level, change asInvoker to requireAdministrator. Build your project to embed the new manifest, and it should be ready to do its thing.
Oh -- I didn't think to do it here, but in the Configuration drop-down, you probably want to select All Configurations, instead of the (default) Active configuration that's selected in the screen shot. Gets seriously annoying -- you think you've got things fixed, then you change to "Release" and a bunch of stuff suddenly breaks, and you have to go through figuring out what you'd changed, and edit those changes into the Release configuration as well.
In manifest file there is option "requestedExecutionLevel" and "UIAccess" which will manage it.
I found the answer for this after so much testing and searching. So here I mention it for use of any one.
Windows only shows Run as Administrator in the context menu for that shortcuts those are directly targeting to some exe file.
If you use VS deployment (setup) project to create your installation with desktop and start menu shortcuts. Those shortcuts not targeting to exe (Application.exe) file.
Instead of that shortcuts targeting to application folder (MS office 2007 also same). This is called installation-on-demand and advertisement. Here is the more details.
This will help your application to repair from file missing (pray Google for more).
So we have to disable this feature if you want to target your shortcuts directly to exe file.
For this you can use command prompt or some tool. here is how to do it.
Nirmally windows installer having a exe and a msi.
These setting are stored at at msi generated with setup file.
So You have to alter the file and add the entry DISABLEADVTSHORTCUTS=1 to property table.
Using Command prompt:
msiexec /i <path to your msi> DISABLEADVTSHORTCUTS=1
Using Orca Tool:(Meny other tools also there)
Download Orca tool from here and install it.
Right click your *.msi file and click edit with orca.
Go to property table and add new entry DISABLEADVTSHORTCUTS and value is 1 , save and close.
Now you done.
Install using setup.exe file and check the target of the shortcuts. those are directly target to the exe file in application folder.
Now if you right click on the shortcuts those shows Run as Administrator option in context menu.
Note: Doing this you will gain Run as Administrator but scarify the windows auto repair capability.
I need to create an application which needs to create files/folders in "C:\Program Files","Users[username]" and Sys32. Also the application needs to make some registry entry.
This application needs to work on Vista and higher. Also, on Windows Server 2003 and higher.
The above Operating Systems have the concept of User Account Control (UAC), where to access Program Files and writing in registry requires admin privileges.
I looked into many forums and found that using Microsoft SDK we can check whether the current user have admin privileges or not . But the function "CheckTokenMembership" fails for Vista and higher version of OS.
I also found a solution where manifest file can be used to tell OS in advance that the current application requires admin privileges. This is done using "requestedExecutionLevel" tag.
I am using Visual Studio 2005 to create the application. When we create an application in Visual Studio a default manifest file is created. Can I change this manifest file to include "requestedExecutionLevel" tag, so that my application always runs with admin privileges?
Is there any other method through which my application runs with admin privileges without asking user (admin or standard) to run my application as "run as admin"??
Thanks!
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.
Acknowledgements and Introduction
This question helped me and I will help back with the knowledge I gained. Thanks to:
Lipika(The person whom asked the question) revealing that admin access was the reason why access to system directories were redirected to virtual directories. It was later clear that lack of admin access cause writing to certain registry keys to fail.
snowcrash09 for revealing the Visual Studio option for enabling require admin access. With further research on MSDN, I got the manifest to not embed into the executable under Properties>Manifest Tool; thus allowing me to read it.
Nayana's link to polynomial's answer is also good. Here I will borrow part of his answer in my demonstration.
Answer
As Lipika have stated, you require admin access, else Windows Vista and up will redirect you to a virtual directory. Which is great. Logically then your app should request admin access. You can let the user do it manually. If not, Windows provides many ways to do this programatically. The easiest way is to declare it in your app's manifest. Here I will dedicate instructions to individuals not using Visual Studio. If you are using Visual Studio, it is as easy as Properties>Linker>Manifest File>UAC Execution Level.
If you are using CodeBlocks for example; create a file called app_resources.rc. With CodeBlocks its very import that this file has the .rc extension, so CodeBlocks knows to compile it with windows resource tool. Copy the following code into this file, and add it to your project.
#include <windows.h>
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "adminAccess.manifest"
Create a manifest file called adminAccess.manifest. copy the following code to the file. Do not need to add this file to your project as it is reference from your rc file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="MyApplication"
type="win32"/>
<description>Description of your application</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Now you can compile your app and it will automatically prompt for admin credentials when run. It will return failure if admin access was not granted. On Windows Xp, you won't be prompted for any authentication.
Note that from here you can edit the manifest to add features such as visual styles for Windows widgets and DPI awareness.
If you are not using CodeBlocks. For example you are compiling from the command line. You pretty much have to compile the rc file with the Windows Resource Tool. In MinGw build tools, this is called windres.exe. It will compile a .res file. You then link this resulting file, with all the other files you will be linking at the linker stage.
Note that the rc file is a windows resource file and carries all the resources your app uses such as BITMAPs, ICONs, STRINGs, dialog template. Which will all be stored in the final executable. Which you can then load from the executable using Windows specific functions. This is pretty similar to what Android does.
I'm developing a unit test project (let's say XXX.UnitTest) to test ViewModels in another project (XXX) in my solution. I can add the reference but when I build, an error states that it cannot find that same project (XXX)
Error 42 Could not load file or
assembly 'XXX, Version=1.0.2.66,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. The system
cannot find the file
specified. XXX.UnitTest
I did a clean rebuild of all projects in my solution.
I verified that the assembly with that version number (1.0.2.66) did exist in the path I was referencing.
I removed and re-added the reference both as a project and through the Browse tab.
I made sure that the version number was not specified in the csproj file.
I verified the referenced assembly with Dependency Walker.
I verified that both projects were targeting the x86 platform. (As suggested here Tips to help debug "Could not load file or assembly X or one of its dependencies")
Does anyone know what else can cause this problem?
Last week I had this same problem. It turns out my solution and projects were on a network resource. If I moved the solution to the local drive, the problem went away.
This problem happened regardless if I used a mapped drive or an UNC path.
This problem happened even with a Code Access Security Policy of "Full Trust" for the URL.
I believe the problem occurs on Windows XP computers and not Windows 7 computers, but have not tested or verified.
I believe it has something to do with the Share permissions.
If I try to use "offline folders" for the network resource, I get "access is denied".
-.
Setting NTFS permissions has no effect.
Adding user to administrators group has no effect.
I did not test to see if problem exists on removable local drives.
Work Around
Move solution and projects to a local hard drive.
Comment
I think this is a bug in Visual Studio 2010.
I came across this post while searching for the answer. Here is the solution. In the config file of QTAgent32.exe and devenv.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, add the following element to the section:
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
This can be added to machine config file (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\ machine.config) for all VS2010 tools. Be sure to run notepad as administrator to allow machine.config to save.
See this link for details: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx
I have the same problem. I'm running VS 2010 on Windows Server 2003; both running within a VM on a Mac. My VS project is in the mac home folder (~/) which is mapped as Z:\ from the Windows side. At build time, VS studio generates an error saying it can't find the UnitTests.dll or one of its dependencies. I get the same error with a small test project. If I move the project to the Windows C:\ drive, the dll reference resolves and unit tests work. I tried to add the reference Blanthor mentions, but couldn't get it to work.
I've been trying desperately to get my application (15 C# dlls and 1 C++/CLI dll with C++ Runtime DLL dependencies) to deploy with ClickOnce. I got it to work by just copying the Release folder, but ClickOnce refuses to copy the files (msvcm80.dll, msvcp80.dll and msvcr80.dll) and deploy them in this folder.
I did this nutty workaround (supply msvcm80.dll, msvcp80.dll and msvcr80.dll as Content/Copy If Newer and then at startup, create the Microsoft.VC80.CRT folder, copy those DLLs, and create Microsoft.VC80.CRT.manifest) that seems to work, but this all just feels wrong to me.
Am I missing something?
I'm stupid: I just found this:
On Publish tab of Properties page of my startup project: click Prerequisites... button > check Visual C++ Runtime Libraries, radio button setting: Download prerequisites from the component vendor's web site.
It seems to work the way one might expect!
There should be a msi from microsoft that deploys those for you. I used....
instructions
and download vcredist_x86.exedownload