[wix-users] Suitability of MSI

Wed May 6 10:43:53 PDT 2020

Msi is perfect for databases or IIS. It provides you a basic framework and process and write CA's to do things that are a bit special which is not natively supported or doesn't fit in the sequence flow.
Imo, using Msi gives you basis for process, framework/structure.
I write a lot of CA's that are flexible using either tables as input or properties. And I wouldn't trade it for inferior installer products or msix.

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Hoover, Jacob via wix-users <wix-users at lists.wixtoolset.org>
Sent: Wednesday, May 6, 2020 5:48:11 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-users] Suitability of MSI

I know C and I work on the toolset, but I have zero desire to learn IIS config.  A possible option is you research/document what is needed to be changed in the IIS extension, create a WIP, and I can articulate the logical change to C.

From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Ven H via wix-users
Sent: Tuesday, May 5, 2020 10:05 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Ven H <venh.123 at gmail.com>
Subject: Re: [wix-users] Suitability of MSI

Thank you Richard.

On Wed, May 6, 2020 at 12:51 AM Richard G via wix-users <
wix-users at lists.wixtoolset.org<mailto: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<mailto: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<mailto: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<mailto:venh.123 at gmail.com>>
> > Cc: Edwin Castro <egcastr at gmail.com<mailto:egcastr at gmail.com>>; WiX Toolset Users Mailing List <
> wix-users at lists.wixtoolset.org<mailto: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<mailto: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<mailto: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<mailto: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/<http://www.firegiant.com>
> >>>>
> >>>
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/<http://www.firegiant.com/>
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/<http://www.firegiant.com/>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/<http://www.firegiant.com/>

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/<http://www.firegiant.com/>
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/