[wix-users] Suitability of MSI

Tue May 5 12:21:45 PDT 2020

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/