Well my installer installs some 3rd party msi installer silently. Now currently I'm checking the existing version by registry read method of Uninstall key (SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{GUID}). But this leads to some problem like each time the company giving me a new updated installer, I need to change this GUID.
And yes, I cannot rely on the 3rd party company's installer upgrade method as sometimes their msi gets screwed up, so need to check for the upgrade scope manually.
Now one way to overcome this, reading the version number of that 3rd party installed files and take decision accordingly.
Is there any other way that anyone can point me?
NSIS has a function GetFileVersion that may help you. Just pass it one of the executable files from the third party files. Here is my example:
${GetFileVersion} "$UserDir\thirdParty.exe" $CurrentVersionString
StrCpy $CurrentVersion $CurrentVersionString
DetailPrint "The Current version is: $CurrentVersion"
This will work provided the third party software properly versions their executables.
Related
I have a windows desktop application which is currently available on a Linux server for download on user's machine. I want to automate the process of MSI packaging on the same Linux server using any EXE/DLL.
I have an App.exe and App.txt file. Some information should be read from text file and injected into exe before creating an MSI package. This entire process has to happen dynamically in the Linux server only after the user clicks on download.
Can anybody point me in the right direction as to how i can achieve my goal? I want to achieve the same by having minimum dependencies on any additional/3rd party tool. TIA for any time and effort.
p.s - I have done some R&D about various installers but none of them were matching the criteria as they have too many dependencies.
False Positive Risk: Creating a new binary for every user would seem to be very unwise because of malware scanners and their ability to recognize "known" versions of binaries (by hash).
If you create a new binary for each user, the malware suite might suddenly start to quarantine your setup without any warning or sense. This problem is not trivial anymore as malware control is hardened everywhere and setups that run with elevated rights are "prime suspects for risk management".
Digital signatures can help, but they are merely a guarantee that you made the setup, and not a guarantee that the setup doesn't contain anything harmful. Nothing worse than signed malware vectors. In fact it is proof positive that the malware came from you :-). Note: some people even manage to tamper with signed executables. The combination of the latter two fact is very troubling.
Application Setup: I like to eliminate such features and details from the setup and make the application itself responsible for it own configuration on first launch after installation. I find this more reliable and easier to debug.
Custom Configuration: You can apply custom configuration information at runtime via various mechanisms. You should add in a transform, or you can create a batch file next to the setup with this information embedded and pass to the MSI or the setup.exe.
Batch File?: The msiexec.exe command line supports passing parameters to the MSI. You can generate a batch file that will run the setup with such parameters if you design your setup to support these "incoming" parameters.
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
Transform: You can also create a transform to contain the parameters (a transform is a tiny MSI fragment with settings and changes to the original MSI):
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
A transform would be difficult to create on a Linux box, seeing as they are COM-structured storage files native to Windows only. I am not sure if it is even possible, but maybe.
Some Links:
Can the resulting command line be determined after running an .msi installer?
Change Program Name and Shortcut Title during installation
How to make better use of MSI files
We have had some success with wixl from msitools.
Also WiX will run under WINE.
However, in both cases we have not had EmbedCab="yes" work, which may or may not affect you.
In Installshield 2015 Premier Edition, I've created a patch definition which upgrades my application product from version 1.9.7 to 1.9.7.5
In the Installscript MSI project, I've only changed package code, product version and built the patch (Latest 1.9.7.5 release - Previous 1.9.7 release).
Patch (Update.exe) is executed under Admin priviliges (a 1.9.7 release in installed priorly)
The patch 1.9.7.5 will omit to update .exe and .dll component files of a feature application directly install in [INSTALLDIR] (root : C:\ProgramFiles\MYCOMPANY\MYAPP\confapp.exe)
All other component files are updated respectfully ; they're located in their own sub-directories of [INSTALLDIR] as designed in Installation Architecture in IS2015.
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature1DIR\app1.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature2DIR\app2.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature3DIR\app3.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature4DIR\app4.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature5DIR\app5.exe
I'm shipping the newly built applications and have upgraded my .dll files with AssemblyInfo.cs.
Long story short, my Update.exe is only updating 5 out of 6 applications installed.
Any help appreciated if you've already encountered the issue,
Regards,
Can you please add your feature/component/file structure and log file entries that relate to those files in particular? It should look something like:
MSI (s) (B4:4C) [11:30:07:906]: Executing op: FileCopy(SourceName=eulatxt|eula.txt,SourceCabKey=FILE1,DestName=eula.txt,Attributes=512, FileSize=29239,PerTick=32768,,VerifyMedia=1,,,,, CheckCRC=0,,,InstallMode=58982400,HashOptions=0, HashPart1=-1713153497,HashPart2=58557210, HashPart3=1046945815,HashPart4=871163290,,)
MSI (s) (B4:4C) [11:30:07:906]: File: C:\WINDOWS\system32\eula.txt; Won’t Overwrite; Won’t patch; Existing file is unversioned but modified
You also need to check your components and key files. If the key file for a component is not changing in your patch (this is a "small update" or "patch" BTW, not minor upgrade), none of the other files in the component get upgraded regardless of the version changes associated. Remember that component best practices state one binary (versioned) file per component.
From this MSDN article:
Be aware how the Windows Installer applies the File Versioning Rules
when Replacing Existing Files. The Windows Installer first determines
whether the component's key file is already installed before
attempting to install any of the files of the component. If the
installer finds a file with the same name as the component's key file
installed in the target location, it compares the version, date, and
language of the two key files and uses file versioning rules to
determine whether to install the component provided by the package. If
the installer determines it needs to replace the component base upon
the key file, then it uses the file versioning rules on each installed
file to determine whether to replace the file.
If this is an InstallScript project, open Components view and make sure OverWrite setting is set to Always. By default, it is set to Overwrite files by version, then Date, I think. However, I have seen cases when this algorithm did not work for some reason, and some files were not updated.
I have what might be a simple question and might be....a more complex one. We are preparing to add NSIS to our software, that is, we want people who use our software to be able to create installers using NSIS, but through our software. (We'll be creating functions using NSIS, acknowledging NSIS, etc.) What I am trying to figure out before we get started is how many/what files our customers will be required to have on their hard drive for NSIS to work. So, we just need to know if nsis can be used standalone or if it requires the user to install it into program files, or if it requires a lot of different files in AppData - If we have to bundle a few .dlls, that's not a problem and is expected. Ultimately, if we end up having to bundle NSIS as well, that's fine - We just want to make sure it'll work on other people's computers without telling them to go download it.
MakeNSIS does not read/write from/to the registry or anywhere else and only needs a handful of files for minimal operation.
To build a simple installer you need:
NSIS\MakeNSIS.exe (Just calls Bin\MakeNSIS.exe)
NSIS\Bin\MakeNSIS.exe
NSIS\Stubs\* (If you are only going to use a specific compression mode you only need one, and the uninstaller file if you want uninstall capability)
If you want to use the Modern UI you need its header files, some files from Contrib (Graphics and UI) and system.dll and nsDialogs.dll from the plugin folder.
Everything else is optional but I would recommend that you also bundle:
NSIS\Include
NSIS\Plugins (You can remove stuff you will never need; dialer, splash etc)
NSIS\Contrib (Language files, graphics and UI)
You can find license information here.
You could also just ask the user to install it and enter the path to it in your setup program...
I would just include all of the files. (It's only 5MB or so) NSIS has a zip archive as well as exe installer that includes the necessary files. (Or just zip up the installed directory from exe installer).
From my experience, NSIS does not need to be installed to work. I run a fleet of build servers that build NSIS-based installers, and they each just have the files extracted in a directory. The installer is never run on them. This should mean there are no DLLs to register or things like that.
Just make sure you are following whatever their licensing terms are - I have not reviewed redistribution/bundling of their files in another product, since that is not something I do.
Is there a NoUninstall=Y or similar option I can put into Setup.ini for a program?
I want to compare the behaviour of a patched and non-patched version of some software. To do that, I need 2 copies installed in different folders.
When I run setup.exe the second time, I am prompted to uninstall.
If I change DoMaintenance=N -> DoMaintenance=Y, I get the option to Modify, Repair, Uninstall.
I do not have access to the original InstallShield project files.
I'd like to avoid having to use Virtual PC.
Otherwise can I change the GUID of the first install within Windows/Regedit?
I don't sure regarding changing GUIDs of installer in registry, but I guess it's possible, but the better will be change your setup. As I understood you have access to setup.ini, and perhaps you have access to msi? If so, you could change GUIDs of components, PackageCode, UpgradeCode, ProductCode and ProductName or ProductVersion.
P.S. For editing MSI you can use Orca, or more useful and also free InstEd.
I need to find all Visual C++ runtime installed on a machine. The exe will be run by a user who is not in the administrator group.
All solutions I've found rely on registry keys or scanning the c:\Windows folder (which I don't think is very reliable). In addition, if user cannot read the registry, chances are they don't have permission to access the system folder either.
Q1. Is there a 3rd method?
Q2. If multiple versions of VC++ are installed, is there a way to determine which one is used when an application is executed?
A1: Depends on what you mean by "installed". If you mean "used by some application", then even those methods won't tell you. If you mean "automatically found during application loading", then you really have to check the registry settings used by the loader.
A2: Sure, check whether the application imports MSVCRT80.DLL or MSVCRT90.DLL, etc.