[wix-users] Suitability of MSI

Tue May 5 14:35:18 PDT 2020

I don't think Chef is declarative in the same way SQL and the Windows
Installer are declarative. In Chef you specify resources that are processed
top-down in a single pass and there is no rollback functionality at all. In
the case of Chef, the declarative nature of their syntax just maps to a
list of function calls just like in an imperative programming language.

Last time I looked at Puppet it had effectively the same design. I looked
at it again today for just a couple of minutes and it looks like they are
using or redesigned to match Windows Desired State Configuration. The
system I wrote once upon a time was a poor-man's DSC. Mine had multiple
passes so it could make decisions about what to do, similar to what the
Windows Installer does. I'm less familiar with whether DSC and Puppet work
similarly or just provide a bunch of functions that are callable as data.

Here is a summary of what the system should do for my definition of
declarative:

1. Declare the resources that should be installed.
2. Resources should be automatically removed upon uninstall.
3. During upgrade, resources should be replaced by newer versions in a new
version of your product and removed when the new version of your product
does not need them.
4. If an error occurs, replaced resources should be written back to their
original state and removed resources should be installed again.
5. If a product is already installed then a repair operation should
reinstall resources even if they are already present on the target system.

Notice I declared what I wanted only once in #1 and everything else comes
out of that. This is the goal.

The Windows Installer does all that for the resources it knows about. The
extension model is difficult because you need to think about #2, #3, #4,
and #5 when implementing an extension and that is hard no matter which way
you slice it.

I can't think of any other system out there that explicitly aims to do all
five. Quite often I see uninstall go out the window and with it the notion
of rollback. The options they provide are typically something along the
lines of delete the resources and try again. That's a simple solution that
typically only works well when you only need to deal with files. Upgrade
operations typically leave cruft behind unless some underlying system, like
RPM/DEB, remove files that are no longer needed. And I have seen no system,
including the Windows Installer, that provides any mechanism to manage data
effectively including changing schema, updating configuration data, and
keeping user configuration (this last bit is the hardest part).

I guess the point of this rant is that magic bullets do not exist. All
platforms have their pros and cons. It is important to understand both the
pros and cons when selecting your combination of platforms, especially the
cons as they define the constraints of your chosen technology.

Setup is hard and setup is hardest on Windows. We're constantly reinventing
solutions rather than sharing them. We need to share our solutions with one
another but we tend to build solutions that work just for the product we're
currently installing or our employers are not interested in sharing that
work with the community. Setup is devalued if it works and demonized if it
doesn't but is always just a means to an end. The Product is the thing that
matters not setup. I don't know how to encourage more community involvement
in existing projects like the WiX toolset. I don't know how to encourage
new projects to begin. But I think living in our silos is definitely not
helping.

--
Edwin G. Castro

On Tue, May 5, 2020 at 12:21 PM Richard G via wix-users <
wix-users at lists.wixtoolset.org> wrote:

> Use MSI to install applications. Configuration (IIS config, databases etc)
> should be done with a declarative configuration management tool. Personally
> I think Puppet is the best of these, especially on Windows.
>
> > On 5 May 2020, at 19:55, Rob Mensching via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
> >
> > I agree with Edwin and would emphasize three points:
> >
> > 1. Windows has different (lower?) expectations of its end users than
> Linux (generally). That fact raises the bar for Windows developers and
> Windows installations. Windows also exposes a massive configuration surface
> area when compared to Mac. That fact raises the bar for Windows developers
> and Windows installations. That's not to say I would like to see the better
> parts of Linux and Mac configuration be adopted by Windows. But you can do
> a *lot* of different things with Windows and the expectation is (generally)
> that your Windows installation will do it all well in install, uninstall,
> upgrade and rollback for all of that.
> >
> > IMHO, this ease of use (from a end-user perspective) to produce a *very*
> broad range of solutions are two key aspects that made Windows popular.
> >
> >
> > 2. Declarative installation - declarative does require you as the
> developer to think differently, much like SQL requires you to think
> declaratively about data access. However, I challenge you to build
> procedural installations (of any consequence) that are less error prone if
> you need uninstall and rollback. You have to write a lot of procedural code
> to handle those situations that you don't, with declarative solutions
> (that's why declarative solutions exist).
> >
> >
> > 3. <rant> IIS configuration (as an example) - I occasionally see people
> complain about missing IIS configuration (or anything else needing more
> declarative support). The Windows Installer does not support IIS
> configuration at all. The support you are using comes from an extension
> provided by the WiX Toolset (you are welcome). If you want the extension to
> do more, help enhance the extension. Do not complain that it doesn't do
> what you want and then complain that you have to write your own custom
> action. Give back or give to those that give back.</rant>
> >
> > Edwin is right too.
> >
> > -----Original Message-----
> > From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> Edwin Castro via wix-users
> > Sent: Tuesday, May 5, 2020 11:28 AM
> > To: Ven H <venh.123 at gmail.com>
> > Cc: Edwin Castro <egcastr at gmail.com>; WiX Toolset Users Mailing List <
> wix-users at lists.wixtoolset.org>
> > Subject: Re: [wix-users] Suitability of MSI
> >
> > I would not try to compare Windows install issues with other platforms
> like Linux. Those platforms are incredibly different. It would be like
> comparing apples and chicken. Yes, apples and and chicken can be considered
> food but that is about as close as it gets. Trying to apply Linux best
> practices to Windows will lead to pain.
> >
> > Windows installations are difficult because they require more than
> copying files and modifying files. Windows Installer installations are
> difficult because the engine requires a declarative approach and forces the
> setup developer to think about things they typically do not think about
> like how do I rollback an operation or how do I repair a broken
> installation.
> > Windows Installer installations are difficult because the engine
> requires that you consider current state and make decisions about
> everything you want to do before you do it, including what do to if a
> rollback is necessary.
> >
> > Personal opinion: One of the things that makes the Windows Installer
> difficult is that it has a very high bar for reproducibility and
> reliability. I know it sounds counter intuitive but nearly all *nix
> deployment platforms only track files to be installed and removed. That's
> about it. They have no built-in rollback and cannot reliably do so because
> their extension model is /bin/sh allowing you to do anything at all at
> practically any time. The result is that you get developers writing a lot
> of imperative code in pre/post scripts for various cases were the only
> thing the platform really provides is xcopy and some form of relatively
> questionable dependency management. Okay, the dependency management
> provided is clearly good enough and is better than none (Windows doesn't
> have anything really for dependency management... so...) Anyway, the main
> point I'm trying to make is that *nix platforms tend to make it easy to
> write scripts because it is all just "easy to understand" imperative cod
> > e but ultimately it is no more reliable than anything else. There are
> effectively no guarantees. There is no rollback and repair and upgrade and
> hotfix and other concepts from Windows simply do not really exist or look
> different enough to not be considered the same.
> >
> > You could "simplify" matters by using zip as a container format (like so
> many open formats do) and use your preferred scripting language (perhaps
> > powershell) to do the work. You could build a simple executable engine
> that can extract the zip and run scripts and copy files at the right time.
> Your extension mechanism is now just your chosen scripting language with
> simple and/or non-existent restrictions. But a word to the wise, I've done
> this before. It is incredibly difficult, time consuming, and, ultimately,
> error prone. I left about 4 and half years of my life working 16-20 hour
> days,
> > 6-7 days a week, nearly 52 weeks a year and it was the worst experience
> I have ever had. Honestly, do *NOT* recommend it.
> >
> > The Windows Installer is hard and some technologies are not making it
> easy to work with them, I'm thinking of you IIS, but I personally think it
> is the ONLY reliable installation platform on any operating system platform.
> > All other setup platforms are not reliable. They are just easy to work
> with.
> >
> > --
> > Edwin G. Castro
> >
> >
> >> On Tue, May 5, 2020 at 10:57 AM Ven H <venh.123 at gmail.com> wrote:
> >>
> >> Hi Edwin,
> >>
> >> Thanks a lot for the details. I know it's been a while. I agree with
> >> you on Database. After burning my fingers a lot, I have come to the
> >> same conclusion that MSI is not suitable for DB installation or
> >> upgrades or patches.
> >>
> >> But I feel with the same with IIS also. There are lots of IIS settings
> >> which are not supported by MSI. We can achieve them using Custom
> >> Actions, but these come with their set of issues like managing
> >> uninstall, Upgrades, patches etc.
> >>
> >> Also, we cannot control the sequence of installation of components.
> >> Managing clean installation & uninstallation of prerequisites is
> >> another challenge. Even areas like Upgrades and Patches bring in their
> >> own challenges.
> >>
> >> Also, my client has some specific requirements like retaining some
> >> config files post install / upgrade.  This adds another layer of
> challenge.
> >>
> >> Again, with all due respect, I am not complaining about WiX or the
> >> authors or even the community (since you guys have been really great
> >> in terms of technical help and support), but wondering whether there
> >> is a packaging and deployment mechanism which can address requirements
> >> like IIS, Databases, Patches, Upgrades etc in Microsoft world. Also
> >> wondering how other platforms like Linux manage complex deployments.
> >>
> >>
> >>> On Fri, Feb 7, 2020 at 12:26 AM Edwin Castro <egcastr at gmail.com>
> wrote:
> >>>
> >>> You should be able to do nearly everything you need to do with the
> >>> Windows Installer, MSI. You should be able to write custom actions
> >>> for those things that the Windows Installer engine doesn't do on it's
> >>> own. The WiX Toolset should provide most of the functionality you
> >>> need that is not provided by MSI. I'm thinking things like IIS and MS
> >>> SQL Server database deployments. That said I would caution against
> >>> using MSI to install your database.
> >>>
> >>> Databases are rarely installed on the same server where other
> >>> application components are installed. Often you install the front end
> >>> web site and/or web service APIs to many servers for horizontal
> >>> scaling. Which of these servers should the database be installed on?
> >>> Likely none of them as likely the database is a different server all
> >>> together. In fact, the only server that likely makes sense is the
> >>> database server itself but your DBAs likely will not allow that.
> >>> Instead, you'll have to designate a server that will have the
> >>> database MSI installed that will not actually have the database
> installed because the database will actually be deployed to another server.
> >>> You'll also need to guarantee that this "proxy server" is always the
> >>> server used to upgrade the database otherwise it will try to install
> >>> the database from scratch as the MSI product was not previously
> >>> installed on a different "proxy server".
> >>>
> >>> In my opinion, the Windows Installer is not the best option to manage
> >>> datastore deployments. On upgrade you change schema *and* migrate
> >>> data from old schemas to new schemas. In complicated deployments
> >>> you'll want that process to run outside the context of the Windows
> >>> Installer. I think the Windows Installer is a good option to install
> >>> database deployment tools which can then be used to manage the
> database deployment.
> >>>
> >>> The WiX Toolset does provide actions to create empty databases and
> >>> execute SQL scripts, inline and script files, which can be useful for
> >>> very simple deployments. The Windows Installer and WiX cannot know
> >>> what actions, if any, are appropriate for a rollback. You'll need to
> >>> provide the scripts that do that work. WiX will just execute them for
> you.
> >>>
> >>> I'd instead recommend looking into database migration tools instead.
> >>> My quick google search found Flyway DB as an example. There were
> >>> other options years ago when I used them more regularly, including
> >>> tools from Microsoft for MS SQL Server. Some of these tools track
> >>> changes and can migrate a database from some snapshot to a future
> >>> snapshot applying all changes in between. Some of those tools allow
> >>> you to undo those changes which could be useful for rollback
> >>> scenarios. Other tools work of a model which is compared to the
> >>> target database at runtime and the change script is generated at
> >>> runtime. Some DBAs do not trust these tools but they generally rock!
> >>> Highly recommended! The Microsoft offering used to work this way. Not
> >>> sure if it still exists nor how it has changed since 2013 when I last
> used it.
> >>>
> >>> --
> >>> Edwin G. Castro
> >>>
> >>> On Thu, Feb 6, 2020, 09:14 Ven H via wix-users <
> >>> wix-users at lists.wixtoolset.org> wrote:
> >>>
> >>>> I need to take care of the installation / configuration of the
> >>>> following features. Is MSI a best fit for all these requirements,
> >>>> especially Database?
> >>>>
> >>>> Prereqs Check (no installation / uninstallation) Enable / Disable
> >>>> Features Create / Update / Remove Registry Entries Register /
> >>>> Unregister COMs (with Heat) Register / Unregister GAC (with Heat and
> >>>> XSL transform) Set / Remove ACL Update IIS Settings (Web Site,
> >>>> Binding, Auth, Default Document, App Pool Props, Mime Types etc)
> >>>> Create / Remove Event Viewer Categories Start / Stop Services Add /
> >>>> Remove MSMSQ Add / Remove Shortcuts Install / Upgrade Databases
> >>>> (including Create / Update tables, Stored Procedures, Indexes,
> >>>> Triggers and so on) Lots of files (with Heat) Manage web.config
> >>>> files Custom Actions
> >>>>
> >>>> HotFix
> >>>> Repair
> >>>> Upgrade
> >>>> Rollback (including DB)
> >>>>
> >>>> ____________________________________________________________________
> >>>> WiX Toolset Users Mailing List provided by FireGiant
> >>>> http://www.firegiant.com/
> >>>>
> >>>
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/