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.
Related
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
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?
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.
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.