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.
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.
Greetings,
I'm trying to figure out how to pull off the following scenario with MSBuild and Visual Studio 2010.
I have a set of three services that I would like to install. The default installation directory should vary with the build (qa, uat, and production).
To add another fun wrinkle to this whole thing, sometimes the uat environment can be pressed into service when we are at peak load, so each build of the service will need to have a different name. It doesn't happen frequently, but it is on the list. How can I configure the service installers to alter the service name dynamically?
I want to be able to create MSI installers for the services (for whatever the current build is). I have an existing and extensive MSBuild script for the various websites I'm working with already, but I'm a little unsure how to proceed with making the services work.
Obviously, the configuration files for each service build will be different.
I've added installer classes for each of the services.
I guess I'm a little confused with how to start this, so any help I can get would be awesome. I had considered simply hardcoding the different service names and using conditional compilation statements to set them, but I don't think doing so is a particularly clear way to go about it all. Any thoughts?
It might be simpler to just zip up the service bits during the build and deploy with MSBuild using or MSBuild Extension tasks. You would put your environment specific configuration data in an msbuild .properties file (mylocal.service.properites, qp.service.properties, uat.service.properties, etc.). This is the way I deploy services.
note: the property file would contain things like your db connection string, TargetDir, ServiceName, etc.
Service names are specified at install time see 'sc', 'installutil' or the WindowsService msbuild extensions pack task snippet below. This means you can copy the same service bits everal directories and install each with a unique name (e.g. QAService, UATService, PRODService).
note: I want to reinforce that the service name is a deploy-time consideration, not a build-time consideration.
<WindowsService TaskAction="Install"
ServiceName="$(ServiceName)"
MachineName="$(TargetServer)"
ServicePath="$(FullServicePath)"
User="$(User)" />
The approach is similar for MSI installers. I assume your installers prompt for all necessary environment specific configuration data... All [decent] installers have a way to provide answers from a file versus using the installer interactively. So, as above, you create one answer file per environment and feed it to the installer on the command-line.
You do not want to do this at build time... and thereby have a separate installer per platform. Was forced to do this with an ancient version of the wyse installer. Made me sad. You want a single MSI installer that can be run in every environment (given the environment specific answer file).
Details of the MSI command-line and answer file format will vary by product. What installer package are you using?
Cheers,
/jhd
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.
Due to severe limitations of the Microsoft Windows Installer (MSI) system it is required to create a bootstrapper in order to install multiple MSI files (due to pre/post-requisites). However, this introduces an distribution problem because you now have multiple files that need to be included with the distribution. There are of course multiple ways to distribute this as a single file.
1: An archive
You can put all the files into a single archive that users download. The obvious choice for MS Windows is of course a PK-ZIP archive. But this is not very user friendly. Users will first have to extract the archive, and then run the bootstrapper (which would be called setup.exe).
2: A SFX archive
Instead of distributing an plain archive file you could wrap it into a self extracting archive. Executing this SFX archive would prompt the user to extract and/or run the contents. But this adds yet another prompt to the whole installation process (#1: SFX prompt, #2: bootstrapper prompt, #3: main installer prompt). This is also not very user friendly, as it increase annoyance due to multiple prompts.
3: Single file bootstrapper
Of course there is the option to embed all the extract files into the bootstrapper. This is probably the most user friendly for a normal end-user. However, this is less friendly for system administrators, because usually bootstrappers are less manageable than the MSI files. An admin would rig the system so that all requisites are also installed when the main MSI is installed, thus the bootstrapper would not be needed.
4: Other?
An other unlisted method?
So what do you think is the best way to distribute a installer for MS Windows software that requires a bootstrapper?
We provide a single file bootstrapper for retail distribution and all single-user installations.
Volume licensing customers (e.g. 10+ seats) receive one (or more) MSI files along with instructions and a list of prerequsites that must be installed before our application will run (which slightly differ between XP, Vista and Win2k). The EXE blocks installation if the prerequisites are not installed, the MSI will permit installation under the assumption that the sysadmin knows what they're doing and might be installing the prereq's at the same time, before the next reboot.
Basically the single bootstrapper is for non-sysadmins, people who want a single click solution. System administrators and corporate IT support who prefer more fine grained control over their installation are happy for multiple files, even if it means more work for them. The single EXE file is available publicly, the instructions + multiple files are only available by contacting our sales team.
This method gives us the best of both worlds, as well as the ability to provide different default configurations for home and corporate customers - hints, tips, splash screens, auto-updates and welcome dialogs are all disabled by default for corporate installations but enabled for "single" users.
We use Wix to create MSI files which is hugely flexible and can easily be automated with build scripts.
To chain multiple MSI/EXE files together for distribution via single bootstrapper I would highly recommend DotNetInstaller. I'm in no way connected or affiliated with this product, but it has been a lifesaver on projects for generating highly configurable bootstrappers in unmanaged code.
I wrote up my recent experiences in developing a multi-language MSI and bootstrapper using these technologies here. This talks through the process from start to finish. Using DotNetInstaller you can download and install dependencies from a URL on demand, or embed them directly within the bootstrapper with ease. I did also consider WIX's own SETUPBLD bootstrapper generator and the GenerateBootStrapper MSBuild task but they are pretty basic. That said WIX 3.5 Burn utility is currently in the pipeline and could be a pretty decent alternative once it's released.
Regarding: 1: An archive: 2: A SFX archive
You could use a self-extracting .ZIP that automatically launches a Setup.exe. WinZip offers this support inexpensively. That way, it would be more customer-friendly. It can be configured to launch the bootstrapper without a prompt.
Regarding: 3: Single file bootstrapper
At the risk of sounding like an InstallShield salesman, InstallShield 2009 will take care of everything you're asking about -- it smooths over the MSI shortcoming of needing a bootstrapper. You could use the Release Wizard to create a single-.EXE all-in-one bootstrapper. Or you could create a web-deploy setup that is very small and then downloads the payload from a web site. Or you could put different features in separate .CAB files, and the user only needs to deploy those CAB files corresponding to the features he wants to install. InstallShield comes bundled with dozens of prerequisites ready to add to your Setup.
Depending on your siutation, MSI v4.5 and 5.0 might help you -- they have native support for multi-package transaction chaining. Of course, depending on what OSes you support, you may still need a bootstrapper to make sure the right level of MSI support is present.
I had a similar problem where I needed to distribute some optional support software, MSI installer, and another file just incase the MSI file needed it. I basically created a native application to handle the whole process. I wrote a blog about it here (http://blog.foldertrack.com/?p=45)
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.