Bartek Szafko

Rafał – jeden z moich czytelników opisał ciekawy problem, na który natrafił: chciał stworzyć źródło do logowania w windowsowym systemie zdarzeń.

Read the rest of this entry »

W Windows Vista(Installer 4.5) i Windows 7(installer 5.0) jest całkiem ciekawa funkcjonalność – buforowanie instalatorów msi. Rzecz całkiem przydatna, gdy niespecjalnie lubimy komunikaty w stylu “Nie można znaleźć pliku (ulubiony soft).msi”.

Read the rest of this entry »

Merge modules to plik z rozszerzniem .msm, który możemy dołączyć do naszego pliku .msi. Zaletą jest to, że na wyjściu dostajemy jeden plik Windows Installera, którego zawartość jest połączona(stąd nazwa merge module) z modułem.

Read the rest of this entry »

Aktualizowanie aplikacji to moim zdaniem ważne zagadnienie. Bardzo często aplikacja podlega ciągłym zmianom, dodawane są nowe funkcjonalności, naprawiane błędy(oczywiście:) ). Istotne jest to, w  jaki sposób taką aktualizację widzi użytkownik.

Read the rest of this entry »

Nie wiem czy zauważyliście, ale przy domyślnie stworzony instalatorach w WiX okno postępu instalacji nigdy nie wyświetla dokładnie jakie pliki, klucze rejestru są zakładane i kopiowane, wyświetla się tylko dosyć ogólna informacja “Kopiowanie nowych plików”:

Na przykład instalator od resharpera wyświetla bardzo sczegółowe info o tym co się dzieje:

Żeby dodać podobny efekt, musimy zmodyfikować interfejs użytkownika dodać nową kontrolkę i zasubskrybować jej zawartość do zdarzenia ActionData:

<Control Id="ActionData" Type="Text" X="59" Y="165" Width="273" Height="41" Transparent="yes" TabSkip="no">
  <Subscribe Event="ActionData" Attribute="Text" />
</Control>

Niby prosta modyfikacja, ale wymaga albo zbudowania WiXa od nowa(chociaż UIExtension) albo dodania całego UI do swojego projektu instalatora – co ma niewątpliwe zalety na przyszłość, będzie można trochę poszaleć i np stworzyć coś podobnego do resharpera. BTW instalator resharpera jest dobrym miejscem do podejrzenia jak zrobić parę ciekawych rzeczy w wix – więc orca w dłoń i do roboty.

Bartek zadał pytanie:

Od pewnego czasu szukam narzędzia do robienia instalek (lepszego niż z VS) testowałem już advanced installer i instalshield teraz znalazlem twoj opis WIX ale żedne z tych narzędzi nie integruje się z VS2008 express. Moje pytanie "Czy jest na to jakiś sposób" czy też muszę przejść na wyższą pułkę?

Wtyczka Votive, która dodaje nowy typ projektu – WixProj i pozwala na uruchomienie Candle i Light z poziomu Visual Studio niestety nie działa w wersji Express. Wersja ta ma wogóle wyłączoną możliwość instalacji dodatków( poza chlubnym wyjątkiem jakim jest TestDriven.net). Brak Votive jednak nie uniemożliwia użycia Wixa.

Wtyczka votive uruchamia aplikacje Candle i Light. Możemy zrobić to samo posługując się “Post build event” we właściwościach projektu:

A plik buildmsi.bat może mieć postać zbliżoną do:

"%wix%bin\candle.exe" -out obj\Debug\Product.wixobj -arch x86 -ext "%wix%bin\WixUIExtension.dll" Product.wxs
"%wix%bin\Light.exe" -cultures:pl-PL -ext "%wix%WixUIExtension.dll" -out bin\Debug\WixProject2.msi -pdbout bin\Debug\WixProject2.wixpdb obj\Debug\Product.wixobj

W zależności od tego w jaki sposób zbudowaliśmy Product.wxs do candle może trzeba będzie podać dodakowe komendy -Dnazwaparametru=wartosc. Zmienna %Wix% jest ustawiana przez instalator podczas konfigurowania Wixa.

W poprzednich częściach o WiX:

• część 1 – wstęp teoretyczny o instalatorach
• część 2 – pierwszy instalator
• część 3 – dodanie interfejsu użytkownika
• część 4 – customizacja interfejsu użytkownika
• część 5 – skróty na pulpicie i w menu start
• część 6 – upgrade

Jakiś czas temu Szymon Kobalczyk i Marcin Książek pytali o możliwość automatycznego tworzenia skryptów WxS w oparciu o stworzone przez projekt. Taki mechanizm byłby szczególnie przydatny dla projektów, w których często zmieniają się pliki, które muszą być zainstalowane np: dla aplikacji webowych. Gdy zajrzałem do jednego ze starych projektów stwierdziłem, że używałem do tego dosyć rozbudowanego skryptu Wsh.

W wix3 istnieje całkiem przydatny program narzędziowy, który pozwala właśnie na stworzenie pliku wxs. Aplikacja nazwya się heat. Przy wywoływaniu heat-a ważny jest tzw. harvester, czy zbieracz plików. Przykładowymi harvesterami jest directory, który zbiera wszystkie pliki z folderu oraz project, który tworzy wxs na podstawie wyniku projektu z VS.

Przykładowe wywołanie może wyglądać tak:

heat.exe project myproj.csproj -sfrag -srd -gg -suid -pog:Binaries -pog:Content -out Files.wxs

Omówie po kolei wszystkie parametry:

• project – określa typ harvestera, następna jest nazwa pliku projektu
• sfrag – powoduje, że nie są generowane osobne fragmenty dla każdego pliku
• gg – generuje odrazu guidy dla componentów
• suid – powoduje, że pola Id dla komponentów i plików nie są unikalnymi guidami, co jest całkiem przydatne w sytuacji gdy chcielibyśmy w innym miejscu odwołać się do plików
• pog:Binaries – określa, które grupy wyjścia mają być uwzględnione w pliku, w przykładzie wybrałem Binaria, parametr pog można powtarzać
• out Files.wxs – plik, do którego będzie generowanie wyjście

Plik Files.wxs będzie miał taką postać:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <DirectoryRef Id="c2csi.Binaries">
            <Component Id="c2csi.Binaries.c2csi.exe" Guid="{0CCD4E1F-0AD8-40F3-B741-7A11E3E70D99}">
                <File Id="c2csi.Binaries.c2csi.exe" Source="$(var.c2csi.TargetDir)\c2csi.exe" />
            </Component>
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <ComponentGroup Id="c2csi.Binaries">
            <ComponentRef Id="c2csi.Binaries.c2csi.exe" />
        </ComponentGroup>
    </Fragment>
    <Fragment>
        <DirectoryRef Id="c2csi.Content">
            <Component Id="c2csi.Content.XMLFile1.xml" Guid="{41E641F5-C0CA-470B-A7F2-73EF37B49A5F}">
                <File Id="c2csi.Content.XMLFile1.xml" Source="$(var.c2csi.ProjectDir)\XMLFile1.xml" />
            </Component>
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <ComponentGroup Id="c2csi.Content">
            <ComponentRef Id="c2csi.Content.XMLFile1.xml" />
        </ComponentGroup>
    </Fragment>
</Wix>

Dodatkowo do tego główny skrypt:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="00225fb3-42b1-4404-a595-f9a1c9ad5d16" Name="WixProject2" Language="1045" Version="1.0.0.0" Manufacturer="WixProject2" UpgradeCode="4dd7c3bd-1d88-4d2b-8da9-fd39b11b2653" Codepage="1250">
        <Package InstallerVersion="200" Compressed="yes" />

        <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />

        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder">
                <Directory Id="c2csi.Binaries" Name="WixProject2">
                </Directory>
            </Directory>
        </Directory>

        <Feature Id="ProductFeature" Title="WixProject2" Level="1">
      <ComponentGroupRef Id="c2csi.Binaries"/>
        </Feature>
    </Product>
</Wix>

Trzymanie plików w osobnym skrypcie WxS jest dobrą praktyką, natomiast z automatycznym generowaniem należy być ostrożnym może to spowodować nieprzewidziane problemy.

Uruchamianie heat warto wrzucić do before build action do projektu wix.

I was trying to write a post on generating wxs scripts with heat. But i think I found a bug. Below more info – maybe someone can verify.

I’ve got a following directory contents:

And I run heat with following parameters:

heat dir . -dr D_INSTALLLOCATION -sfrag -srd -gg -suid -cg test -out test.wxs

I get following wxs:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <ComponentGroup Id="test">
            <ComponentRef Id="" />
            <ComponentRef Id="" />
            <ComponentRef Id="" />
            <ComponentRef Id="" />
        </ComponentGroup>
    </Fragment>
    <Fragment>
        <DirectoryRef Id="D_INSTALLLOCATION">
            <Component Id="c2csi.exe" Guid="{43B03251-B0EE-4273-8E3C-DE54EAD0A263}">
                <File Id="c2csi.exe" KeyPath="yes" Source="SourceDir\c2csi.exe" />
            </Component>
            <Component Id="c2csi.pdb" Guid="{5B925509-EB62-461F-BEB8-FC4C8C99C290}">
                <File Id="c2csi.pdb" KeyPath="yes" Source="SourceDir\c2csi.pdb" />
            </Component>
            <Component Id="c2csi.vshost.exe" Guid="{048CE65A-FCD9-4A05-B482-45F326F40199}">
                <File Id="c2csi.vshost.exe" KeyPath="yes" Source="SourceDir\c2csi.vshost.exe" />
            </Component>
            <Component Id="test.wxs" Guid="{90927E13-B1AD-48D2-AADA-0C227CD2DC36}">
                <File Id="test.wxs" KeyPath="yes" Source="SourceDir\test.wxs" />
            </Component>
        </DirectoryRef>
    </Fragment>
</Wix>

Notice the ComponentGroup – it has empty Ids in ComponentRef.

Why would I want to generate non unique File Ids and put them in ComponentGroup?

The answer is: I would put ComponentGroupRef in Feature and use references to File element to create for example a shortcut in start menu.

Now when I removed –suid when calling heat it generated wxs with unique component and file ids which are impossible to reference in the main script.

Is it a bug or should I take a completly different approach?

UPDATE: when used project harvester with the same paramaters .wxs was ok:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <DirectoryRef Id="c2csi.Binaries">
            <Component Id="c2csi.Binaries.c2csi.exe" Guid="{22D0EAD2-B33C-4D1D-B5F2-FA046CF79649}">
                <File Id="c2csi.Binaries.c2csi.exe" Source="$(var.c2csi.TargetDir)\c2csi.exe" />
            </Component>
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <ComponentGroup Id="c2csi.Binaries">
            <ComponentRef Id="c2csi.Binaries.c2csi.exe" />
        </ComponentGroup>
    </Fragment>
</Wix>