I want to install OpenSplice DDS using nsis script, but i have to know whether the OpenSplice DDS installed or not in the system (Windows).
Based on the register keys how can we check if OpenSplice DDS is installed or not?
Can anybody provide the nsis script to check DDS installation based on registery keys?
A standard OpenSplice installation does not make any changes to the registry and as such, you can not use checking of the registry key to discover whether or not OpenSplice has been installed. Only if the option to install OpenSplice as a Windows service was checked during installation, information will be inserted into the registry -- just like any Windows service has an entry in the registry. Since it is up to the user to select this option or not, this is not a reliable mechanism to check for either.
A better way might be to check whether the environment variable %OSPL_HOME% is set. This variable is typically added to the environment by the OpenSplice installer; it points to its installation directory.
This answer is based on previous experience with the product. I do not have access to any current version, so the installation process might have changed.
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.
i have a .msi file . i want to add functionality in the installer.
i want to add
License Key Condition ,when someone try to install the application.
i don't want others to use this application. Only for those who have key for this software.Please help me if you can. Thanks
This question needs some improvement and clarification I think, but I will attempt an answer.
The application itself should be designed to allow license keys to only be accessible for certain users. Generally this involves storing the license in HKCU rather than HKLM. You cannot really change this in the setup, it is the application that will expect to read the license key from a predetermined source. Some applications are able to store license keys both per-user or per-machine - it all depends on its design. What application is this?
One way to "emulate" this for applications that only register the license key per-machine (for all users), is to remove the shortcuts to launch the application for users who do not have rights to use the application. This can involve installing the MSI "per-user", but it doesn't always work as intended.
It also depends on how you will distribute this software. Does it get installed remotely from a deployment system such as SCCM, or will you install interactively on every computer? If the latter is the case, you can install as the user who will use the application, and check if there is an option called "Install for current user" (or equivalent). If you deploy remotely you should create a transform to set the same option (install for current user) and invoke the install via SCCM whilst that user is logged in.
Where does Linux fit into this equation? Are you running Wine or some emulation software?
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.
Is there any way to programmatically alter the AppName in Inno Setup? Perhaps a registry value that can be set towards the end of the installation? My customer needs to be able to install multiple instances of my application with slightly different behaviors, and it would be ideal if AppName could be altered to during the install accomodate this (note that versioning is a separate consideration).
I'm afraid that 'AppName' is a required scripting directive and cannot be changed after your Inno Setup script is compiled into an installer.
It seems strange that you need multiple instances of your application installed on the same machine that each behave slightly different. Why is this necessary? What does this accomplish? I'm willing to bet that this should be addressed instead of modifying your Inno Setup installation script.