I have an Inno Setup installer that worked fine on my machine (Win 7 32-bit), but did not work at all on a test machine (also Win 7 32-bit). After some investigation, I found that the reason is that there is something going wrong when the UAC is set to anything which is not Never notify me. However, if I right click on the installer, and select Run as Administrator, the installer works fine.
I then tried to modify the embedded manifest of the installer (methods described below), so that it will always run as admin, but this is not working as I wished. I have obtained the original manifest using the command
mt.exe -inputresource:installer.exe -out:installer.exe.manifest
I, then, opened the extracted manifest using a text editor and changed the line
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
to
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
I then, tried to apply the resulting manifest, by running the command
mt.exe -manifest installer.exe.manifest -updateresource:installer.exe;#1
but the manifest tool gave me the error
mt.exe : manifest authoring error c1010001: Values of attribute "level" not equal in different manifest snippets.
I also tried changing the command to
mt.exe -manifest installer.exe.manifest -outputresource:installer.exe;#1
but this caused the entire installer to be overwritten by nothing more than the resources (i.e. the actual installer was lost).
I also tried opening the installer executable using Visual Studio (Resource Editor), modified the manifest and saved the file, but this gave the same result as the second mt.exe command I used.
Does anybody know what I am doing wrong, or if I am missing out on something ?
You shouldn't modify the manifest of the resulting Inno setup as Inno does any elevation it needs for the PrivilegesRequired directive.
If you do modify the manifest, or manually do "Run as Administrator" then it will break all the ...AsOriginalUser functionality, most importantly, the postinstall flag.
mt.exe and similar resource editors are also very likely to strip the setup data from the setup file as it's appended to the end of the binary.
Related
I want to deploy my app with an wix based installer and also want it to be available in the Command line, so that I can call my app after installation just like this:
C:\> myApp "Some parameters"
I know that I can achive this by adding my installation directory to PATH, but I need a bit more.
I would like to call my app by another name, for example my app is named like
MyApp.Cli.exe
and for a few reasons I would like to keep that naming scheme in the install folder. But on the command line I would like to call my App like
C:\> MyApp
instead of
C:\> MyApp.Cli.exe
Any ideas how to achive this? Thank you a lot for any help.
App Paths: I suppose you can try App Paths? It is an alternative to updating the PATH variable. I don't think it works via the command line, but it works in the Windows Shell - or in other words when you do Windows Key + R and type in "YourAppName" (without the quotes), then you run the right application without updating the systems PATH variable.
Reminder: Remember to test on all OS versions you intend to support!
Note on WiX:
Sidenote: The WiX toolkit does something interesting. It adds its own environment variable WIX and sets it to the path of the
toolkit's installation folder. Hence you can do this in scripts and
the cmd.exe window: "%WIX%bin\candle.exe" in order to launch the binary in question (candle.exe, light.exe, etc...).
App Paths, Registry: In the registry your App Path would look something like this:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
"(Standard)\Your Path Here\Your Path Here\MyApplicationFullName.exe"
Actual reg-file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\DaTool.exe]
#="C:\\Program Files\\My Tools\\DaFullNameOfDaTool.exe"
WiX Markup: Running heat.exe reg MyRegExport.reg -out MyWiXFile.wxs -sfrag -suid to convert the exported *.reg file to WiX markup yields something like this (not tested, please adjust as appropriate - just a generalized idea of how to do this):
<Component>
<RegistryKey Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\DaTool.exe" Root="HKLM">
<RegistryValue Value="[ProgramFilesFolder]DaFullNameOfDaTool.exe" Type="string" />
</RegistryKey>
</Component>
Command Line: It seems it works to use the "start" command from a command line window:
start datool
But it does not work to just go datool. Didn't test much, have a play with it?
Links:
How the App Paths Registry Key Makes Windows Both Faster and Safer (Helge Klein)
Application Registration
Modify user and system variables in Visual Studio 2017 installer
"Register" an .exe so you can run it from any command line in Windows
I have a custom Java app and an IzPack installer. For years, in my izpack build file I had the following:
<run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
The problem is that some of the users do not have admin privilege on their PCs, but they still want to be able to install the package. If I remove the above, they can run the installer but then it complains "This directory cannot be written!", when they try to install in the default location, which is C:\OPENDCS.
Yet the same user can create this directory either from a CMD or an Explorer window.
Is there a way to allow the izpack installer to create a directory directly under C:\ without running as an administrator?
Please check the behavior with izpack v5.0.7. The problem you mentioned should be fixed with this issue: https://izpack.atlassian.net/browse/IZPACK-1355
You could package your directory create operations in a create-dirs.bat batch file, which you would mark <executable> and execute stage="postinstall". This way the directory creation will be executed with the given user's permissions, which (according to your post) should work just fine.
EDIT 29/02/2016: You would put this file into a first "dummy" <pack>, mark it <executable> and execute stage="postinstall" as stated above, which would execute it after this first dummy pack was installed. At the installation of the next pack (i.e. your first useful pack) you will already have the folder created.
Note that postinstall will not run the batch file after the installation, but after the <pack>'s installation.
I am getting this weird error on Windows 10 when I try to build any project. The projects are working fine if I build them on other OS.
The specified task executable "cmd.exe" could not be run. The
specified executable is not a valid application for this OS
platform.
When I tried to check the log I got to the following code in Nuget.targets file inside .nuget folder, I commented the code and the project builds fine now. I don't understand why the error. Any new projects that I create are working fine...
I am using Visual Studio 2013 on Windows 8, Windows Server 2008 and Visual Studio 2015 on Windows 10.
Code:
<Exec Command="$(RestoreCommand)"
LogStandardErrorAsError="true"
Condition="'$(OS)' == 'Windows_NT' And Exists('$(PackagesConfig)')" />
What is the reason for this error ?
Is it because of OS or because of Visual Studio ?
How do I resolve it? I don't think commenting the code is the way to do it...
I got the same error, and repairing the corrupted files solved my issue. Try this:
In administrator command prompt, run sfc /scannow
It should emit log file in %windir%\Logs\CBS\CBS.log. Confirm that it repaired cmd.exe. For me I saw something like this Repairing corrupted file [ml:48{24},l:46{23}]"\??\C:\WINDOWS\SysWOW64"\[l:14{7}]"cmd.exe" from store
If that doesn't help you can try DISM /Online /Cleanup-Image /RestoreHealth
See more here
It happened to me when building my project on Windows 10. The problem was that the path of one file was very long (longer than 260 characters). So, by making it shorter, the problem solved for me.
I had the same problem with VS c++ OpenFrameWorks. I tried your suggestion but could not solve the problem. I solved it differently as under.
Soln:
Project Properties ->
Build Events ->Post-Build Event -> Command line
"robocopy "$(OF_ROOT)/export/vs/$(Platform_Actual)/" "$(ProjectDir)bin/" "*.dll" /njs /njh /np /fp /bytes if errorlevel 1 exit 0 else exit %errorlevel%"
Removed Above line from command-line.
OK, Solved.
If you started to face this error after deleting some files :
Unload your project
Edit Your csprok
Delete any reference for the your deleted files
Reload your project and Build
I faced the same issue when building a .NetCore App using a template that includes an Angular app with it, and i tried to delete the ClientApp folder. I had to remove multiple Target and ItemGroup tags from within the csproj.
To those who have landed here:
If you get this message I suggest that you do not, as #Hans Passant suggested, first assume that your machine or Windows has been corrupted.
Instead, I recommend that you suspect that your anti-virus or Carbon Black installation is to blame.
This was the case for me.
Someone from my IT Department disabled a certain Carbon Black policy and everything magically worked again.
I have a setup exe, and I want its .msi file for administrative installation (see https://superuser.com/questions/307678/how-to-extract-files-from-msi-package)
But, although I see at the beginning the extraction of .msi, I can't find it.
Where is the location of this file?
Usually MSI file(s) might be extracted in different temp locations depends from who was launched (User\System\etc) and how configured setup.exe. Sometimes you can extract it with help of different command-line switches for setup.exe.
The simple way to check - launch it under user account, go to %temp% folder, most likely there should be created folder with {GUID_view_name}. Inside this folder you will find MSI file.
User's %temp% folder has different location in different Windows versions:
Windows XP\2000\2003:
"C:\Documents and settings\{user name}\Local settings\Temp" or "%userprofile%\local settings\temp"
Windows Vista\7\8\2008\2012
"C:\Users\{user name}\AppData\Local\Temp" or "%userprofile%\appdata\local\temp"
P.S. Also you can check this SO question-answer.
Snapshot a clean VM and use a program such as Install Watcher or InCntrl to record the current state of the file system. Run the setup.exe until you are on the first dialog of the MSI and take another recording. Diff and look for where the MSI and related support files appear.
I found a much better solution, Igor, gave me the idea.
I used ProcessMonitor and filtered with Process is "msiexec.exe" and Path ends with ".msi".
I found the msi in:
C:\ProgramData\Downloaded Installations\{41A70E83-DA5D-4CA6-9779-73C9330E3D13}\IQProtector64.msi
I am getting the following error trying to load a basic project template:
Error 12 Could not load the assembly file://\\psf\home\documents\visual studio 2010\Projects\WindowsPhonePivotApplication1\WindowsPhonePivotApplication1\obj\Debug\WindowsPhonePivotApplication1.dll. This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file, even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties. Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information. WindowsPhonePivotApplication1
I don't have the Security tab when I try and modify the DLL to unblock the assembly. Any advice?
Did you try copying this assembly locally? Currently it seems to be loaded from a network share. You will need to trust that network location if you want to work this way.
Drive:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol.exe -m -ag 1 -url "file:////\computername\sharename*" FullTrust -exclusive on
Check this KB for details... http://support.microsoft.com/kb/320268/
I just ran into this very same problem - trying to compile a Silverlight application inside Parallels Desktop 8 virtual machine on a Mac - where the SL output directory was located on the emulated drive (appears in Windows as a network drive).
Very simple fix. You can open up devenv.exe.config located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE and add this line inside the <Runtime> node:
<loadFromRemoteSources enabled="true"/>
e.g.
<?xml version ="1.0"?>
<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
...
<runtime>
<loadFromRemoteSources enabled="true"/>
...
To edit the devenv.exe.config file you will also need to open NotePad as administrator. After doing the above I can compile my SL application inside Parallels Virtual Machine, but the above also applies to Silverlight applications hosted on a network drive.
I ran into this. These were the steps I took:
Downloaded a file, WP7PiChartsFromDBSOUP.dll, to my downloads folder (everything locally).
Copied this file to c:/Program Files/ referenced it and attempted to build.
Got this error message.
Removed the reference, and followed the steps to unblock.
Referenced and attempted to build: still same error.
Went back to c:/Program files and noted that the file was still blocked. Somehow my attempt to block didn't take. So I tried to unblock, closed the properties dialog, then reopened. Somehow my attempt to unblock didn't appear to be working.
Went to the downloads folder and unblocked the file that was downloaded to this location, tried to unblock, and it seemed to work. So I felt like I was out of the woods. I copied this file over the file in c:/Program Files and reference it in VS2010, closing and reopening VS2010.
Same error message. I rebooted the machine and tried again. Same error message. And I know this is gonna sound crazy, but I renamed the dll from that long name to PieChart.dll.
And it finally worked.
So, either there was a problem with the name, or maybe changing the name somehow caused the change in blocked status to kick in.
I had the same problem trying to build an application on parallels.
I just copied the whole project in a folder under c:/ and works
it seems that parallels shares certain folders (i.e. desktop, documents) between the OS running on the vm and your mac user home folder. because of that windows treats these folders as network shared folder and forbids you to access them.
It's on the General tab in file properties from explorer. Either via the DLL in question, or you can do it on the zip file before you extract if it was a download, there will be an unblock button at the bottom right.
Make sure it's from a trusted source.
I've tried many solutions also with coping file to external usb drive with FAT32 file format, and some other ideas. But finally I've found post by caliban here: Topic about this problem. He links to a program called Streams which helped solving this problem :)
caliban:
Run this line in the command line
streams -s -d directory
download Streams exe
Add to the project a text file named ServiceReferences.ClientConfig having the following contents:
<configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>
Re-build the project.
If you still didn't get your answer, I just found the solution. You are saving the application into the network hardrive. So while creating the application, change the location to something like your local disk e.g.,
C:/Projects
Then you will be able to run it.
I had the same problem over VMWare using a mac to load windows 7, if you see the path it starts like a network path, that's why VS gives out about the security.
Take the entire folder project and put it in a physical path starting with C://program files... , then open and compile, it will work.
Right click on the dll and select properties. You should see a button to unblock the assembly.