[wix] Hoe een gegenereerde wix file includen in je main wxs?

[BasieP]

Beste mensen,

ik ben al tijden aan't zoeken, maar denk dat ik ergens een denkfout maak. Ik ben nog niet zo lang bezig met wix, en probeer nu van mijn projectje een msi te bouwen.

Ik gebruik visual studio met de wix extentie en de deploy extentie.
Ik heb een webapp, en deze wordt na het bouwen door de deploy extentie gedeployed. Ik heb onderaan de .proj file van de deploy extentie deze regel toegevoegd:

XML:

<exec Command="%22$(WixToolPath)heat.exe%22 dir %22.\$(Configuration)%22 -gg -g1 -o %22$(OutputPath)files.wxs%22"/>

wat er dus voor zorgt dat al mijn gedeployde files in een 'files.wxs' bestand komen.


Daarna heb ik een wix project met een product.wxs, waarin ik o.a. de website aanmaak etc.
Echter moet ik ook de files kopieren.

ik was van plan om zoiets te doen in mijn product.wxs:

XML:

<?include $(var.SolutionDir)BVI_deploy\$(var.Configuration)\files.wxs ?>

maar dat mag alleen wanneer 'files' een include file is (wxi, met starttag 'include')


Dit lijkt me iets wat iedereen doet, ik kan alleen helemaal nergens iets vinden op internet. of ik snap niet hoe je zo'n probleem oplost, of ik ben de enige die wix gebruikt...

help pls

[mindcrash]

Uh, waarom zo moeilijk doen? In Visual Studio 2010 zit Web Deploy support ingebakken. open het context menu van je Web App, klik op "package application" en je bent min of meer klaar...

Deployen doe je vervolgens door Web Deploy op een productiebak te installeren en dan krijg je een hele sloot mogelijkheden in IIS erbij (nieuwe site maken op basis van package, package in bestaande site importeren etcetera); tevens kun je ervoor kiezen om de package via het batch bestand wat tezamen met je package gegenereerd wordt uit te rollen.

http://www.iis.net/download/webdeploy

[ Voor 12% gewijzigd door mindcrash op 14-04-2011 08:38 ]

[CyBoB]

Als het goed is hoef je de gegenereerde wxs niet te includen. Als je er voor zorgt dat deze naast je andere wxs bestanden terecht komt dan zullen light en candle deze bij het compileren gewoon oppakken. Heat levert een bestand op met o.a. Component elementen genest in Fragment elementen. De compiler/linker voegt alle Fragment elementen samen tot een groot "script".

Als dat niet zo is dan zou je even naar de output van VS kunnen kijken om te zien welke commando's deze uitvoert. Eventueel zou je de gegenereerde file op kunnen nemen als project file. Deze wordt dan wel steeds overschreven, maar zo weet VS wel welke files hij mee moeten nemen in de MSI.

[BasieP]

mindcrash schreef op donderdag 14 april 2011 @ 08:36:
Uh, waarom zo moeilijk doen? In Visual Studio 2010 zit Web Deploy support ingebakken. open het context menu van je Web App, klik op "package application" en je bent min of meer klaar...

Deployen doe je vervolgens door Web Deploy op een productiebak te installeren en dan krijg je een hele sloot mogelijkheden in IIS erbij (nieuwe site maken op basis van package, package in bestaande site importeren etcetera); tevens kun je ervoor kiezen om de package via het batch bestand wat tezamen met je package gegenereerd wordt uit te rollen.

http://www.iis.net/download/webdeploy

1. we gebruiken nog visual studio 2008
2. we shippen .msi files, geen lose websites
3. we willen graag dat de gebruiker tijdens installatie dingen gevraagd worden (config settings etc.)
4. we kunnen vanuit bouw niet bij productie (en ik zou het slecht vinden als dat ergens wel kan)
5. we willen dezelfde techniek voor meerdere dingen (dus ook services/windows forms apps etc.)

CyBoB schreef op donderdag 14 april 2011 @ 08:49:
Als het goed is hoef je de gegenereerde wxs niet te includen. Als je er voor zorgt dat deze naast je andere wxs bestanden terecht komt dan zullen light en candle deze bij het compileren gewoon oppakken. Heat levert een bestand op met o.a. Component elementen genest in Fragment elementen. De compiler/linker voegt alle Fragment elementen samen tot een groot "script".

Als dat niet zo is dan zou je even naar de output van VS kunnen kijken om te zien welke commando's deze uitvoert. Eventueel zou je de gegenereerde file op kunnen nemen als project file. Deze wordt dan wel steeds overschreven, maar zo weet VS wel welke files hij mee moeten nemen in de MSI.

Mmm das interessant. Ik moet hem dan neem ik aan nog wel in mijn wix project includen?
En hoe zorg ik dan dat de bestanden in de juiste folders komen?

even ter voorbeeld:
in mijn product.wxs (hoofd wix bestand) staat:

XML:

<Directory Id='TARGETDIR' Name='SourceDir'>
      <Directory Id='ProgramFilesFolder' Name='PFiles'>
        <Directory Id='GroupFolder' Name='bedrijfsnaam'>
          <Directory Id='ApplicationFolder' Name='productnaam'>
            <Component Id='WebsiteComponent' Guid='ED6A7853-F91C-4fec-B338-5A6B8FE015D7'>
              <!-- ding doet hier dus website bouwen -->
            </Component>
          </Directory>
        </Directory>
      </Directory>
    </Directory>

nu wil ik in diezelfde dir ook mijn files kopieren.

in mijn gegenereerde wxs file staat zoiets:

XML:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <DirectoryRef Id="TARGETDIR">
            <Directory Id="dir99DE416F55C8960850D5A4FCA3758AD4" Name="Release" />
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <DirectoryRef Id="dir9CD8C8356CD3694E238AAEF8F724741E">
            <Component Id="cmp02C84B8B9DA833B0B3882E4215FD881D" Guid="08CDFCB8-DA86-429F-8DA2-B2E51B7E81B2">
                <File Id="fil48C1ACE800BC6ED9D493A31D3C6ECE0F" KeyPath="yes" Source="SourceDir\dir\server\index.html" />
            </Component>
        </DirectoryRef>
    </Fragment>
   <!-- hier meer fragments -->
</Wix>

Hoe weet ie nou welke files waar naartoe moeten?

[CyBoB]

Hoe weet ie nou welke files waar naartoe moeten?

Dat weet WiX op basis van dir DirectoryRef elementen. Een DirectoryRef verwijst altijd naar een Directory element. Met de Directory elementen bepaal je de structuur van de files zoals ze geinstalleerd worden. In een Fragment kan je hieraan refereren doormiddel van de DirectoryRef. De linker (light) zal uiteindelijk dat allemaal samennemen.

In jou voorbeeld wordt door heat TARGETDIR genomen als de id van de Directory. In jou voorbeeld is dat dus de root.

XML:

<Directory Id='TARGETDIR' Name='SourceDir'>  <!-- Dat is dus deze directory -->
      <Directory Id='ProgramFilesFolder' Name='PFiles'> 
        <Directory Id='GroupFolder' Name='bedrijfsnaam'> 
          <Directory Id='ApplicationFolder' Name='productnaam'> 
            <Component Id='WebsiteComponent' Guid='ED6A7853-F91C-4fec-B338-5A6B8FE015D7'> 
              <!-- ding doet hier dus website bouwen --> 
            </Component> 
          </Directory> 
        </Directory> 
      </Directory> 
    </Directory>

Ik weet eigenlijk zonder te testen niet zo goed waar de bestanden dan terecht komen, maar ik vermoed in de root van de opgegeven schijf (c:\).

Je kan echter via een parameter van heat het id van de DirectoryRef die gegeneerd wordt aanpassen. Dit is de parameter -dr <naam>.

Als ik het volgende commando uitvoer in mijn WiX dir:

heat dir . -dr MyDir -o MyOutput.wxs

dan komt er iets uit als:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <DirectoryRef Id="MyDir">
            <Directory Id="dirD5BF427BA37FA7B68FFE4EC213ABFB3D" Name="bin" />
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <DirectoryRef Id="dirD5BF427BA37FA7B68FFE4EC213ABFB3D">
            <Component Id="cmpFAF315A560EE62BAA7068D1C307DFFFE" Guid="PUT-GUID-HERE">
                <File Id="filC08D76F6F6C6F0C8106DCAEF7C3B7C73" KeyPath="yes" Source="SourceDir\burnstub.exe" />
            </Component>
            <Component Id="cmp7747D11F425FAC6089B3EC36C1C56517" Guid="PUT-GUID-HERE">
                <File Id="fil5D2D2F12E41682137DAB867174A25BDB" KeyPath="yes" Source="SourceDir\candle.exe" />
            </Component>
            <Component Id="cmp52FA55201190EB13DDB2D469F6599798" Guid="PUT-GUID-HERE">
                <File Id="filBE2E9CB24EFE1CF4F357992892C672E9" KeyPath="yes" Source="SourceDir\candle.exe.config" />
            </Component>
            <Component Id="cmpC843454EB006C2D10B5B258364D06319" Guid="PUT-GUID-HERE">
                <File Id="fil765F6E5307D533A3820A287E497F4A64" KeyPath="yes" Source="SourceDir\darice.cub" />
            </Component>
...

Als je in je Product dan iets hebt als:

XML:

<Product>
<Directory Id='TARGETDIR' Name='SourceDir'> 
   <Directory Id='ProgramFilesFolder'> 
      <Directory Id='MyAppName' Name='Foo'> 
         <Directory Id='MyDir' Name='WebBestanden'/>
      </Directory>
   </Directory> 
</Product>

Wanneer je dan beide wxs bestand door candle heen haalt en vervolgens linkt met light, dan zullen je bestand in "C:\Program Files\Foo\WebBestanden\...<al je heat bestanden + subdirectories hier>" terecht moeten komen.

Deze constructie wordt veel toegepast in WiX. Zo kan je de "code" netjes opsplitsen in verschillende bestanden. Je doet het automatisch al bij het bepalen van je Features. Daar doe je ook iets als

XML:

<Feature ...>
 <ComponentRef Id=''/>
</Feature>

Dit is dan ook meteen een aandachtspunt want je moet er eigenlijk ook voor zorgen dat heat een ComponentGroup genereert. Anders ben je een uur bezig om alle ComponentRef's in je Features op te nemen.

heat dir . -dr MyDir -cg WebComponentGroup -o MyOutput.wxs

Vervolgens kan je in je feature het volgende doen:

XML:

<Feature ..>
   <ComponentGroupRef Id='WebComponentGroup'/>
</Feature>

Hoop dat dit wat duidelijkheid verschaft. Heeft mij ook even geduurt voordat ik het onder de knie had

[ Voor 0% gewijzigd door CyBoB op 15-04-2011 08:50 . Reden: typos ]

[BasieP]

thanx CyBoB, maandag ga ik direct kijken (ik laat het weten)

[BasieP]

edit:

aargh tikfout

werkt als een zonnetje

bedankt allen

[ Voor 111% gewijzigd door BasieP op 18-04-2011 09:06 ]

[BasieP]

oke sorry dat ik nog een keer een reactie plaats, maar ik heb nog 1 vraagje.

Ik heb nu dus twee projecten in visual studio. Een deploy project, dat ook heat aftrapt, en een installer project dat de door heat gegenereerde wxs bouwt.

Nu heb ik wat moeite met de paden.

mijn deploy project deployed files in :
.\deploy_project\bin\release\
bijvoorbeeld:
.\deploy_project\bin\release\default.aspx

deploy project trapt heat af die een file genereerd in vanuit de 'release' map op de locatie:
.\instal_project\
De file die dus gegenereerd wordt staat in
.\install_project\files.wxs

in de wxs file staan verwijzingen naar
SourceDir\.... <hier mijn files>
dus bijv.
SourceDir\default.aspx

Wanneer ik dan candle draai vanuit
.\instal_project\ krijg ik fouten
The system cannot find the file 'SourceDir\default.aspx'

en dat klopt want die staat ook niet in:
.\instal_project\default.aspx
, maar in
.\deploy_project\bin\release\default.aspx

nu kan ik bij mijn deploy wel deployen naar een andere directory of een copy slag doen, maar dat vind ik niet zo netjes..
zijn hier ook standaard oplossingen voor?

[CyBoB]

Misschien lukt het via de FileSource attribute van het Directory element?

XML:

<Directory Id="INSTALLLOCATION" Name="MyApp $(var.Version)" FileSource="..\MyApp\bin\$(var.Configuration)" >

Of kijk anders naar de -var parameter waarmee je de default File/@Source waarde kan voorafgaan met een preprocessor variabele. Die je vervolgens kan configureren naar een specifieke locatie.

Voor alle parameters zie:

heat -?

[BasieP]

het is nu inderdaad met var gelukt.
ik voer nu heat uit met

heat -var var.WebsiteFolderSource

ik snap het absoluut niet, want hoe weet heat nou dat als ik een var toevoeg waar hij hem moet gebruiken, maar wonderbaarlijk genoeg plakt hij hem precies op de goede plek.

hij genereerd dan ipv:

XML:

<File Id="fil8FF2C1E82673CC2D0099C481307B00C2" KeyPath="yes" Source="SourceDir\Default.aspx" />

dit:

XML:

<File Id="fil8FF2C1E82673CC2D0099C481307B00C2" KeyPath="yes" Source="$(var.WebsiteFolderSource)\Default.aspx" />

[CyBoB]

BasieP schreef op maandag 18 april 2011 @ 15:45:
...
ik snap het absoluut niet, want hoe weet heat nou dat als ik een var toevoeg waar hij hem moet gebruiken, maar wonderbaarlijk genoeg plakt hij hem precies op de goede plek.
...

Dat is gewoon hardcoded lijkt me. Kon het even niet zo snel vinden in de source op codeplex, maar gezien de helptekst is er maar 1x een -var parameter mogelijk en is de plek hardcoded..