I thought this would be somewhere on the Web, but I couldn't Google it:
Given the complexity involved in creating an MSI package (compared to NSIS, InnoSetup, etc.), what would be a compelling reason to go through all the mess (using MSVS's crappy setup project wizard, learn a whole new langauge/ecosystem just to make the installer (WiX), or pay heavy license fees (InstallShield)) for the sake of making an MSI installer?
Would be nice to have real world opinions or experience (even to prove that MSI is really worthless) other than the obvious MSDN page, for instance :)
I don't think there is one prime advantage for all situations. Here are some things I like about it, vs other kinds of installers:
Install logic and code is contained in a database, which is in an accessible format.
I like this a lot when I'm debugging. Rather than rebuilding your installer, you can directly edit the database with a tool like Orca (free database editing download from MS), then run the install again to test your changes. Update your custom code, temporarily condition something out, change the order of operations, whatever you need to do.
Patching. The Installer service and its corresponding tools know how to create patches containing deltas of updated files, rather than complete files. It allows maintenance sizes to remain reasonable.
Administrative Images. The installer can create an administrative image. If you've generated patches, you can apply the patches to the administrative image, and new installations can then be run from the administrative image rather than the original installer. Like slipstreaming patches in OS images. If you're pushing your app out to a large number of machines, it's pretty cool to not need to push a bunch of patches out post-install.
Other interesting features include transforms, run from source, detect and repair, component sharing, and so on.
Take a look at this:
https://serverfault.com/questions/11670/advantages-of-using-msi-files
MSI (or ClickOnce) was required to obtain the Windows Vista Logo Program (Microsoft official certification). I believe this requirement was removed with Windows 7, but it's still easier to get certification with MSI (see here).
You don't need to buy any expensive 3rd party installer package though. If you're going for MSI, I suggest you use WIX and learn it. Once you're familiar with it, it works pretty well.
Another good read is:
Windows Installer: Benefits and Implementation for System Administrators
I've been a full time setup developer for 14 years. My first 7 years were InstallScript Setup.exe style projects and my last 7 years have been MSI based. At first I resisted MSI and then after 6 months of using it I became a true believer in how much better it is.
I'm pretty certain that there are enterprises that require MSI formats to remote bulk install an application on thousands of machines. However I don't deal with such organizations so don't know for certain.
Related
I never needed to add an installer to my programs but I always wondered about Microsoft Installer (.msi or .exe installers). What tasks do they do?
They make the life easier for the user, but that's not all to it. I know they also deal with the Operating System in several aspects.
But before learning about installers themselves. I feel there's a gap on my knowledge on some prerequisite subjects related to this.
So, which subjects would they be? And where can I learn them? (Books, articles, videos, courses, ...)
And to be clear I'm not asking about how to create an installer (I can do it with Visual Studio or tools like Install Shield). But I'm more concerned about the prerequisite subjects I need to learn to proper understand and handle installers. Specially in what areas do they deal with the Operating System?
Installers are nothing special. They give this impression because they do a bunch of weird things that don't seem accessible to other apps. The .msi and .exe installers will self extract (take a portion of the file itself and copy it to another file) or they will download other files from a server. The .exe and .msi files are thus normal executables that the OS recognizes due to their file extension as files that it should execute.
Each file extension has a default app to open them. When you open a file, its default app is started and the path to that file is passed as a string to the main function of the app. That way, the app can parse the file and show the content of it to you (similarly to compiling a program).
Other things like creating desktop icons are available with some dlls native to Windows and some other libraries that call in those dlls for higher level languages like C#. Quite simply, you create an average window like any other, you extract the app being installed from the same file to Program Files and you're good minus some other minor details. The apps available are really just to make your life easier.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
I have minimal exposure to RPM, Windows installer mechanics, and WIX. That said, I'm interested in making a cross-platform installer tool (Linux, Windows) that supports upgrading and downgrading (versiona and patches) of my own product. I don't believe this is a topic to be approached lightly; I would like to learn the science of the art (or the art of the science). If I succeed, and build a minimally successful installer tool, it would have these features:
does not depend on a platform-specific tool (such as Windows Installer).
reads XML or a declarative syntax to fulfill installation requirements.
attempts to minimize steps to upgrade or downgrade one of my products (rather than requiring a complete uninstall and re-install).
does not require knowledge of interim product versions, in order to jump versions (i.e. can upgrade one of my products from version 1 to version 3, without passing through version 2).
I'm convinced that "the key" to achieving this goal is by seeing versions as a "point A to point B" problem, which implies that A and B are described by two XML "version" documents that hold info about all the parts and actions (files, or platform specifics such as registry entries). My installer tool would "join" or compare the two documents and determine a minimal set of changes to transform A into B. To some extent, I believe this is precisely what Windows Installer does.
Of course there are further complexities, but that is the point of this post. Where is "the bible" of information on this topic? Remember, I want to make my own installer - not use a platform-specific one. For those who care, my products are usually written in C++ or C#.
Or perhaps I should study something like Steam which is cross-platform and has "automated game updates" as part of its capabilities. In my case, the problem of online deployment is already handled. It is just the final installation step I'm examining. Does Steam use native installers (such as an MSI)? If yes, then that is not what I'm looking for.
In short, what path should I pursue to become somewhat competent on the science of this topic?
I'm not an expert and others can give you better answers but...
Don't declaratively list steps required to install your product - You'll end up making assumptions which will eventually prove wrong. Instead, you should be looking at defining the final state of the installation and let the installer worry about how to make that happen.
Another consideration is that being downgradable may involve huge complications depending on your product - Would it have to down-grade database schemas / file formats / ??? In short, every version of your app will need to be both fully forwards- and backwards-compatible (or at least fail gracefully). Also consider the scenario where V1 of your app stores settings in a file. V2 comes along and adds more settings. You downgrade to V1 - What should it do when changing settings? preserve the V2 settings? dump them? Do some of the V2 settings change the impact/meaning of the V1 settings? Are these decisions to be made by your app or your installer?
Anyway, all that aside, I'd say you need at the least:
A central server/farm with complete files for every version of your App and some API/Web Service which allows the installer to retrieve files/filesets/??? as appropriate (You may be able to tie this into a source control system like svn)
Some way of specifying the desired post-install state of the system in an environment-agnostic way (Think install paths - /usr/??? - should the map to C:\Users\??? or C:\Program Files on windows? Also don't forget it might be a 64-bit machine so it could be C:\Program Files (x86).
A very clever installer written for multiple platforms with as much code re-use as possible (Java, Mono, ???)
The installer should do (simply):
Determine the desired version of the product.
Download/read the appropriate manifest.
Compare the desired situation with the current situation (NB: What is currently on the local system, NOT what should be on the system according to the current version's manifest)
Generate a list of steps to reconcile the two, taking into account any dependencies (can't set file permissions before you copy the file). You can make use of checksums/hashing/similar to compare existing files with desired files - thus only downloading the files actually required.
Possibly take complete backups
Download/unpack required files.
Download/unpack 3rd party dependencies - Later .Net Framework Version/Similar
Perform install steps in atomic a manner as possible (at the very least keeping a record of steps taken so they can be undone)
Potentially apply any version-jump specific changes (up/down-grade db, config files, etc.)
verify installation as much as possible (checksums again)
None of this addresses the question of what to do when the installer itself needs upgrading.
A technique I've used on Windows is that the installer executable itself is little more than a wrapper with some interfaces which loads the actual installer dynamically at runtime - thus I can move files about/unload/reload assemblies, etc... from within a fixed process that almost never changes.
As I said above, I am definitely not an expert, just a novice who's done some of this myself. I sure you can get more complete answers from others but I hope this helped a little
We've decided to create a custom bootstrapper for our deployment solution. We are currently re-writing and re-designing our deployment strategy for all of our products. Sadly, none of us are deployment experts.
Here's what we have so far:
A. The MSI packages will be authored in InstallShield. We will use whatever feature Installshield offers (IIS integration, COM registration, Registry, etc). The dialog's created by InstallShield will not be used (that is what the bootstrapper is for). The MSIs will be installed silently.
B. Whenever we need to write CA's for stuff that InstallShield can't handle, we will be writing them in managed code (C#) using DTF. We will be creating a "Custom Action Framework" that will "standardize" how we use custom actions.
C. We will create a custom bootstrapper (the "setup.exe") in C# to "handle" the installation.
We have decided to go with a multiple MSI approach and use MSI transaction to "chain" the installation from the boostrapper (inspired from Office 2007 installer)
The boostrapper that we are envisioning to create is inspired from Visual Studio's and SQL Server's bootstrapper. The boostrapper will be responsible for the following:
Prerequisite installation: Each application require a pre-requisite. These pre-requisites are listed in an XML file placed on the same folder as the MSI (inspired from Office 2007 installer) along with other metadata. Depending on current state of the system, the boostrapper will decide which pre-requisite to be installed or not.
Feature selection: We are planning to structure the "internal" MSI's feature in such a way that it will not be appropriate to be displayed right away to the end-user. We will have feature labeled as "Core_Files", or "Vista_Only" or "64bit_Only". Depending on the metadata on the XML file (on item 1) and the target system, the bootstrapper will be responsible in "populating" a "feature tree" that the user can customize (also inspired from Office 2007 bootstrapper).
Pre-installation Checks: The bootstrapper will be responsible in checking if the system is ready to receive the installation. For instance, if a machine needs to reboot prior to installation or if the user needs to manually install a service pack, patch or a windows component. Anything that needs to be done that needs user intervention should be displayed here. Think of it as a check list (a listbox) with checks and exes. (Inspired from SQL server's bootstrapper). The "rules" will be written in C#.
Application Configuration: For application that needs to be "configured" prior to installation. These "parameters" (user configuration) will be passed to the respective MSI via MSI Properties.
Actual Installation: The bootstrapper will then perform the installation. Proper "transaction" should be observed when necessary. All "products" that should be grouped together shall be displayed as one product in Add/Remove Programs (by messing with the ARP entries). Also, proper progress shall be reported by each MSI being installed.
-- That's what we have so far.
I think there are a couple of out-of-the-box solutions for creating a custom bootstrapper like dotNetInstaller and BMG. We've look into it but it's not as flexible as we've hoped. There's also BURN but we're not sure if it's ready for primetime.
So here we are... we've decided to create our own custom bootstrapper.
Question:
Are we crazy? Shouldn't we be creating our own bootstrapper? Which ideas listed above are not realistic? Is there a better approach?
Any input regarding our situation will be greatly appreciated. Also, if you have any questions, please don't hesitate to ask.
Frankly, Burn isn't going to be done for at least a year. You already have InstallShield and IMO it has the best off the shelf bootstrapper currently available. I'd scope your requirements back and make it fit the box. Pretty much everything I read from you can be done using InstallShield if you learn to push it to it's limits.
I would go for Burn anyway or some already existing solution.
I'm sure that after some time you'll face new problems that you can't now really imagine.
If you face them, that means that Burn's developers have already faced them and probably got them solved. If not, Burn has a large community that will fix the potential bug faster than you.
Focus on the software you're developing, not on writing installer/bootstrapper.
If I were in your shoes, I would give a burn a try. I'd get me a couple of days and see if it meets my requirements.
I'm trying to implement a version control system, but as most of us know designers don't feel comfortable with version control systems. I'm looking for a solution mostly for our designers using Photoshop, Flash and other design tools.
It's not a big deal to use a version control system, like VSS 2005, with our frontend and backend coders, but we have some serious problems with our designers. They mostly refuse to use version control systems, and they are right at some points, mostly on productivity level. They mostly work on more than one file, and on more than one application like Photoshop and Flash.
I don't know if version controlling is the right answer or not. Maybe we have to implement a backup system, but there has to be a versioning system, I think. I and our designers are very tired of doing the same thing or going back to the previous designs over and over again.
It would be wonderful to know how digital agencies overcome this problem. If version controlling is the answer, please share your tips on how to make designers comfortable with version controlling.
EDIT 1: Maybe it would be great to have a solution like Dropbox, as it doesn't disturb you with check-ins/check-outs. All you have to do is to open up a file, work on it and save it, the rest is handled by Dropbox.
EDIT 2: We are on Windows, so no chance to implement anything other than Windows support :(
Thanks...
I haven't actually ever done this with graphic designers, but is it possible that Subversion's WebDAV support might work for them? You can mount a WebDAV share as a drive under Mac OS X and Windows XP & Vista, I believe. Each save becomes a new revision in the repository.
And as for your second, hidden question: Yes, you do need to implement a backup system. At least if you value your data.
Adobe has it's own version control, Version Cue, which is bundled with the Creative Suite package. http://www.adobe.com/products/creativesuite/versioncue/sdk_overview/ Apparently, Eclipse can plug into this. I haven't tried it extensively, but I know it integrates nicely into the file dialog in Creative Suite.
NOTE: Version Cue has been discontinued by adobe after the release of CS5:
http://www.adobe.com/products/adobedrive/
Adobe Version Cue maybe?
You might want to try subversion because there are plugins for windows explorer and max OS X finder. integration with the filesystem has been a big help for me on projects where non-developers had to work with source control. This includes projects that have had designers.
Another key thing that helped was having a good directory structure for the files the designers and other non-developers worked with.
I just came accross ConceptShare and it's pretty great...it's not automated version control but you could use it for that and it's a great way to collect and document feedback.
You can try Subversion (installed on a local or remote server) plus Adobe Creative Suite plug-in that would face the designers - Pixelnovel Timeline
It's compact, has previews of all versions (submitted via the plug-in), works for Photoshop, Illustrator & InDesign.
If developers also use Subversion, everything (code & design) can be kept in one place.
Instead of trying to integrate a version control system with lots of applications on different operating systems, you might want to have a look at copy-on-write file systems such as http://en.wikipedia.org/wiki/Ext3cow. That way your designers won't even notice a difference; all they will have to do is save their work to a network share on a linux/samba server using ext3cow.
I'm both a designer and coder. I usually version control code (text data) with git, and simply use "save as" with a version name for graphics (binary data). And I run Apple's Time Machine on top of all that, for safety.
To me, version control on graphic files would just be a burden. I'd have to roll back to see changes, and you wouldn't even get one of the great features of version control: see the changes you did in a specific commit just by looking at diffs. The log feature is nice though, to see how you progressed in time, and notes, but to me personally it's not worth it.
Take a look at Perforce - it has a plugin and tools that allow you to use it from within designer tools such as Photoshop, its also super fast and integrates well with Visual Studio - runs on Windows as well as Linux
What I did once was create a "Snapshot" shortcut on the desktop that added and committed everything from a specific directory.
If every designer commits to their own branch (trivial with a DVCS but easy with SVN too) there will be no conflicts, and the cross-branch merging can be done at intervals by someone who isn't afraid of it.
I've been having my eyes on GridIron's Flow for a while now. It looks like a competent version control suite that has some neat asset management features such as visualization on graphics between versions and relationships between different assets. Flow has support for handling files for adobe photoshop, illustrator, flash etc. However as of now (early january) GridIron hasn't released Flow yet other than having to announce the beta program.
Most digital agencies that I know of that mainly do web development use Subversion for version control. To avoid conflicts on image files an artist will lock the files he or she will work on. That way, another artist won't do the mistake of overwriting changes. This requires some coordination among artists and devs so that noone steps on anyone shoes. Also, if someone forgets to unlock, there is the possibility to break locks.
If you're into distributed version control you might want to take a look at Mercurial as it has good support for Windows and has some neat cheat sheets. The Ruby kids are using git but is rather lacking in Windows.
Before using version control with artists, at least make sure they know the basics of version control and let them fool around with it in a sandbox. Also make sure they've set up some basic rules of conduct when collaborating with each other and interacting through version control (i.e. ways to make sure they don't destroy each others works or step on each others toes).