I hope someone may be familiar with MakeMSI. I got the problem that my application needs to run a special runtime, whose executable I have as an MSI-File.
It's not a big deal to set the Custom Action to execute this file, after all files were copied to the harddrive, but the problem is, that no installation process can be executed, while another installation process is running ... I tried to set the custom action after the installation process is finalized, but this is not allowed ...
Does anyone have experience with that or knows a way out?
I'm very thankful for all well-meant and helpful answers, so thank you in advance!
You can't run two concurrent MSI installs, that's the issue you've found. It seems like this other MSI might be a prerequisite, like the NET runtime, C++ support, SQL Express and so on, and these get installed with a prerequisite installer that runs before your install, a bootstrapper.
Alternatively, if this special runtime is only for you (and not all users of the system) and if MakeMsi can generate a merge module then make a merge module and include it in your MSI build like other runtime merge modules can be included (such as .msm files from Microsoft).
Related
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I would like to know how can I detect if help file is contained in setup file for windows platform application (msi or exe). Is there any method to get this information without installing the software first ?
Of course setup file can be created by many setup makers like innosetup, installshield and so on. So I wonder if there is some universal method to solve this.
For an MSI based install it would be very easy. For example you can use the Microsoft.Deployment.WindowsInstaller interop via C# to open the MSI as an InstallPackageClass then access it's Files collection to see if it contains the file you care about.
For a Non-MSI based install, there is no universal way and in most cases, no way period. See, that's kind of the point of MSI: to have a standards based package rich in meta data to be able to see what it's doing. When you do some proprietary script driven installer you lose that openness.
If it's a MSI file, open it up using Orca, and you can view file names.
For both of them, you should be able to do an administrative install, which would extract the files, but not register anything. Depending on where the exe came from, doing an administrative install changes, since each vendor(installshield, innosetup, etc) has their own way to run an administrative install.
for a MSI it's simply
msiexec /a <msi_filename>
For an exe you'll have to look up how to pass the /a argument.
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
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.