Windows Installer

[Rod Widdowson]

As I mentioned on the call yesterday I want to start looking at creating the
Windows Installer soon, and there are several requirements we will need to
bottom out.  Although most of them will be to do with the deep and boring
mechanical details of Windows and Windows installers, many things are likely
to push back into the OS independent code and config (for instance metadata
segments, and pre-configuration for known LDAP setups) – this being
particularly important since in V3 I really do not want to have shadow
copies of mainstream files which need to be continually updated to track
mainline changes.  I’ll try and keep windows specific conversations separate
from general purpose ones.

I’m going to start on two tracks – I’ll try to capture some requirements and
design suggestions and we can discuss that in here.  At the same time I’ll
start on the more mechanical parts of the process that need little
discussion – the merge modules, the service, checking for java and so forth.

However as I precondition I have a couple of questions:

1) Where (in SVN) are we going to keep the installer source?

I would suggest that it goes into a subdirectory as a peer of all the other
idp-projects, but that we do not teach maven anything about it until we have
any specific windows code.  Or would we be better having it a maven aware
from day 1 (just in case).

2) (Windows Specific) How do we want to orchestrate the build process?  I
initially thought that we had four options

 - Batch File
 - Hyperscript
 - Within VisualStudio/MsBuild
 - Nmake

I’ve pretty much come to the conclusion that we have to use a batch script:

Hyperscript ties us to relatively recent OS versions and if we want to stand
a chance of other projects generating the merge modules they understand we
probably need to be able to build on XP/W2K3 (or W2K, if not WinNt 3.7)


We don’t need dependency analysis and the current Licensing model of Visual
Studio makes me feel that, unless we have to (as we do for the SP), the
project should stay clear of anything coming from that suite (You don’t buy
licenses to use the software any more, you rent the software on a yearly
basis as part of your “subscription”.  Don’t start me).  
For the same reason I would suggest that we stick to use VBScript for any
plug ins (although I'd prefer to use C/C++)

FYI Wix (the tool we use) is freely to use.

I’ll start on the requirements and design document and circulate a pointer
when it becomes sensible to.

/Rod