Search Results

Search found 32 results on 2 pages for 'wxs'.

Page 1/2 | 1 2  | Next Page >

• WiX 3 Tutorial: Understanding main WXS and WXI file

  - by Mladen Prajdic

  In the previous post we’ve taken a look at the WiX solution/project structure and project properties. We’re still playing with our super SuperForm application and today we’ll take a look at the general parts of the main wxs file, SuperForm.wxs, and the wxi include file. For wxs file we’ll just go over the general description of what each part does in the code comments. The more detailed descriptions will be in future posts about features themselves. WXI include file Include files are exactly what their name implies. To include a wxi file into the wxs file you have to put the wxi at the beginning of each .wxs file you wish to include it in. If you’ve ever worked with C++ you can think of the include files as .h files. For example if you include SuperFormVariables.wxi into the SuperForm.wxs, the variables in the wxi won’t be seen in FilesFragment.wxs or RegistryFragment.wxs. You’d have to include it manually into those two wxs files too. For preprocessor variable $(var.VariableName) to be seen by every file in the project you have to include them in the WiX project properties->Build->“Define preprocessor variables” textbox. This is why I’ve chosen not to go this route because in multi developer teams not everyone has the same directory structure and having a single variable would mean each developer would have to checkout the wixproj file to edit the variable. This is pretty much unacceptable by my standards. This is why we’ve added a System Environment variable named SuperFormFilesDir as is shown in the previous Wix Tutorial post. Because the FilesFragment.wxs is autogenerated on every project build we don’t want to change it manually each time by adding the include wxi at the beginning of the file. This way we couldn’t recreate it in each pre-build event. <?xml version="1.0" encoding="utf-8"?><Include> <!-- Versioning. These have to be changed for upgrades. It's not enough to just include newer files. --> <?define MajorVersion="1" ?> <?define MinorVersion="0" ?> <?define BuildVersion="0" ?> <!-- Revision is NOT used by WiX in the upgrade procedure --> <?define Revision="0" ?> <!-- Full version number to display --> <?define VersionNumber="$(var.MajorVersion).$(var.MinorVersion).$(var.BuildVersion).$(var.Revision)" ?> <!-- Upgrade code HAS to be the same for all updates. Once you've chosen it don't change it. --> <?define UpgradeCode="YOUR-GUID-HERE" ?> <!-- Path to the resources directory. resources don't really need to be included in the project structure but I like to include them for for clarity --> <?define ResourcesDir="$(var.ProjectDir)\Resources" ?> <!-- The name of your application exe file. This will be used to kill the process when updating and creating the desktop shortcut --> <?define ExeProcessName="SuperForm.MainApp.exe" ?></Include> For now there’s no way to tell WiX in Visual Studio to have a wxi include file available to the whole project, so you have to include it in each file separately. Only variables set in “Define preprocessor variables” or System Environment variables are accessible to the whole project for now. The main WXS file: SuperForm.wxs We’ll only take a look at the general structure of the main SuperForm.wxs and not its the details. We’ll cover the details in future posts. The code comments should provide plenty info about what each part does in general. Basically there are 5 major parts. The update part, the conditions and actions part, the UI install sequence, the directory structure and the features we want to include. <?xml version="1.0" encoding="UTF-8"?><!-- Add xmlns:util namespace definition to be able to use stuff from WixUtilExtension dll--><Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"> <!-- This is how we include wxi files --> <?include $(sys.CURRENTDIR)Includes\SuperFormVariables.wxi ?> <!-- Id="*" is to enable upgrading. * means that the product ID will be autogenerated on each build. Name is made of localized product name and version number. --> <Product Id="*" Name="!(loc.ProductName) $(var.VersionNumber)" Language="!(loc.LANG)" Version="$(var.VersionNumber)" Manufacturer="!(loc.ManufacturerName)" UpgradeCode="$(var.UpgradeCode)"> <!-- Define the minimum supported installer version (3.0) and that the install should be done for the whole machine not just the current user --> <Package InstallerVersion="300" Compressed="yes" InstallScope="perMachine"/> <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" /> <!-- Upgrade settings. This will be explained in more detail in a future post --> <Upgrade Id="$(var.UpgradeCode)"> <UpgradeVersion OnlyDetect="yes" Minimum="$(var.VersionNumber)" IncludeMinimum="no" Property="NEWER_VERSION_FOUND" /> <UpgradeVersion Minimum="0.0.0.0" IncludeMinimum="yes" Maximum="$(var.VersionNumber)" IncludeMaximum="no" Property="OLDER_VERSION_FOUND" /> </Upgrade> <!-- Reference the global NETFRAMEWORK35 property to check if it exists --> <PropertyRef Id="NETFRAMEWORK35"/> <!-- Startup conditions that checks if .Net Framework 3.5 is installed or if we're running the OS higher than Windows XP SP2. If not the installation is aborted. By doing the (Installed OR ...) property means that this condition will only be evaluated if the app is being installed and not on uninstall or changing --> <Condition Message="!(loc.DotNetFrameworkNeeded)"> <![CDATA[Installed OR NETFRAMEWORK35]]> </Condition> <Condition Message="!(loc.AppNotSupported)"> <![CDATA[Installed OR ((VersionNT >= 501 AND ServicePackLevel >= 2) OR (VersionNT >= 502))]]> </Condition> <!-- This custom action in the InstallExecuteSequence is needed to stop silent install (passing /qb to msiexec) from going around it. --> <CustomAction Id="NewerVersionFound" Error="!(loc.SuperFormNewerVersionInstalled)" /> <InstallExecuteSequence> <!-- Check for newer versions with FindRelatedProducts and execute the custom action after it --> <Custom Action="NewerVersionFound" After="FindRelatedProducts"> <![CDATA[NEWER_VERSION_FOUND]]> </Custom> <!-- Remove the previous versions of the product --> <RemoveExistingProducts After="InstallInitialize"/> <!-- WixCloseApplications is a built in custom action that uses util:CloseApplication below --> <Custom Action="WixCloseApplications" Before="InstallInitialize" /> </InstallExecuteSequence> <!-- This will ask the user to close the SuperForm app if it's running while upgrading --> <util:CloseApplication Id="CloseSuperForm" CloseMessage="no" Description="!(loc.MustCloseSuperForm)" ElevatedCloseMessage="no" RebootPrompt="no" Target="$(var.ExeProcessName)" /> <!-- Use the built in WixUI_InstallDir GUI --> <UIRef Id="WixUI_InstallDir" /> <UI> <!-- These dialog references are needed for CloseApplication above to work correctly --> <DialogRef Id="FilesInUse" /> <DialogRef Id="MsiRMFilesInUse" /> <!-- Here we'll add the GUI logic for installation and updating in a future post--> </UI> <!-- Set the icon to show next to the program name in Add/Remove programs --> <Icon Id="SuperFormIcon.ico" SourceFile="$(var.ResourcesDir)\Exclam.ico" /> <Property Id="ARPPRODUCTICON" Value="SuperFormIcon.ico" /> <!-- Installer UI custom pictures. File names are made up. Add path to your pics. –> <!-- <WixVariable Id="WixUIDialogBmp" Value="MyAppLogo.jpg" /> <WixVariable Id="WixUIBannerBmp" Value="installBanner.jpg" /> --> <!-- the default directory structure --> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLLOCATION" Name="!(loc.ProductName)" /> </Directory> </Directory> <!-- Set the default install location to the value of INSTALLLOCATION (usually c:\Program Files\YourProductName) --> <Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /> <!-- Set the components defined in our fragment files that will be used for our feature --> <Feature Id="SuperFormFeature" Title="!(loc.ProductName)" Level="1"> <ComponentGroupRef Id="SuperFormFiles" /> <ComponentRef Id="cmpVersionInRegistry" /> <ComponentRef Id="cmpIsThisUpdateInRegistry" /> </Feature> </Product></Wix> For more info on what certain attributes mean you should look into the WiX Documentation.   WiX 3 tutorial by Mladen Prajdic navigation WiX 3 Tutorial: Solution/Project structure and Dev resources WiX 3 Tutorial: Understanding main wxs and wxi file WiX 3 Tutorial: Generating file/directory fragments with Heat.exe

  Read the article

• WiX: Define made in included file not avaible from wxs-file.

  - by leiflundgren

  I have a defines.wxi-file which contains some good definitions used in all my wxs-files. When I attempt to reference the defined value I get Undefined preprocessor variable '$(var.MAGE_FOLDER)' back in my face. I guess there is something trivial I am missing here... Any ideas? defines.wxi <Include> <?define IMAGE_FOLDER="Images" ?> </Include> Product.wxs <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <?Include defines.wxi ?> <Product ... > <Component Id='c.Images' Directory='$(var.IMAGE_FOLDER)' />

  Read the article

• WiX: Define made in included file not avaible from wxs-fragment-file.

  - by leiflundgren

  I have a defines.wxi-file which contains some good definitions used in all my wxs-files. When I attempt to reference the defined value from one of the <Fragment>-files I get Undefined preprocessor variable '$(var.IMAGE_FOLDER)' back in my face. I guess there is something trivial I am missing here... Any ideas? Edit 19:th April. Found that issue only occurs if reference from a Fragment-file. Re-wrote sample to match that. defines.wxi <Include> <?define IMAGE_FOLDER="Images" ?> </Include> some-Fragment.wxs <Fragment> <?Include defines.wxi ?> <Component Id='c.Images' Guid=".." Directory='INSTALLDIR.Images' > <File Id='f.sample.jpg' Source='$(var.IMAGE_FOLDER)sample.jpg' Name='sample.jpg' /> </Component>

  Read the article

• WiX 3 Tutorial: Generating file/directory fragments with Heat.exe

  - by Mladen Prajdic

  In previous posts I’ve shown you our SuperForm test application solution structure and how the main wxs and wxi include file look like. In this post I’ll show you how to automate inclusion of files to install into your build process. For our SuperForm application we have a single exe to install. But in the real world we have 10s or 100s of different files from dll’s to resource files like pictures. It all depends on what kind of application you’re building. Writing a directory structure for so many files by hand is out of the question. What we need is an automated way to create this structure. Enter Heat.exe. Heat is a command line utility to harvest a file, directory, Visual Studio project, IIS website or performance counters. You might ask what harvesting means? Harvesting is converting a source (file, directory, …) into a component structure saved in a WiX fragment (a wxs) file. There are 2 options you can use: Create a static wxs fragment with Heat and include it in your project. The pro of this is that you can add or remove components by hand. The con is that you have to do the pro part by hand. Automation always beats manual labor. Run heat command line utility in a pre-build event of your WiX project. I prefer this way. By always recreating the whole fragment you don’t have to worry about missing any new files you add. The con of this is that you’ll include files that you otherwise might not want to. There is no perfect solution so pick one and deal with it. I prefer using the second way. A neat way of overcoming the con of the second option is to have a post-build event on your main application project (SuperForm.MainApp in our case) to copy the files needed to be installed in a special location and have the Heat.exe read them from there. I haven’t set this up for this tutorial and I’m simply including all files from the default SuperForm.MainApp \bin directory. Remember how we created a System Environment variable called SuperFormFilesDir? This is where we’ll use it for the first time. The command line text that you have to put into the pre-build event of your WiX project looks like this: "$(WIX)bin\heat.exe" dir "$(SuperFormFilesDir)" -cg SuperFormFiles -gg -scom -sreg -sfrag -srd -dr INSTALLLOCATION -var env.SuperFormFilesDir -out "$(ProjectDir)Fragments\FilesFragment.wxs" After you install WiX you’ll get the WIX environment variable. In the pre/post-build events environment variables are referenced like this: $(WIX). By using this you don’t have to think about the installation path of the WiX. Remember: for 32 bit applications Program files folder is named differently between 32 and 64 bit systems. $(ProjectDir) is obviously the path to your project and is a Visual Studio built in variable. You can view all Heat.exe options by running it without parameters but I’ll explain some that stick out the most. dir "$(SuperFormFilesDir)": tell Heat to harvest the whole directory at the set location. That is the location we’ve set in our System Environment variable. –cg SuperFormFiles: the name of the Component group that will be created. This name is included in out Feature tag as is seen in the previous post. -dr INSTALLLOCATION: the directory reference this fragment will fall under. You can see the top level directory structure in the previous post. -var env.SuperFormFilesDir: the name of the variable that will replace the SourceDir text that would otherwise appear in the fragment file. -out "$(ProjectDir)Fragments\FilesFragment.wxs": the full path and name under which the fragment file will be saved. If you have source control you have to include the FilesFragment.wxs into your project but remove its source control binding. The auto generated FilesFragment.wxs for our test app looks like this: <?xml version="1.0" encoding="utf-8"?><Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Fragment> <ComponentGroup Id="SuperFormFiles"> <ComponentRef Id="cmp5BB40DB822CAA7C5295227894A07502E" /> <ComponentRef Id="cmpCFD331F5E0E471FC42A1334A1098E144" /> <ComponentRef Id="cmp4614DD03D8974B7C1FC39E7B82F19574" /> <ComponentRef Id="cmpDF166522884E2454382277128BD866EC" /> </ComponentGroup> </Fragment> <Fragment> <DirectoryRef Id="INSTALLLOCATION"> <Component Id="cmp5BB40DB822CAA7C5295227894A07502E" Guid="{117E3352-2F0C-4E19-AD96-03D354751B8D}"> <File Id="filDCA561ABF8964292B6BC0D0726E8EFAD" KeyPath="yes" Source="$(env.SuperFormFilesDir)\SuperForm.MainApp.exe" /> </Component> <Component Id="cmpCFD331F5E0E471FC42A1334A1098E144" Guid="{369A2347-97DD-45CA-A4D1-62BB706EA329}"> <File Id="filA9BE65B2AB60F3CE41105364EDE33D27" KeyPath="yes" Source="$(env.SuperFormFilesDir)\SuperForm.MainApp.pdb" /> </Component> <Component Id="cmp4614DD03D8974B7C1FC39E7B82F19574" Guid="{3443EBE2-168F-4380-BC41-26D71A0DB1C7}"> <File Id="fil5102E75B91F3DAFA6F70DA57F4C126ED" KeyPath="yes" Source="$(env.SuperFormFilesDir)\SuperForm.MainApp.vshost.exe" /> </Component> <Component Id="cmpDF166522884E2454382277128BD866EC" Guid="{0C0F3D18-56EB-41FE-B0BD-FD2C131572DB}"> <File Id="filF7CA5083B4997E1DEC435554423E675C" KeyPath="yes" Source="$(env.SuperFormFilesDir)\SuperForm.MainApp.vshost.exe.manifest" /> </Component> </DirectoryRef> </Fragment></Wix> The $(env.SuperFormFilesDir) will be replaced at build time with the directory where the files to be installed are located. There is nothing too complicated about this. In the end it turns out that this sort of automation is great! There are a few other ways that Heat.exe can compose the wxs file but this is the one I prefer. It just seems the clearest. Play with its options to see what can it do. It’s one awesome little tool.   WiX 3 tutorial by Mladen Prajdic navigation WiX 3 Tutorial: Solution/Project structure and Dev resources WiX 3 Tutorial: Understanding main wxs and wxi file WiX 3 Tutorial: Generating file/directory fragments with Heat.exe

  Read the article

• WiX unresolved reference error

  - by David

  I'm using Wix version 3.0.5419.0. I have two .wxs files, one which is a fragment, and another which uses the fragment to create the .msi file. Here is the file which uses the fragment (DaisyFarmer.wxs): <?xml version='1.0' encoding='windows-1252'?> <Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' xmlns:iis='http://schemas.microsoft.com/wix/IIsExtension'> <Product Name='Daisy Web Site 1.0' Id='BB7FBBE4-0A25-4cc7-A39C-AC916B665220' UpgradeCode='8A5311DE-A125-418f-B0E1-5A30B9C667BD' Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='the man'> <Package Id='5F341544-4F95-4e01-A2F8-EF74448C0D6D' Keywords='Installer' Description="desc" Manufacturer='the man' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' /> <Media Id='1' Cabinet='Sample.cab' EmbedCab='yes' DiskPrompt="CD-ROM #1" /> <Property Id='DiskPrompt' Value="the man" /> <PropertyRef Id="NETFRAMEWORK35"/> <Condition Message='This setup requires the .NET Framework 3.5.'> <![CDATA[Installed OR (NETFRAMEWORK35)]]> </Condition> <Feature Id='DaisyFarmer' Title='DaisyFarmer' Level='1'> <ComponentRef Id='SchedulerComponent' /> </Feature> </Product> </Wix> The fragment I'm referencing is (Scheduler.wxs): <?xml version="1.0" encoding="utf-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Fragment> <DirectoryRef Id="TARGETDIR"> <Directory Id="dir2787390E4B7313EB8005DE08108EFEA4" Name="scheduler"> <Component Id="SchedulerComponent" Guid="{9254F7E1-DE41-4EE5-BC0F-BA668AF051CB}"> <File Id="fil9A013D0BFB837BAC71FED09C59C5501B" KeyPath="yes" Source="SourceDir\DTBookMonitor.exe" /> <File Id="fil4F0D8D05F53E6AFBDB498E7C75C2D98F" KeyPath="no" Source="SourceDir\DTBookMonitor.exe.config" /> <File Id="filF02F4686267D027CB416E044E8C8C2FA" KeyPath="no" Source="SourceDir\monitor.bat" /> <File Id="fil05B8FF38A3C85FE6C4A58CD6FDFCD2FB" KeyPath="no" Source="SourceDir\output.txt" /> <File Id="fil397F04E2527DCFDF7E8AC1DD92E48264" KeyPath="no" Source="SourceDir\pipelineOutput.txt" /> <File Id="fil83DFACFE7F661A9FF89AA17428474929" KeyPath="no" Source="SourceDir\process.bat" /> <File Id="fil2809039236E0072642C52C6A52AD6F2F" KeyPath="no" Source="SourceDir\README.txt" /> </Component> </Directory> </DirectoryRef> </Fragment> </Wix> I then run the following commands: candle -ext WixUtilExtension -ext WiXNetFxExtension DaisyFarmer.wxs Scheduler.wxs light -sice:ICE20 -ext WixUtilExtension -ext WiXNetFxExtension Scheduler.wixobj DaisyFarmer.wixobj -out DaisyFarmer.msi I'm getting an error when I run light.exe which says "DaisyFarmer.wxs(20) : error LGHT0094 : Unresolved reference to symbol 'Component:SchedulerComponent' in section 'Product:{BB7FBBE4-0A25-4CC7-A39C-AC916B665220}'." What am I missing?

  Read the article

• Disqus-like comment server

  - by wxs

  I'm looking at setting up a blog, and I think I want to go the static website compiler route, rather than the perhaps more conventional Wordpress route. I'm looking at using blogofile, but could use jekyll as well. These tools recommend using disqus to embed a javascript comment widget on blog posts. I'd go that route, but I'd rather host the comments myself, rather than use a third party. I could certainly write my own dirt-simple comment server, but I was wondering if anyone knew of one that already exists (of the open source variety). Thanks!

  Read the article

• Disqus-like comment server

  - by wxs

  Hi all, I'm looking at setting up a blog, and I think I want to go the static website compiler route, rather than the perhaps more conventional Wordpress route. I'm looking at using blogofile, but could use jekyll as well. These tools recommend using disqus to embed a javascript comment widget on blog posts. I'd go that route, but I'd rather host the comments myself, rather than use a third party. I could certainly write my own dirt-simple comment server, but I was wondering if anyone knew of one that already exists (of the open source variety). Thanks!

  Read the article

• How do I share a WiX fragment in two WiX projects?

  - by Randy Eppinger

  We have a WiX fragment in a file SomeDialog.wxs that prompts the user for some information. It's referenced in another fragment in InstallerUI.wxs file that controls the dialog order. Of course, Product.wxs is our main file. Works great. Now I have a second Visual Studio 2008 Wix 3.0 Project for the .MSI of another application and it needs to ask the user for the same information. I can't seem to figure out the best way to share the file so that changing the information requested will result in both .MSIs getting the new behavior. I honestly can't tell if a merge module, an .wsi (include) or a .wixlib is the right solution. I would have hoped to find a simple example of someone doing this but I have failed thus far. Edit: Based on Rob Mensching's wixlib blog entry, a wixlib may be the answer, but I am still searching for an example of how to do this.

  Read the article

• Link to audio in XHTML/EPUB

  - by wxs

  I'm looking into synchronizing an ebook in epub format (so the content is in XHTML) to an audio file. I'm thinking of putting something along the lines of: <a class="audiolink" href="sound.ogg?t=1093"></a> into the body of the document, and then have a custom epub reader that recognizes those tags and synchronizes the audio accordingly. That does seem like a bit of a hack to me though, especially the use of a special class name. Does anyone have any pointers to how this may be done in a more standards-compliant manner (or somewhere where it has been done before)? Ebooks with audio annotation seem like an idea that may already be out there.

  Read the article

• Disable globbing in PHP exec()

  - by wxs

  I have a PHP script which calls another script in order to add IP addresses to a whitelist. I sometimes want to whitelist all addresses, in which case I have it call exec("otherscript *.*.*.*", output, retval); This worked fine, adding the string "*.*.*.*" to the whitelist until I happened to have another file in the directory of the php script that matched that pattern ("foo.1.tar.gz"), at which point the wildcards were expanded, and I ended up with the filename in my whitelist. Is there some way to disable globbing in php's exec? It isn't mentioned in the PHP docs as far as I can tell.

  Read the article

• How To Run MSBuild scripts in .wixproj?

  - by hisoka21

  Im trying to learn to make a web installer using Windows Installer XML (WIX 3.5). I found this blog about using msbuild in .wixproj files to avoid the scenario where the installer ends up dropping the web project assemblies right in the root of the app instead of keeping them in the bin folder like they're supposed to be. Here is the link to that: <http://www.paraesthesia.com/archive/2010/07/30/how-to-consume-msdeploy-staged-web-site-output-in-a.aspx But after adding the MSBuild scripts in the .wixproj file, I don't know what to do anymore. According to the instruction after adding the MSBuild script: "When that target runs, you'll see a .wxs file pop out in the .wixproj project folder. Add the generated .wxs to your .wixproj project so it knows to include it in the build." I really don7t know what this means. How can I run the target? I tried to build it but there was no .wxs file generated in the .wixproj folder. Am I missing something? Please help...

  Read the article

• Reference WiX define made in included file.

  - by leiflundgren

  I have a defines.wxi-file which contains some good definitions used in all my wxs-files. When I attempt to reference the defined value I get Undefined preprocessor variable '$(var.MAGE_FOLDER)' back in my face. I guess there is something trivial I am missing here... Any ideas? defines.wxi <Include> <?define IMAGE_FOLDER="Images" ?> </Include> Product.wxs <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <?Include defines.wxi ?> <Product ... > <Component Id='c.Images' Directory='$(var.IMAGE_FOLDER)' />

  Read the article

• Localize WiX installer which uses the Firewall extension

  - by tronda

  I've got a WiX installer project which uses MSBuild to generate the MSI file. The WXS file includes the WiX firewall extension: xmlns:fire="http://schemas.microsoft.com/wix/FirewallExtension" I've defined two cultures in the MSBuild file with the following definition: <PropertyGroup> ... <Cultures>en-us;no-no</Cultures> </PropertyGroup> I've also added the translated resources: <ItemGroup> <EmbeddedResource Include="lang\Firewall_no-no.wxl" /> <EmbeddedResource Include="lang\WixUI_no-no.wxl" /> </ItemGroup> These represents translation to Norwegian for the Firewall extension and the WixUI extension. When I run the build it succeeds with the en-us part, but the no-no part fails with the following error messages: C:\delivery\Dev\wix30_public\src\ext\FirewallExtension\wixlib\FirewallExtension.wxs(19): error LGHT0102: The localization variable !(loc.WixSchedFirewallExceptionsInstall) is unknown. Please ensure the variable is defined. .... Couple of issues: I don't know where the C:\delivery directory comes from. I don't have such a directory. The localization variables referenced in the error message have been translated in the Firewall_no-no.wxl file. When I run MSBuild with more detailed information I see the following output right before the error message: Task "Light" Command: C:\Program Files (x86)\Windows Installer XML v3\bin\Light.exe -cultures:no-no -ext "C:\Program Files (x86)\Windows Installer XML v3\bin\WixUIExtension.dll" -ext "C:\Program Files (x86)\Windows I nstaller XML v3\bin\WixUtilExtension.dll" -ext "C:\Program Files (x86)\Windows Installer XML v3\bin\WixFirewallExtension.dll" -loc lang\Firewall_no-no.wxl -loc lang\WixUI_no-no.wxl -out F:\Projects\MyProd\MyProj\Installer\bin\Debug\no-no\MyInstaller.msi -pdbout F:\Projects\MyProd\MyProj\Installer\bin\Debug\no-no\MyInstaller.wixpdb obj\Debug\MyProj.wixobj As the details show, the MSBuild task results in having two -loc parameters to the Light executable. Not sure if that would be the reason for this problem. Any ideas on how to solve this?

  Read the article

• Adding shortcut for WiX file in a different fragment.

  - by matt

  I'm using heat.exe to generate fragments similar to this: <Fragment> <DirectoryRef Id="INSTALLDIR"> <Component Id="id1" Guid="*"> <File Id="fid1" KeyPath="yes" Source="SourceDir\Foo1.dll" /> </Component> <Component Id="id2" Guid="*"> <File Id="fid2" KeyPath="yes" Source="SourceDir\Foo2.dll" /> </Component> <Component Id="id3" Guid="*"> <File Id="fid3" KeyPath="yes" Source="SourceDir\Bar.exe" /> </Component> </DirectoryRef> </Fragment> <Fragment> <ComponentGroup Id="Components"> <ComponentRef Id="id1" /> <ComponentRef Id="id2" /> <ComponentRef Id="id3" /> </ComponentGroup> </Fragment> These fragments are stored in the auto-generated wxs file. I'm then adding them into my feature (in the main WiX file) like so: <ComponentGroupRef Id="Components"/> This works fine. However, I'd also like to add a shortcut to Bar.exe to my start menu. I ideally want to do this in my main wix file, with the Bar.exe component still residing in the auto-generated wxs file. How would I approach this problem without modifying the auto-generated code?

  Read the article

• Compilation error - ICE80: The 64BitComponent ... uses 32BitDirectory ...

  - by Chris Ballance

  The following line Generates the following error: Error 4 ICE80: This 64BitComponent GlobalScopePackages uses 32BitDirectory blablabla c:\development\...\file.wxs Error is described on this page http://msdn.microsoft.com/en-us/library/aa369034%28VS.85%29.aspx How do I fix this or suppress the warning? Is it safe to simply supress the warning?

  Read the article

• WiX 3 Tutorial: Custom EULA License and MSI localization

  - by Mladen Prajdic

  In this part of the ongoing Wix tutorial series we’ll take a look at how to localize your MSI into different languages. We’re still the mighty SuperForm: Program that takes care of all your label color needs. :) Localizing the MSI With WiX 3.0 localizing an MSI is pretty much a simple and straightforward process. First let look at the WiX project Properties->Build. There you can see "Cultures to build" textbox. Put specific cultures to build into the testbox or leave it empty to build all of them. Cultures have to be in correct culture format like en-US, en-GB or de-DE. Next we have to tell WiX which cultures we actually have in our project. Take a look at the first post in the series about Solution/Project structure and look at the Lang directory in the project structure picture. There we have de-de and en-us subfolders each with its own localized stuff. In the subfolders pay attention to the WXL files Loc_de-de.wxl and Loc_en-us.wxl. Each one has a <String Id="LANG"> under the WixLocalization root node. By including the string with id LANG we tell WiX we want that culture built. For English we have <String Id="LANG">1033</String>, for German <String Id="LANG">1031</String> in Loc_de-de.wxl and for French we’d have to create another file Loc_fr-FR.wxl and put <String Id="LANG">1036</String>. WXL files are localization files. Any string we want to localize we have to put in there. To reference it we use loc keyword like this: !(loc.IdOfTheVariable) => !(loc.MustCloseSuperForm) This is our Loc_en-us.wxl. Note that German wxl has an identical structure but values are in German. <?xml version="1.0" encoding="utf-8"?><WixLocalization Culture="en-us" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252"> <String Id="LANG">1033</String> <String Id="ProductName">SuperForm</String> <String Id="LicenseRtf" Overridable="yes">\Lang\en-us\EULA_en-us.rtf</String> <String Id="ManufacturerName">My Company Name</String> <String Id="AppNotSupported">This application is is not supported on your current OS. Minimal OS supported is Windows XP SP2</String> <String Id="DotNetFrameworkNeeded">.NET Framework 3.5 is required. Please install the .NET Framework then run this installer again.</String> <String Id="MustCloseSuperForm">Must close SuperForm!</String> <String Id="SuperFormNewerVersionInstalled">A newer version of !(loc.ProductName) is already installed.</String> <String Id="ProductKeyCheckDialog_Title">!(loc.ProductName) setup</String> <String Id="ProductKeyCheckDialogControls_Title">!(loc.ProductName) Product check</String> <String Id="ProductKeyCheckDialogControls_Description">Plese Enter following information to perform the licence check.</String> <String Id="ProductKeyCheckDialogControls_FullName">Full Name:</String> <String Id="ProductKeyCheckDialogControls_Organization">Organization:</String> <String Id="ProductKeyCheckDialogControls_ProductKey">Product Key:</String> <String Id="ProductKeyCheckDialogControls_InvalidProductKey">The product key you entered is invalid. Please call user support.</String> </WixLocalization>   As you can see from the file we can use localization variables in other variables like we do for SuperFormNewerVersionInstalled string. ProductKeyCheckDialog* strings are to localize a custom dialog for Product key check which we’ll look at in the next post. Built in dialog text localization Under the de-de folder there’s also the WixUI_de-de.wxl file. This files contains German translations of all texts that are in WiX built in dialogs. It can be downloaded from WiX 3.0.5419.0 Source Forge site. Download the wix3-sources.zip and go to \src\ext\UIExtension\wixlib. There you’ll find already translated all WiX texts in 12 Languages. Localizing the custom EULA license Here it gets ugly. We can override the default EULA license easily by overriding WixUILicenseRtf WiX variable like this: <WixVariable Id="WixUILicenseRtf" Value="License.rtf" /> where License.rtf is the name of your custom EULA license file. The downside of this method is that you can only have one license file which means no localization for it. That’s why we need to make a workaround. License is checked on a dialog name LicenseAgreementDialog. What we have to do is overwrite that dialog and insert the functionality for localization. This is a code for LicenseAgreementDialogOverwritten.wxs, an overwritten LicenseAgreementDialog that supports localization. LicenseAcceptedOverwritten replaces the LicenseAccepted built in variable. <?xml version="1.0" encoding="UTF-8" ?><Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Fragment> <UI> <Dialog Id="LicenseAgreementDialogOverwritten" Width="370" Height="270" Title="!(loc.LicenseAgreementDlg_Title)"> <Control Id="LicenseAcceptedOverwrittenCheckBox" Type="CheckBox" X="20" Y="207" Width="330" Height="18" CheckBoxValue="1" Property="LicenseAcceptedOverwritten" Text="!(loc.LicenseAgreementDlgLicenseAcceptedCheckBox)" /> <Control Id="Back" Type="PushButton" X="180" Y="243" Width="56" Height="17" Text="!(loc.WixUIBack)" /> <Control Id="Next" Type="PushButton" X="236" Y="243" Width="56" Height="17" Default="yes" Text="!(loc.WixUINext)"> <Publish Event="SpawnWaitDialog" Value="WaitForCostingDlg">CostingComplete = 1</Publish> <Condition Action="disable"> <![CDATA[ LicenseAcceptedOverwritten <> "1" ]]> </Condition> <Condition Action="enable">LicenseAcceptedOverwritten = "1"</Condition> </Control> <Control Id="Cancel" Type="PushButton" X="304" Y="243" Width="56" Height="17" Cancel="yes" Text="!(loc.WixUICancel)"> <Publish Event="SpawnDialog" Value="CancelDlg">1</Publish> </Control> <Control Id="BannerBitmap" Type="Bitmap" X="0" Y="0" Width="370" Height="44" TabSkip="no" Text="!(loc.LicenseAgreementDlgBannerBitmap)" /> <Control Id="LicenseText" Type="ScrollableText" X="20" Y="60" Width="330" Height="140" Sunken="yes" TabSkip="no"> <!-- This is original line --> <!--<Text SourceFile="!(wix.WixUILicenseRtf=$(var.LicenseRtf))" />--> <!-- To enable EULA localization we change it to this --> <Text SourceFile="$(var.ProjectDir)\!(loc.LicenseRtf)" /> <!-- In each of localization files (wxl) put line like this: <String Id="LicenseRtf" Overridable="yes">\Lang\en-us\EULA_en-us.rtf</String>--> </Control> <Control Id="Print" Type="PushButton" X="112" Y="243" Width="56" Height="17" Text="!(loc.WixUIPrint)"> <Publish Event="DoAction" Value="WixUIPrintEula">1</Publish> </Control> <Control Id="BannerLine" Type="Line" X="0" Y="44" Width="370" Height="0" /> <Control Id="BottomLine" Type="Line" X="0" Y="234" Width="370" Height="0" /> <Control Id="Description" Type="Text" X="25" Y="23" Width="340" Height="15" Transparent="yes" NoPrefix="yes" Text="!(loc.LicenseAgreementDlgDescription)" /> <Control Id="Title" Type="Text" X="15" Y="6" Width="200" Height="15" Transparent="yes" NoPrefix="yes" Text="!(loc.LicenseAgreementDlgTitle)" /> </Dialog> </UI> </Fragment></Wix>   Look at the Control with Id "LicenseText” and read the comments. We’ve changed the original license text source to "$(var.ProjectDir)\!(loc.LicenseRtf)". var.ProjectDir is the directory of the project file. The !(loc.LicenseRtf) is where the magic happens. Scroll up and take a look at the wxl localization file example. We have the LicenseRtf declared there and it’s been made overridable so developers can change it if they want. The value of the LicenseRtf is the path to our localized EULA relative to the WiX project directory. With little hacking we’ve achieved a fully localizable installer package.   The final step is to insert the extended LicenseAgreementDialogOverwritten license dialog into the installer GUI chain. This is how it’s done under the <UI> node of course.   <UI> <!-- code to be discussed in later posts –> <!-- BEGIN UI LOGIC FOR CLEAN INSTALLER --> <Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="LicenseAgreementDialogOverwritten">1</Publish> <Publish Dialog="LicenseAgreementDialogOverwritten" Control="Back" Event="NewDialog" Value="WelcomeDlg">1</Publish> <Publish Dialog="LicenseAgreementDialogOverwritten" Control="Next" Event="NewDialog" Value="ProductKeyCheckDialog">LicenseAcceptedOverwritten = "1" AND NOT OLDER_VERSION_FOUND</Publish> <Publish Dialog="InstallDirDlg" Control="Back" Event="NewDialog" Value="ProductKeyCheckDialog">1</Publish> <!-- END UI LOGIC FOR CLEAN INSTALLER –> <!-- code to be discussed in later posts --></UI> For a thing that should be simple for the end developer to do, localization can be a bit advanced for the novice WiXer. Hope this post makes the journey easier and that next versions of WiX improve this process. WiX 3 tutorial by Mladen Prajdic navigation WiX 3 Tutorial: Solution/Project structure and Dev resources WiX 3 Tutorial: Understanding main wxs and wxi file WiX 3 Tutorial: Generating file/directory fragments with Heat.exe  WiX 3 Tutorial: Custom EULA License and MSI localization WiX 3 Tutorial: Product Key Check custom action WiX 3 Tutorial: Building an updater WiX 3 Tutorial: Icons and installer pictures WiX 3 Tutorial: Creating a Bootstrapper

  Read the article

• How to conditionally exclude features from "FeaturesDlg" in WiX 3.0 from a managed Custom Action (DT

  - by Gerald

  I am trying to put together an installer using WiX 3.0 and I'm unsure about one thing. I would like to use the FeaturesDlg dialog to allow the users to select features to install, but I need to be able to conditionally exclude some features from the list based on some input previously received, preferably from a managed Custom Action. I see that if I set the "Display" attribute of a Feature to "hidden" in the .wxs file that it does what I want, but I can't figure out a way to change that attribute at runtime. Any pointers would be great.

  Read the article

• Problem with WiX Votive 3.0 preprocessor

  - by Leith Bade

  I have just started using WiX for the first time. I added a WiX Votive project to my existing C project. To automatically select the correct source folder for the binaries add used the following: <Directory Id="INSTALLLOCATION" Name="Trapeze Capture For Objective" FileSource="$(var.CaptureForObjective.TargetDir)"> That results in the following error: 1C:\code\CaptureForObjective\Installer\Product.wxs(10,0): error CNDL0150: Undefined preprocessor variable '$(var.CaptureForObjective.TargetDir)'. The C project is called CaptureForObjective, and the WiX project is called Installer. What do I need to do to get this to work?

  Read the article

• Environment variables get lost between MSBuild projects

  - by DotNetter

  Hi, I have a .NET solution containing following projects: web application (WAP) web deployment (WDP, .wdproj) wix setup (WIX, .wixproj) In the WDP I've used a custom MSBuild task (SetEnvVar) to set some env. variables for further use in the build process. After setting them I can use them without prob. in the WDP but in the WIX they are empty/undefined. The strange thing is that when I reference those env. vars in the WIX files (by using properties in .wxs or preproc vars in .wxi) I get the values as expected. Do you have any idea why the env. vars get lost/are undefined in .wixproj? By the way the (solution) build process is triggered from inside VS 2010.

  Read the article

• Problems with WiX and Visual Studio web deployment project

  - by Valeriu

  Hello, I want to create an .MSI package from a web deployment project in Visual Studio 2008. Now we want to use continuous integration and we would need the .MSI package build in the nightly builds. Till now we used standard Visual Studio Web Setup project, but this is not compatible with the MSBuild. So we decided to use WiX. The problem is that I have not found any good tutorial/documentation about this. Is there a way to do a WiX installer package from a web deployment project? If yes, how? Also, I tried to use heat.exe to create the XML for the WiX project .wxs file, but it seems that heat.exe doesn't recognize the web deployment project format. Thank you for your responses. Regards, V.

  Read the article

• How do I execute file installed by merge module?

  - by Juozas Kontvainis

  I am using WIX and have successfully used a custom action to execute installed file at the end of installer like this: <CustomAction Id="LaunchAfterInstall" FileKey="foobar.exe" ExeCommand="parameters" Execute="immediate" Impersonate="yes" Return="asyncNoWait" /> <Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION"/> <UIRef Id="WixUI_InstallDir" /> <Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT" Value="Launch Foobar." /> <UI> <Publish Dialog="ExitDialog" Control="Finish" Order="1" Event="DoAction" Value="LaunchAfterInstall">WIXUI_EXITDIALOGOPTIONALCHECKBOX</Publish> </UI> This works well when foobar.exe is in a component in the same wxs file. However what I really want is to execute a file that is installed by a merge module. How do I do this? I can make changes in the merge module, if this helps things.

  Read the article

• Integer variables at WIX

  - by Hila

  I would like to install a feature according to the brand. So in my brand.wxi I defined: <?define brand.FeatureLevel = 1 ?> And in my wxs I wrote: <Feature Id="FF" Title="FF" Level="$(var.brand.FeatureLevel)"> <ComponentRef Id="..." /> <ComponentRef Id="..." /> </Feature> This definition works fine (wheather I've placed 0 or 1 as FeatureLevel). My only problem is a warning I get at compilation time: The 'Level' attribute is invalid - The value '$(var.brand.FeatureLevel)' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:integer' - The string '$(var.brand.FeatureLevel)' is not a valid Integer value. Is there a way to fix this warning? Can I define integer variable? I couldn't find a way...

  Read the article

• WIX Merge Module : Trying to use $(var.Project.TargetFileName)

  - by Stephen Bailey

  I have created a simple Wix 3 Merge Module in VS 2005 ( .wxs ) <?xml version="1.0" encoding="UTF-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Module Id="TestMergeModule" Language="1033" Version="1.0.0.0"> <Package Id="ef2a568e-a8db-4213-a211-9261c26031aa" Manufacturer="Me" InstallerVersion="200" /> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="MergeRedirectFolder"> <Component Id="Test_ModuleComponent" Guid="{1081C5BC-106E-4b89-B14F-FFA71B0987E1}"> <File Id="Test" Name="$(var.Project.TargetFileName)" Source="$(var.Project.TargetPath)" DiskId="1" /> </Component> </Directory> </Directory> </Module> </Wix> And I have added the project "Project" as a reference to this Merge Module, however I continue to get this error Error 7 Undefined preprocessor variable '$(var.Project.TargetFileName)'. Any suggestions, I am sure I am just missing the obvious here.

  Read the article

• Retrieve COM ProgID from exe without registering it

  - by mangelo

  Background: I would like to extract the COM data from a VB6 application so I can register it correctly (according to Microsoft best practice) the application. I am using WiX 3.0 and heat.exe will not extract the data (known issue with heat) and I do not have ready access to the associated TLB file. The VB6 application does not have compatibility turned on so it regenerates the COM GUIDs every build (They want to have the application be able to run side by side with an older version.) I created a C# application that will collect the TypeLib, interface and CoClass information from the VB6 application without registering it and create a wxs file for candle to use. My company has several other older applications like this and I would like to make it a more generic solution. The Issues: 1.Is there a way to collect the 'true' ProgID (programmer intended one) from the application with out the project or TLB file and without registering it? 2.Is there a way to find out the intended Threading Model from a DLL without registering it? (I intend that it can handle all COM active items, might as well be complete) Thank you.

  Read the article

• SharpDevelop WIX project: MSBuild Configurations

  - by chezy525

  Using SharpDevelop, I wrote a windows service with a WIX setup project to install/auto-start it. For testing purposes, I've done a number of things I don't want to do in the release version (i.e. add an uninstall shortcut to the desktop). So, my question really boils down to this; how do you handle build configurations within a WiX project? I think I've solved most of my problems after I found this question Passing build parameters to .wxs file to dynamicaly build wix installers. And thus far I've done the following: Added a property that checks the Configuration variable <Product> ... <Property Id="DEBUG">$(var.Configuration) == 'Debug'</Property> ... Separated all of the debug files into unique components and setup as a separate feature with a condition checking the DEBUG property. <Product> ... <Feature> ... <Feature Id="DebugFiles" Level="1"> <ComponentRef Id="UninstallShortcutComponent" /> <Condition Level="0">DEBUG</Condition> </Feature> ... Then, finally, pointing to the correct file based on the configuration, using the Configuration variable <Directory> ... <Component> <File Source="..\mainProject\bin\$(var.Configuration)\main.exe" /> </Component> ... So, now my question is simplified to how to handle files that may not exist under certain build configurations (like .pdb files). Using all of the above (including pointing the file source to the ...\bin\Release\*.pdb, which I know isn't expected to exist) I get a LGHT0103 compiler error, it can't find the file.

  Read the article

1 2  | Next Page >