I'm using Inno Setup 5, and to enbody an customizable .exe file, it's name is changed in the [Files] section using the parameter DestName. But, we're talking about an .exe file.
I noticed that when it's running, the name in Task Manager is the old file name, the DestName parameter only changes it's actual name, not the file Description, which is shown in Task Manager. Somebody has had any experience like this?
I'm using Windows 10, running as administrator (if makes any difference).
The file description is a part of the file header.
You cannot change it easily. It's possible. But only with unsigned binaries. Changing a description of a signed binary would invalidate the signature, as any other change would. And nowadays all binaries should be signed.
If you sign the binary as part of the installer build, you can modify the description before that. You can use Resource Hacker command-line. There are various way to invoke a tool like Resource Hacker as part of the installer build:
If you build your installer from command-line, you can modify the description even before you run the Inno Setup compiler. See Run a [Code] or PowerShell script in Inno Setup compiler.
You can use Exec preprocessor function. This is also covered in Run a [Code] or PowerShell script in Inno Setup compiler.
Or you can do it as part of the signing. For some information see Inno Setup - How to change the icon of the shortcut of uninstaller without separate icon file? and Microsoft SmartScreen - suspended using Inno Setup installer?.
For an example on how to use Resource Hacker to modify a binary description, see Inno Setup change Task Manager Description for Setup.tmp – It's about a manual modification, but you will need some of the information even for your automated (command-line) modification.
Though I believe that way easier is to automate and customize your application build process, so you can easily produce the binaries with custom description, instead of hacking it into the installer build process.
[Setup]: VersionInfoDescription
Default value: "AppName Setup" if AppName doesn't include constants, an empty string otherwise
Description:
Specifies the file description value for the Setup version info.
This setting has no effect if UseSetupLdr is set to no.
Code Sample:
VersionInfoDescription = "This is my awesome app description"
There is a solution I found.
Go to the direction of Inno Setup, then open Default.isl file. This file includes all setup descriptions & other components.
You can open this file with any text editor, then press Ctrl + F and search for whatever you want to change.
After you saved this file, compile your setup file and execute it again.
My description was already changed.
There is an example I did previously.
Related
I have two executable files, the first one should run the second one. The second one comes with different types of manifests: asInvoker, requireAdministrator, etc.
Is it possible to change the manifest of executable file? I'm searching a simple solution on C.
I would like not to keep few copies of executable with different types of manifests, and not to keep third party tool that could change it. BTW, it is possible and this tool exists: MT (manifest tool) from visual studio package, link.
Yes, you can change the manifest file using mt.exe from the Win32 SDK. But that is only something you should do during development or testing. You cannot deploy this tool to customer's machine, so you can't use it to dynamically change the manifest back and forth.
But that's okay, because you don't ever need to change the manifest file back and forth at runtime. The executable's manifest file should specify the minimum required privileges for that EXE. Thus, if it's possible for the user to run the EXE without administrative privileges (i.e., without elevation)—even if it means the app runs with limited functionality—the app's manifest should specify "asInvoker". The user can always choose to run the app with administrative privileges if they need those extra features.
And, of course, you can launch the EXE programmatically with elevation. You do this using ShellExecuteEx, specifying the "runas" verb for the lpVerb parameter. This will have the same effect as setting the permissions level in the application's manifest to "requireAdministrator".
It is not entirely clear from your question how your application is set up. Normally, the first EXE has "asInvoker" set in its manifest so that any user can run it. It doesn't need administrative privileges in order to do anything. However, if there is something it might need to do that requires administrative privileges, it displays some bit of UI with the UAC shield icon, and clicking on that will launch a second EXE (with "requireAdministrator" set in its manifest) that performs whatever task requires elevation. This second app doesn't need to be distributed in an "asInvoker" form because what it does always requires elevation. You'll notice that this is how all of Microsoft's apps are set up, including the bits shipped with the operating system.
Thanks #RbMm for his comment.
Also I found later that my question is duplicate. Sorry for that, I haven't found this earlier.
So, the solution (error handling and includes omitted):
HANDLE handle = BeginUpdateResourceW(file, TRUE);
UpdateResourceW(handle, RT_MANIFEST, CREATEPROCESS_MANIFEST_RESOURCE_ID, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), manifest, strlen(manifest));
EndUpdateResourceW(handle, FALSE);
Notes for further generations:
Manifest should be in short chars - char * instead of wchar *
Errors (e.g. incorrect XML syntax) could be tracked in Event Viewer, section Windows Logs -> Application
Some tools (Resource Hacker) could open and show manifests, but they show unicode manifests without error too...
I'm trying to create an automated way to build mpir on Windows with Microsoft C++. One required step seems to be to install vsyasm, so my current mini-project is to create an automated way to do that, i.e. something that can be done by a batch file or program without human intervention.
The vsyasm readme suggests three methods:
a. put these files in the MSBUILD customisation directory,
which is typically at:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations
or:
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations
b. put them in a convenient location and set this path in the
'Build Customisations Search Path' in the Visual Studio
'Projects and Solutions|VC++ Project Settings' item in
the 'Tools|Options' menu;
c. put them in a convenient location and set this path in the
'Build Customisation dialogue (discussed later).
The first is blocked by Windows security. Are there any ways around that that don't require manual intervention?
The second and third directly require manual intervention. Are there any automated equivalents, particularly if you want to end up building the project from the command line instead of within the IDE?
Are there any other options I'm missing?
As far as I can tell, there simply is no repeatable way to install vsyasm. There is, however, a repeatable way to build mpir with the command line compiler, and this is the way I recommend doing it: forget about Visual Studio integration, download plain old yasm, rename it to simply yasm.exe, put it somewhere in your path, run vcvarsx86_amd64.bat and:
cd \mpir-2.6.0\win
configure.bat
make.bat
In an InstallShield project I have a VBScript custom action that conditionally needs to execute a certain file packaged with the install.
Normally I get the current directory of a vbs using code such as
sCurPath = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")
Which, if it returned the location of the Setup.exe that initiated the install, should work.
However when running the install, the current path (on XP) is C:\Windows\system32 instead of the location of the Setup.exe file I was expecting.
Assuming the output of my InstallShield build looks like the following
Disk1
->Setup.exe
->ISSetupPrerequisites
-->Req1
-->Req2
-->...
->OtherReqs
-->ConditionallyRunMe.exe
How could I run "\OtherReqs\ConditionallyRunMe.exe" from a VBScript custom action?
Thanks!!
(Note: I realize there are ways to conditionally run exe files from withing InstallShield, but in this case the requirements are not supported by InstallShield - unless there is a way to use a VBScript custom action return value as a condition to run another file?)
After a lot of messing around, I got it (actually found it in the InstallShield manual, and not Google, go figure :))!
This line of VBScript does the trick
disk1Path = Session.Property("SETUPEXEDIR")
The line above points to where ever the setup exe file was, so from there it's trivial to run any exe included with your install media.
Other useful ones I found, which I'll past here for reference are
'points to app data\downloaded install directory
MsgBox Session.Property("SourceDir")
'where the software wants to install to on the users system
MsgBox Session.Property("INSTALLDIR")
Not sure why it's so hard to find a good reference on MSI Standard properties (even just a list). The closest I found was this, but not all of them work (and not specifically for InstallShield at all). If anyone finds a good link with documentation about MIS Standard properties and their description please add a link here, so no one has to waste as much time on this as I did :).
Is Visual Studio's Setup Wizard project able to only deploy some of the files only if it finds a certain key into the registry (a) ? If not, then maybe launch another installer file when that certain reg key is present (b) ?
(a) I have been trying to deploy a winamp plugin through VS's .msi files. 2 problems:
the path to {winamp}/plugins folder has to be obtained automatically
on failure, user should be presented with a dialog to choose where to install the plugin to
(b) In an attempt to overcome (a) the NSIS installer was used for only packaging the winamp .dll plugin; however, this introduced another issue:
if user does not have winamp installed, the NSIS generated sub-installer must be manually canceled, and this invariably causes the main VS generated installer to fail (while it shoud not, winamp is not an essential part of the good functionning of the whole app I am deploying)
I have failed in 2 ways to conditionally launch the sub-installer on a certain reg key detection (tried to look for the ProgID key of Winamp). First failure was because the ProgID key is not found even on machines that do have winamp installed (manually checked for the key, it was there), and second failure was due to the fat that such conditional launch could not be applied to just the sub-installer, but to the main installer only.
I am thinking of dumping the VS project wizard altogether and just move to NSIS installer wizard.. but I would not want to learn to script it for deploying each component of my solution. Any GUI version for it ? Or should I start learning Orca and use it on the VSPW's output .msi file ? Or what ?
Thanks
If you want to use a MSI the approach is this:
- create a search for the registry entry
- use the search result (it's stored in an installer property) to condition the components of your files
- use the same result to condition the installation folder dialog
This can easily be done in commercial setup tools. But if you want a free solution, Sandeep is right, Wix is very good.
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".