Как сделать MSI, который просто оборачивает EXE-файл

Question

После слишком большого количества экспериментов я пришел к выводу, что установщик Windows - просто плохая технология. Но клиенты хотят файлы MSI.

Итак, как мне создать MSI-файл, который извлекает EXE-файл во временный каталог и запускает его с такими же или похожими параметрами, которые были переданы в EXE-файл?

Параметры MSI описаны в Msiexec (параметры командной строки) (низкоуровневое "выполнение" MSI - опция msiexec package.msi).

РЕДАКТИРОВАТЬ: WiX-решение mjmarsh выглядит так, как будто оно работает. У меня просто еще не было возможности попробовать это (время кризиса). Если это сработает, я приму это.

РЕДАКТИРОВАТЬ: это не работает. Недостающая часть: посещенный / оставленный без внимания, кажется, не доступен.

В любом случае, единственное, что заставит эту работу работать, - пользовательское действие уничтожит родительский процесс!

РЕДАКТИРОВАТЬ: Итак, кто-то опубликовал в качестве дополнительного ответа, завершая все это как пост-установка пользовательского действия. Теоретически это возможно, но поскольку может потребоваться перезагрузка (спасибо MS за .NET 4, иногда требующую перезагрузку), мы должны сделать еще одну попытку. Итак из матрицы преимуществ:

Transparency: No. One big custom action.
Customizability: No.
Standardization: No. 
Management and reporting: No. Appears to work but will not.
Security: No benefit.
Validation: No. The hackery required to survive reboot makes this sure to not work.
Resiliency: Completely defeated.
Rollback: No. Rollback didn't work when we were using MSI anyway.
Patching & Updates: No. We have a local solution anyway.
Logging: No. Appears to work but will not.

Нет смысла.

Answer 1

Простой трюк:

Изображение проекта

using System;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;

namespace Setup
{
    internal class Program
    {
        [DllImport("kernel32.dll")]
        private static extern IntPtr GetConsoleWindow();

        [DllImport("user32.dll")]
        private static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

        private static void Main(string[] args)
        {
            ShowWindow(GetConsoleWindow(), 0);
            Stream st = Assembly.GetExecutingAssembly().GetManifestResourceStream("Setup.MSI.Temp.msi");
            string path = Path.Combine(System.IO.Path.GetTempPath(), "Temp.msi");
            using (var fileStream = new FileStream(path, FileMode.Create, FileAccess.Write))
            {
                st.CopyTo(fileStream);
            }
            Process p = new Process();
            p.StartInfo.FileName = path;
            p.Start();
            p.WaitForExit();
            File.Delete(path);
        }
    }
}

Answer 2

Не-а, просто воспользуйтесь мастером Inno Setup. Это делает установочный EXE, но не MSI. Это как 5 минут, и у вас будет установщик Windows.

Просто скачайте , установите его, укажите его на свой EXE и следуйте инструкциям на экране

Answer 3

У меня была такая же проблема (обернуть EXE, вызвать другой MSI из EXE, включая установку .net и т. Д.), и вот мое решение:

Я создаю установочный exe-файл, используя InstallAware. У него есть собственный MSI Wrapper, который оборачивает сгенерированный EXE-файл в MSI.

Работает нормально, EXE может без проблем вызывать другие MSI (включая установку .net, другие настройки сторонних производителей), но это потому, что запуск MSI прекращает («возвращает») права после запуска установочного EXE-файла, и таким образом они избегают ограничения MSI на рекурсивные вызовы MSI.

НО - некоторые клиенты (компании), которые используют средства развертывания MSI, требуют, чтобы MSI (msiexec) возвращал (заканчивал) только после завершения процесса установки, и это является проблемой с вышеупомянутым решением.

Итак - чтобы решить это:

Существует еще один MSI Wrapper (exemsi.com), который генерирует MSI, который возвращается только после завершения установки EXE, но для его использования необходимо использовать другой уникальный параметр InstallAware:

InstallAware имеет возможность создавать установки EXE с использованием собственного встроенного механизма, а не на основе механизма установщика Windows, чтобы избежать рекурсивного ограничения MSI. Объедините их обоих, и вы получите идеальное решение.

Надеюсь, это кому-нибудь поможет, хотя прошло много лет с тех пор, как этот вопрос был впервые опубликован.