I am trying to add a file (licence information) to a several Installshield installers, to save storing the files seperately.
I have downloaded InstallShield 2012 trial, but don't have the project files.
Is this possible (no matter how hard the steps required)?
You can reverse engineer .cab and .msi files very easily.
As a first step; see what you can do using 7-zip.
I'm not a 100% sure if the hashes are checked, if not you should just be able to insert/modify the LICENSE within the CAB directly, maybe with a bit of XML mining to store the filename; though I doubt it.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
How to do Text file changes in a ZIP file in InstallShield Basic MSI project. I am not able to do Text file changes in a file which is inside a zipped file.
InstallShield does not offer this capability, at least not now. You will have to either surround the call to the text-file-changing custom action with ones that extract and replace the zipped file (the text file changes would operate on the temporary copy), or implement the whole thing yourself in one step. I'm not sure which approach will be easier.
In your situation, I would reframe the design and requirement. Silverlight .XAP files are typically digitally signed. Any attempt to modify the archive would invalidate this. It's also needlessly complicated.
Instead, change your application to use an external configuration file. native InstallShield functionality can then be used to update this file. For a possible approach, see:
Creating and Using Silverlight web.config app settings (Web.config Configuration Applicatioin Settings) or app.config application settings configuration file for Silverlight
I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:
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.
It's very straightforward to add languages to an installshield project. My goal is to
make a modified English (0x0409.ini) with some of the strings modified, such as
However I have a team of people that would have to copy these files to a directory much like C:\Program Files (x86)\InstallShield\2012Spring\Support andC:\Program Files (x86)\InstallShield\2012Spring\redist\. This is even worse with the 10+ machines in the build farm that could potentially need this file. It's a non-starter. It's hacky to have modify the install of a tool to get it to use an unsupported language.
Is it possible to check the language file to SCM and have it reside in a subfolder of <ISProjectDir>?
I don't believe so. I think you'd have to set up a post-build step that would copy in a modified ini file.
You could set up one in installshield's UI but I don't know if that persists in a stand alone build.