I've been looking at various different ways of making an installer (see How to create a robust, minimal installer for Windows? for details), and I've run into the same thing in a couple of them (WiX and the visual studio installer creator); there doesn't seem to be a way to say "When you build the installer, include every file matching c:\somefolder\*.xml".
I can go and select *.xml and add all the files that match to the project at once, but then if I add another .xml file to my program later, I'd need to go and add that to the installer myself.
Is this a core limitation of windows installer, that I can't just tell it "sort all the XML files in this folder out and don't bother me about them"?
WiX toolset contains an utility called Heat. It can generate the WiX authoring for you based on your needs. The output can be further transformed by XSL templates (-t switch).
Hope this helps.
InstallShield also has this ( see Dynamic File Linking ) but honestly I don't like this pattern in general. It's non-deterministic in nature. I speak from 14 years of experience when I say that if a file is added or removed from my application I want to explicitly add it or remove it from my applications installer. Any magic to automate this has always bitten me in that it takes what should have been a build time error and turns it into a run time error.
My best practice is to write some automation that compares what was available to be consume against what was consumed by the installer. The two lists must match 100% or otherwise fail the build. When the build fails you must choose to either add the file to the installer or cease to archive the file to the directory. With the right tooling, it's trivial to add a file to the installer and the result is 100% accuracy of developer intent being applied to the installer.
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.
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
I'm currently trying to make a download/install file for a CD, and I've never done this or written any type of coding before so I'm somewhat at a loss. When we last created an installer package (I wasn't employed yet) we used InstalShield, but that was decades ago, and we can't afford the 500$+ price to get it again.
Currently I'm trying to work off the old download package we have. There is the Windows Installer Package (made by InstalShield) called CD Cat v6.msi, and then another file called CDcatv6.exe (which launches a window for the customer to browse options) and then a file called Data.cab which has all the files for the entire catalog in it.
I was thinking perhaps I can just replace a lot of those files with the current information. Replace the CDcatv6.exe file with my v7.exe file (but change the name so its CDcatv6.exe) and then replace all the files in the Data.cab file with the current ones. But that's turning out to be a huge issue.
I did a bit of searching to learn what a .cab file was, and downloaded the Cab File Maker 2.0 (after quite a bit of searching!). I'm having a difficult time using it though, as it wants all the files that I put in it to make the .cab to be in .ddf format. I have no idea what that is, much less how to make it. I tried using 'save as' to do it, but since all the files I need are PDF's there's no option for it and I cant export the files to it either.
I tried looking at other ways that people made Cab files, but I don't know many of the file types or programs their talking about. I'm not a programmer by any means, but I have to learn quick I guess, so any information on how to do this will help greatly. Is it even possible to replace all the files seamlessly and have it work properly? Or is there an easier way to create a fill that the customer can click on and have it download to their desktop?
I don't think simple editing of Data.cab will work. There is installer logic stored in other InstallShield files. It could work if and only if the file set is the same, I mean no files changed its names, no new files added, no new registry entries required etc.
To create a CAB file, use cabarc.exe from Microsoft Windows SDK.
Creating a brand new installer may be a better option. Look at this tools for creating installers:
Advanced Installer
NSIS
WiX toolset (with tutorial)
You best solution is to use dark.exe (part of the WiX toolset).
This will enable to you decompile the MSI and CAB files, edit the installer source as XML and then recompile this into a new executable. Unfortunately this route is not for the faint of heart and what you save on price will cost you in time.
I'm curious how your company created an MSI decades ago, but Sasha is right about time and money trade-offs. However if you're working with Visual Studio, you might try the InstallShield Limited Edition for Visual Studio. It may have enough capabilities to suit your needs.
Thanks for pointing to CABARC, that looks exactly what i was looking for, due to information on:
https://learn.microsoft.com/en-us/previous-versions/bb417343(v=msdn.10)?redirectedfrom=MSDN#top
That make me look how to download it, but i found this post:
Where can I get the cabarc utility?
Where it explains CABARC may be obsolete and there is another utility called MAKECAB that cames with Windows 11, i had try it at command line and it is there.
Thanks a lot.
hii,
well i develop a setup.exe(bootstrapper) using GenerateBootstrapper.Bootstrapper to load my msi file after check and installing prerequisites.It perfectly running if i make ComponentsLocation
*) either "HomeSite" to download prerequisites from the microsoft and install.
*) or "Relative" to take the prerequisites at the same location where my application exist and install.
But in my scenario i want that when i run setup.exe(bootstrapper) it first check component in the location where my application exist and IF it's(component) is not exist there then it download them from vendor's URL(Microsoft).
Is it possible with wix v3.5???
This is not possible with the msbuild GenerateBootstrapper task.
As for the burn.exe tool in wix v3.5, it is still in development and currently undocumented. The wix.chm in the latest weekly release does not yet mention burn.exe at the time of writing.
edit: The reason that it is not possible is that it is not really useful. I imagine you have two different deployement scenarios:
the software is delivered
on a CD or DVD with all the
prerequisites included
the software is
downloaded as a zip archive and the prequisites are
omitted to minimize download time
You need to prepare two different file trees anyway in this case. So just create a different bootstrapper for each scenario.
edit2: you can also create the two different bootstrappers, then create a third setup.exe which is a simple application that determines which of the two boostrappers to launch.
I have set up cruisecontrol.net cs for my project that has a number of modules and components that get build and get stored in folder by date on the build machine.The thing is that I need to make setup for the application(wpf non web) and the thing is that since there are a number of module and different solutions that build and finally make the product (dlls) etc.Any suggestion on comming up with a setup strategy that will create a nightly setup and also what setup package to use (something simpler or according to you that would take less time) I was planning to install something on the build machine that would pick up the files from the folder (what folder?) and make the setup...
A link to illustrate the point is Firefox's nightly build.
Any advice guys
Thanks in advance.
I am finding that this system is working pretty well for me. I assume VS 2005/2008 and C#, but the same principle works for other compilers and languages just substitute your own flavoring.
Using CC.NET
Check out all source with scheduleTrigger, if multiple locations use
Use MSBuild to build each solution that is required (assuming VS 2005/2008), or nant, or whatever build tool works best for compiling your component projects
Use MSBuild to create WIX installers, though I have also used MSBuild to create InnoSetup and Wise Installation Studio installations
Use MSBuild to update the AssemblyInfo.cs files for any projects that you want the build script to control
Use your source control command line to check-in updated AssemblyInfo.ca files
Finally use MSBuild to copy your output installer to a new folder in your drop server. I use the time stamp from the primary product executable to make a timestamp along with the generated version number to name the folder (../Builds/Product/v.M.m.r.p - DATE TIME/)
I also like to generate a build notice email at the end.
As for installer recommendations, there is a trade-off.
For fast generation, use a script installer like NSIS or Inno Setup. The drawback is not being Windows Installer compatible.
For Windows Installer products, using Wise or InstallShield are faster to generate the first time, but expensive tools and I find the maintenance on my installation scripts is high. Using WIX tends to be much more expensive the first time (learning curve + angle bracket-tax), but then easier to maintain as it is all XML and the command line tools are easy to use.
I have had some success with installation bundling with Inno Setup as Windows Installer bundling and chaining (at least for Windows XP) is a real pain.
We used Visual Build and Wise for our installer creation and find that highly intuitive and easy to create the set ups with. The actual CC.NET project does a few things, first thing is it checks to make sure all of the needed parts have been built successfully since the last time we created an installer (we allow installers on demand as well as scheduled every night) if they haven't been build successfully we rebuild all the componenets, once they have been (or if they already were) built successfully we then call VisualBUildPro and let it create the installer. Visual Build Pro, handles all the copying and the calling of Wise for the actual installer. Once the installer is created we publish it out to the destination where everyone expects it to be. We also have modified the XSL for the email publisher on the builds server, so everyone gets a link to the newest installer once it is published.
A few things about the nightly builds if you can you should try setting up a symbol server and have every installer upload symbols with source code information up to them. This is also a good point to have any documentation (D'Oxygen; SandCastle) Create and the time to run your FULL suite of testing that you have available.
Take a look at WiX. This toolset allows the setup project to be defined in XML form, and then generates the msi from this XML. The fact that the project is defined in XML gives you alot of flexibility to modify this XML on the fly during the build (if needed).
It integrates with MSBuild - see this article, and also works well with NAnt - see this article.