Обновите отдельную функцию в дереве функции WIX, не удаляя/обновляя другую функцию (функции)
Ключ должен использовать DATEADD и DATEDIFF наряду с соответствующим перечислением промежутка SQL.
declare @datetime datetime;
set @datetime = getdate();
select @datetime;
select dateadd(year,datediff(year,0,@datetime),0);
select dateadd(month,datediff(month,0,@datetime),0);
select dateadd(day,datediff(day,0,@datetime),0);
select dateadd(hour,datediff(hour,0,@datetime),0);
select dateadd(minute,datediff(minute,0,@datetime),0);
select dateadd(second,datediff(second,'2000-01-01',@datetime),'2000-01-01');
select dateadd(week,datediff(week,0,@datetime),-1); --Beginning of week is Sunday
select dateadd(week,datediff(week,0,@datetime),0); --Beginning of week is Monday
Примечание, что, когда Вы ставите в тупик вторым, Вы будете часто получать арифметическое переполнение, если Вы будете использовать 0. Так выберите известное значение, которое, как гарантируют, будет ниже, чем дата и время, которую Вы пытаетесь поставить в тупик.
2 ответа
Я понял это и подумал, что опубликую здесь ответ для дальнейшего использования другими. Итак, я полностью объяснил проблему, я углублюсь в сценарий реального мира.
У нас есть довольно большая часть программного обеспечения, которая требует от нас наличия нескольких поддерживающих приложений, работающих на нескольких разных серверах. Наш текущий прогресс обновлений делает умеренно сложным обновление кода надежным способом. В настоящее время мы используем самораспаковывающиеся исполняемые файлы для развертывания нашего кода на разных серверах. Проблема возникает, когда у нас такое большое количество поддерживающих приложений, что становится трудно убедиться, что приложения были установлены правильно с правильными настройками конфигурации и т. Д. Чтобы решить эту проблему, мы изучаем возможность вместо сжатия каждого из поддерживающих приложений создать единый установщик (MSI), который позволит группе разработчиков инфраструктуры устанавливать определенный набор поддерживающих приложений на каждую данную машину. Когда у нас есть серьезные изменения (например, с 1.0 до 2.0), мы выполним установку полного обновления (это означает, что все службы / процессы должны быть остановлены, деинсталлированы, установлены и запущены). Когда у нас есть незначительное изменение, нам нужно только остановить и переустановить затронутые службы / процессы, не затрагивая другие приложения. Теперь, когда хватит болтовни, давайте перейдем к решению:
Я изменил WIX Product.wxs, чтобы удалить ярлыки, поскольку они нам не нужны в нашем сценарии. Вот обновленный файл wxs:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="13C373D3-5C27-487e-A020-C2C89E4607B1" Name="HelloWorldInstaller" Language="1033" Version="1.0.0.0"
Manufacturer="HelloWorldInstaller" UpgradeCode="E7CB3C76-4D51-48a8-BFB4-6D11B2E2E65B">
<Package InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="product.cab" EmbedCab="yes" />
<FeatureRef Id="HelloWorld1Feature" />
<FeatureRef Id="HelloWorld2Feature" />
<FeatureRef Id="HelloWorld3Feature" />
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="Hello World" />
</Directory>
<Directory Id="DesktopFolder" Name="Desktop"/>
</Directory>
</Fragment>
<Fragment>
<DirectoryRef Id="INSTALLLOCATION">
<Directory Id="HelloWorld1Directory" Name="Hello World 1">
<Component Id="HelloWorld1Component" Guid="6D1D9D33-DA17-4db3-8132-C39F32200C3A">
<File Id="HelloWorld1.exe" Name="HelloWorld1.exe" Source="HelloWorld1.exe" DiskId="1" Checksum="yes" />
</Component>
</Directory>
<Directory Id="HelloWorld2Directory" Name="Hello World 2">
<Component Id="HelloWorld2Component" Guid="B2D51F85-358B-41a7-8C45-B4BB341158F8">
<File Id="HelloWorld2.exe" Name="HelloWorld2.exe" Source="HelloWorld2.exe" DiskId="1" Checksum="yes" />
</Component>
</Directory>
<Directory Id="HelloWorld3Directory" Name="Hello World 3">
<Component Id="HelloWorld3Component" Guid="A550223E-792F-4169-90A3-574D4240F3C4">
<File Id="HelloWorld3.exe" Name="HelloWorld3.exe" Source="HelloWorld3.exe" DiskId="1" Checksum="yes" />
</Component>
</Directory>
</DirectoryRef>
</Fragment>
<Fragment>
<Feature Id="HelloWorld1Feature" Title="Hello World 1" Level="1">
<ComponentRef Id="HelloWorld1Component"/>
</Feature>
</Fragment>
<Fragment>
<Feature Id="HelloWorld2Feature" Title="Hello World 2" Level="1">
<ComponentRef Id="HelloWorld2Component"/>
</Feature>
</Fragment>
<Fragment>
<Feature Id="HelloWorld3Feature" Title="Hello World 3" Level="1">
<ComponentRef Id="HelloWorld3Component"/>
</Feature>
</Fragment>
</Wix>
Теперь вместе с нашими незначительными обновлениями мы будем выпускать исправления для наших компонентов.
Например, предположим, что у нас есть ProductA, который состоит из трех компонентов - 1,2 и 3. Эти три компонента должны запускаться либо как службы, либо как запланированные задачи. Характер нашего продукта, мы не можем закрыть все наши службы для обновления или исправления одного из наших компонентов. Итак, если после установки версии 1.0 мы обнаружим ошибку в компоненте 2, но мы не хотим, чтобы исправление, примененное к этой ошибке, затронуло 1 или 3, мы выпустим исправление для компонента 2, таким образом, будет затронут только компонент 2.
В нашем быстром примере выше мы используем HelloWorld1, HelloWorld2 и HelloWorld3 в качестве трех наших компонентов в нашем программном приложении. Мысль в том, что мы сможем установить все три с помощью одного MSI, но затем обновите каждый из них независимо, не затрагивая другие установленные компоненты.
Итак, чтобы продемонстрировать это, я создал три консольных приложения выше, которые будут отображать «Hello World 1!», «Hello World 2!» И «Hello World 3!». Затем, после выпуска исходного MSI, допустим, мы обнаружили «ошибку», которая требует, чтобы HelloWorld1 произнес «Hello World 1! Обновлено». вместо. Вот что мы сделаем, чтобы смоделировать это:
- Создайте Product.wixobj, выполнив эту команду в командной строке:
Candle.exe Product.wxs
Пожалуйста, помните, что для вызова Candle.exe или любой из команд WIX каталог установки Wix должен быть в вашей переменной PATH. ( Краткое руководство по обновлению переменной среды PATH ) Также, пожалуйста, выполняйте команды в том же каталоге, что и ваш файл Product.wxs. - Создайте первую версию вашего продукта (скажем, 1.0):
light.exe Product.wixobj -out ProductA-1.0.msi - Теперь найдите ошибку (измените вывод HelloWorld1, чтобы сказать "Hello World 1! Обновлено. ") Затем обновите версию сборки и версию файла . Это важно, так как именно так WIX может отличить исполняемые файлы.
- Выполните ту же команду, что и на первом этапе (для хорошей оценки):
Candle.exe Product.wxs - Выполните почти ту же команду, что и на втором этапе:
light.exe Product.wixobj -out ProductA- 1.1.msi
Обратите внимание, что это версия 1.1 вместо 1.0 (это msi с нашим обновленным кодом). Однако мы не хотим просто устанавливать это, продолжайте читать. - Вот самое интересное, мы получаем разницу в двух MSI с помощью следующей команды:
torch.exe -p -xi ProductA-1.0.wixpdb ProductA-1.1.wixpdb -out Diff.WixMst - Теперь мы создаем файл патча из этого ( Patch.wxs будет объяснено ниже):
Candle.exe Patch.wxs - Теперь мы создадим файл WixMsp с помощью этой команды:
light.exe Patch.wixobj -out Patch.WixMsp - И теперь самое интересное. Создайте файл MSP с помощью этой команды:
pyro.exe Patch.WixMsp -out Patch.msp -t RTM Diff.Wixmst
Теперь, если все прошло по плану, у вас должно быть два файла MSI и один файл MSP. Если вы установите первый msi (ProductA-1.0.msi) и запустите HelloWorld1.exe, вы должны увидеть сообщение «Hello World 1!». Просто для развлечения (и примера) запустите оба других приложения и оставьте их работающими (я построил остановку, чтобы они оставались открытыми). Закройте HelloWorld1. exe, поскольку теперь мы собираемся применить обновление для этого exe, но при этом мы не повлияем на HelloWorld2.exe или HelloWorld3.exe. Если вы сейчас установите файл msp (Patch.msp), а затем запустите HelloWorld1.exe, вы увидите обновленное сообщение «Hello World 1! Обновлено».
Теперь о магическом файле Patch.wxs:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Patch
AllowRemoval="yes"
Manufacturer="Dynamo Corp"
MoreInfoURL="http://www.dynamocorp.com/"
DisplayName="Sample Patch"
Description="Small Update Patch"
Classification="Update"
>
<Media Id="5000" Cabinet="RTM.cab">
<PatchBaseline Id="RTM"/>
</Media>
<PatchFamilyRef Id="SamplePatchFamily"/>
</Patch>
<Fragment>
<PatchFamily Id='SamplePatchFamily' Version='1.0.0' Supersede='yes'>
<ComponentRef Id="HelloWorld1Component"/>
</PatchFamily>
</Fragment>
</Wix>
Не так уж много, правда? Что ж, наиболее интересными являются следующие части:
-t RTM- они должны совпадать.
Если вы Если вы что-то искали, приведенный выше код может показаться знакомым, поскольку он взят из Блог Питера Марку : WiX: Создание патча с использованием новой системы построения патчей - Часть 3
Я также полагался сильно на Блог Алекса Шевчука : От MSI к WiX, Часть 8 - Основное обновление
Если вам интересно: «Вау, это много шагов, зачем кому-то делать такое количество шагов? ? ", пожалуйста, помните, что после того, как тяжелая работа (см. выше) будет выполнена, вам нужно перенести это в свою процедуру интеграции. Верно, интегрировать, интегрировать, интегрировать ! Как ты это делаешь? Ну, это еще немного исследований и, может быть, запись в блоге? - Вероятно. Чтобы помочь вам встать на правильный путь, вот замечательная статья о Автоматизация выпусков с помощью MSBuild и Windows Installer XML .
Ух ты, Я надеюсь, что вы прочитали все это (все двое) и многому научились. Надеюсь, это поможет кому-то, кроме меня.
Спасибо!
Похоже, вы разобрались со сценарием обновления, теперь вам просто нужно выяснить Где разместить RemoveExistingProducts в крупном обновлении MSI , чтобы функции не переустанавливались, если они не изменилось :)