How can I create a Single InstallJammer setup for both Windows and Linux? I have a sampleProject with the default components.I need to add a component that checks the OS version and proceed according to the result.
Please avoid giving the installJammer and TCL scripts tutorials as I have already read both of them.
Go to the General Information > Platform Information section, expand the platforms you want (e.g., Linux x86 and Windows) and make sure to set the Active property to Yes on each one. Have a look on other properties as well to be aware of the values and maybe customize something to fit your needs.
On the Install User Interface > Install Panes and Actions is where you can do the "conditional" behaviour. Once you create an Action Group you can set it's Condition property by clicking on the three dots in the end of the input line. A Conditions for... window will be shown, and there you can add a new Platform Condition. Set the advanced property Platform of this contition to the specific platform you want that action to be executed.
As an example, you may want to create different actions to copy different file groups, a group of Windows specific files, and another group for Linux specific files (and you can also define a shared files group).
Go to the Run Build > Build Installers section and enable those platforms you want it to generate build installers.
Related
I have a written a setup script for my own Windows EXE using InstallShield Premium 2012. My EXE, however, ultimately relies on the presence components provided by a Microsoft EXE called AccessDatabaseEngine.exe.
In order to run this AccessDatabaseEngine.exe executable with my installation, I added it as an embedded binary resource then used the Custom Action Wizard to launch AccessDatabaseEngine.exe as "Deferred Execution in System Context" as an "After PublishFeatures" Install Exec Sequence. This worked as expected: The AccessDatabaseEngine.exe launches after my Setup completes most of its work.
However, once I see the UI for the AccessDatabaseEngine.exe and acknowledge its UI prompts, I see "Error 1500", which states that another installation is in progress.
I understand that two MSI packages cannot be running at the same time unless you tweak the registry to allow it, which I do not want to do on my customers' workstations, which are Windows 7 32-bit machines.
I would like to successfully implement one of these options:
OPTION ONE: Have the user launch my Setup.exe program, which will at some point launch the Microsoft AccessDatabaseEngine.exe without generating any error message. I just don't know how to do that without causing the Error 1500 to appear...
OPTION TWO: If it's possible to somehow wrap my Setup.exe along with Microsoft's AccessDatabaseEngine.exe into a single EXE, then I could provide my end users with that single EXE and it would first execute the embedded Setup.exe and, once that's done, it would execute AccessDatabaseEngine.exe.
I realize that I could implement OPTION TWO as a .bat (batch) file, but I want to deliver only a single EXE to my end users and have that single EXE install everything needed for my software to operate properly.
Any ideas?
What you describe here is exactly what InstallShield's prerequisites are designed for. Launch the prerequisite editor from the Tools menu and add files, command lines, and conditions that carry, install, and detect the installed footprint of the AccessDatabaseEngine.exe; then use the redistributables view to include that new prerequisite in your project.
Once you've done this correctly, InstallShield's setup launcher will check to see if the prerequisite footprint is present, and, if not, it will run the prerequisite as described. Since this is done before it launches the main .msi file, it avoids having two .msi files installing at the same time.
See Defining InstallShield Prerequisites, Creating an InstallShield Prerequisite, and Setting Installation Conditions for an InstallShield Prerequisite in the help for more details. For defining where these end up in your built installer, see Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level or Specifying a Run-Time Location for a Specific InstallShield Prerequisite. Note that when dependencies of a prerequisite are added, they often use the release-level setting, so unless you really want a mix of locations, you're best off specifying this in the release.
Apparently there are TWO settings that determine if a prerequisite ends up in its own, separate folder (a release folder below the folder that contains setup.exe), or if it gets embedded into a single setup.exe file.
The first setting is available in the Installation Designer under Application Data | Deliverables. Find your PRQ prerequisite listed there with a check mark, right click it, and view Properties. You will see a Build Location dropdown--one of the options is Extract From Setup.exe. That's the way mine was set.
But then there is SECOND setting, and that's in the Installation Designer's Media section, under Releases. In my project, I had a Releases root, then a PROJECT_ASSISTANT branch, then a SINGLE_EXE_IMAGE branch. I left-clicked SINGLE_EXE_IMAGE and viewed its property sheet. In that list is an entry near the bottom of the list that says Setup Prerequisite Location. Double-click the right column (where its value is listed) and you will see a selection there that also says Extract From Setup.exe.
This second setting OVERRIDES the one specified in the deliverables section, and that's why it wasn't working as specified in the prerequisite setting. That's because I was using the "Copy From Source Media" setting.
So if you have multiple prerequisites and you want all of them to be included in the setup.exe then it's okay to use the Extract From Setup.exe settings. But if you prefer to configure where the prerequisite ends up, then choose the Follow Individual Selections options in the Releases' Setup Prerequisites Location section and then ensure that you've selected the correct option for each of your prerequisites.
Even if others had suggested doing this in previous answers, those explanations weren't clear to me and I wasted a lot of time before ultimately discovering what's actually going on.
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
We have an application consisting of multiple components: main app (installed in program files) and multiple datasets (located in AppData). In the future there will be available (also) individual updates for one of components. What I want is to create one installer for all components, but create multiple uninstallers for components accessible from Programs and Functions. I've looked at Inno Setup, but I think it doesn't support this. Also tried NSIS, but it looks much difficult to use.
Wouldn't it be just as well (or better?) to make it all one install/uninstall program. And it works by noticing which features are present? If none then your screen consists of check boxes with what you want and don't want, then upon running it again later you would uncheck what you want to remove, etc.
Is there a way to discover what installer tool does a product use? I mean, is there any way, checking the files properties or the processes running to discover what setup authoring tool (InstallShield, SetupFactory, InstallAware, Tarma, etc.) was used?
Thanks.
It's possible, but only if you are familiar with all these setup authoring tools. Most of them use custom installer properties, custom actions or custom tables specific only to them.
However, if it's a really simple installer these unique elements may not be used. So it really on a case by case basis.
What product interests you? Perhaps one of us can determine the setup authoring tool they used.
It's not bulletproof, but if you look under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Most products that leave a trace in the add/remove programs applet will have an entry under here.
If you open the 'UninstallString' value, that will include the path to an exe that is invoked to perform the uninstallation. If it's msiexec then you have a product installed by Windows Installer. Otherwise you might need to get hold of the exe and inspect the file's version resource to get a little more information. Note that this may give an inconclusive result if, for example, the uninstaller is a bootstrapper exe that daisy chains a set of .msi packages.
If you need to find out what MSI authoring tool was used to generate the MSI, you might be able to infer this from the summary information stream of the .msi package in the uninstallstring, but not every authoring tools fills this value in.
Properties of setup file -> Version (XP) or Details (7) -> Description, like
Created with Actual Installer
As alternative to above answers I would recommend to open installer's file in hex editor. Then do search for string containing 'install' or something like this. Usually near matched string will be name of program that produced installer package. For example, in my case this was a 'Smart Install Maker'.
I need to create a custom installer that supports French, German, Spanish, Italian, Polish, Russian, English, chinese (mandarin script), more languages to be added for a .net based application.
This installer also needs to be able to check whether the target system has got adobe installed or not. If the target system doesnt have adobe or is a lower version than required then it should install from the CD. if it does then bypass that step.
The installer also needs to prompt the user to browse to any location on the system to pick up a file which will be place in the installation folder.
The installer also need to register this program in the add remove programs list.
Is there a custom installer that can do all of these tasks or do I need to build an application from scratch for it?
Thoughts... ideas???
Thanks for your time...
Short answer : Yes, all those things can be done, most of them easily.
WiX or NSIS are probably your two best free options. NSIS uses a plugin architecture for most of it's functionality, but the plugins are text-files, so you should have no problems downloading them. However, if your company is "funny" about licensing, then check the relevant licenses for each plugin early on - most are completely free to use, but Legal can fail to understand this sometimes...
Please find below pointers to the relevant sections of the documentation, so you can get it downloaded (I feel your pain by the way!)
Language Support
See Docs
Allow user to select a file and copy it
You will need the InstallOptions plugin. This allows you to create an extra page in your install wizard which can prompt for information. It allows various controls, one of which is a file explorer control (search for FileRequest in the link).
To copy the file, you cannot simply use the File instruction, as that extracts and copies files from the installation media, and will not act on files on the target computer.
Instead, you will need a plugin - e.g. this wrapper around the WinAPI. Alternatively, use the CopyFiles instruction.
Register program in Add/Remove programs
This is standard in both WiX and NSIS.
Detect Adobe is installed.
NSIS has the ability to check if registry keys exist, or named files exist, which are the two normal methods of detecting installed programs.