[wix-users] Suitability of MSI

Tue May 5 20:04:37 PDT 2020

Unfortunately, I don't know C/C++. As I said, I am not complaining. I am
just trying to understand how to manage IIS configuration in Windows and
whether it can be handled via MSI or not.

On Wed, May 6, 2020 at 12:25 AM Rob Mensching <rob at firegiant.com> 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 code
> 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/
>