Search Results

Search found 320 results on 13 pages for 'wix'.

Page 1/13 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• I'm referencing an WiX extension in a WiX library project -- how do I avoid having to reference this

  - by arathorn

  I'm referencing a WiX extension in a WiX library project. This WiX library project is itself referenced by my main WiX MSI project. Why does the main project have to also reference the WiX extension, even though it doesn't directly need it? I'd like to keep my wixlib's as self-contained as possible, so that other projects that use them don't need to know about their inner workings. I'm using latest stable release of WiX (3.0.x).

  Read the article

• Building a database installer with WiX, datadude and Visual Studio 2010

  - by jamiet

  Today I have been using Windows Installer XML (WiX) to build an installer (.msi file) that would install a SQL Server database on a server of my choosing; the source code for that database lives in datadude (a tool which you may know by one of quite a few other names). The basis for this work was a most excellent blog post by Duke Kamstra entitled Implementing a WIX installer that calls the GDR version of VSDBCMD.EXE which coves the delicate intricacies of doing this – particularly how to call Vsdbcmd.exe in a CustomAction. Unfortunately there are a couple of things wrong with Duke’s post: Searching for “datadude wix” didn’t turn it up in the first page of search results and hence it took me a long time to find it. And I knew that it existed. If someone else were after a post on using WiX with datadude its likely that they would never have come across Duke’s post and that would be a great shame because its the definitive post on the matter. It was written in October 2009 and had not been updated for Visual Studio 2010. Well, this blog post is an attempt to solve those problems. Hopefully I’ve solved the first one just by following a few of my blogging SEO tips while writing this blog post, in the rest of it I will explain how I took Duke’s code and updated it to work in Visual Studio 2010. If you need to build a database installer using WiX, datadude and Visual Studio 2010 then you still need to follow Duke’s blog post so go and do that now. Below are the amendments that I made that enabled the project to get built in Visual Studio 2010: In VS2010 datadude’s output files have changed from being called Database.<suffix> to <ProjectName>_Database.<suffix>. Duke’s code was referencing the old file name formats. Duke used $(var.SolutionDir) and relative paths to point to datadude artefacts I have replaced these with Votive Project References http://wix.sourceforge.net/manual-wix3/votive_project_references.htm I commented out all references to MicrosoftSqlTypesDbschema in DatabaseArtifacts.wxi. I don't think this is produced in VS2010 (I may be wrong about that but it wasn't in the output from my project) Similarly I commented out component MicrosoftSqlTypesDbschema in VsdbcmdArtifacts.wxi. It wasn't where Duke's code said it should have been so am assuming/hoping it isn't needed. Duke's ?define block to work out appropriate SrcArchPath actually wasn't working for me (i.e. <?if $(var.Platform)=x64 ?> was evaluating to false)  so I just took out the conditional stuff and declared the path explicitly to the “Program Files (x86)” path. The old code is still there though if you need to put it back. None of the <RegistrySearch> stuff is needed for VS2010 - so I commented it all out! Changed to use /manifest option rather than /model option on vsdbcmd.exe command-line. Personal preference is all! Added a new component in order to bundle along the vsdbcmd.exe.config file Made the install of the Custom Action dependent on the relevant feature being selected for install. This one is actually really important – deselecting the database feature for installation does not, by default, stop the CustomAction from executing and so would cause an error - so that scenario needs to be catered for I have made my amended solution available for download at: http://cid-550f681dad532637.office.live.com/self.aspx/Public/BlogShare/20110210/InstallMyDatabase.zip It contains two projects: the WiX project and the datadude project that is the source to be deployed (for demo purposes it only contains one table). I have also made the .msi available although in order that it gets through file blockers I changed the name from InstallMyDatabase.msi to InstallMyDatabase.ms_ – simply rename the file back once you have downloaded it from: http://cid-550f681dad532637.office.live.com/self.aspx/Public/BlogShare/20110210/InstallMyDatabase.ms%5E_ .You can try it out for yourself – the only thing it does is dump the files into %Program Files%\MyDatabase and uses them to install a database onto a server of your choosing with a name of your choosing - no damaging side-affects. I will caveat this by saying “it works on my machine” and, not having access to a plethora of different machines, I haven’t tested it anywhere else. One potential issue that I know of is that Vsdbcmd.exe has a dependency on SQL Server CE although if you have SQL Server tools or Visual Studio installed you should be fine. Unfortunately its not possible to bundle along the SQL Server CE installer in the .msi because Windows will not allow you to call one installer from inside another – the recommended way to get around this problem is to build a bootstrapper to bundle the whole lot together but doing that is outside the scope of this blog post. If you discover any other issues then please let me know. Here are the screenshots from the installer: And once installed…. Hope this is useful! @jamiet 

  Read the article

• building wix managed Custom Actions in .net 4.0

  - by ashish.s

  We just recently upgraded all our code base to .net 4.0, and are trying to build custom actions in our installer using .net 4.0. We are using wix 3.5 to do that, I am getting BadImageException, saying its built using a newer version of .net runtime than currently loaded. does wix 3.5's makesxca utility support .net 4.0 ?

  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

• 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

• Wix XmlFile is keeping SqlDatabase from creating databases

  - by Grandpappy

  I've got a Wix project made up of several fragments. One of those fragments has the database components, another has a component that manipulates xml files. When I include the XmlFile element to manipulate a file, the databases defined by the SqlDatabase do not get created. If I comment out the XmlFile, then the databases do get created. Here are the two wix files with fragments that are being used: Database: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension"> <Fragment> <DirectoryRef Id="TARGETDIR"> <Component Id="Database1Creation" Guid="GUID_HERE"> <sql:SqlDatabase Id="Database1" Server="[DATABASE_SERVER]" Database="[DATABASE_NAME]" CreateOnInstall="yes" ConfirmOverwrite="no" DropOnUninstall="yes"> </sql:SqlDatabase> </Component> </DirectoryRef> </Fragment> </Wix> Xml Manipulation: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"> <Fragment> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLDIR" Name="MyDirectory"> <Component Id="ServiceExecutables" Guid="GUID_HERE"> <File Id="File1" Name="File1.xml" Source="Source/File1.xml" /> <util:XmlFile Id="UpdateFile1" File="[INSTALLDIR]File1.xml" Action="setValue" ElementPath="//SomeContainer/SomeElement" Value="[SOME_VALUE]" /> </Component> </Directory> </Directory> </Directory> </Fragment> </Wix> There are other things that are also installed, but they don't appear to have any influence on the issue (I've removed everything else and tested the install). When looking at the install logs when using XmlFile and when not, they are almost exact copies of each other, except that the SqlDatabase calls would be completely missing, and the XmlFile calls would be in their place. Is there a known bug here? Or am I doing something I shouldn't be? This isn't a killer for our app, since I can move the things I'm putting in the xml file into the registry, but I'd rather not do that. I am using Wix 3.5.

  Read the article

• How to add a whole directory or project output to WiX package

  - by Coincoin

  We decided to switch from VS integrated setup to WiX. However, what we currently do is use projects output files as the input for the setup project. This lets us easily add Application Files to a directory (for images, samples, and other resources...) and those files are automatically added to the setup when we build. I could not find any similar feature in WiX. WiX seems to require one Directory entry and one File entry for each and every directory and file. This would require us to change the WiX source everytime a file is added which, to my eyes, is prohibitive since we have so many of them. Is there any integrated way of doing that with WiX or do I have to write my own task that will create a WiX source before calling candle?

  Read the article

• WIX 3.5 Unexpected Child Element iis:Certificate

  - by Wil Peck

  Came across this today when I switched from WIX 3.0 and VS 2008 to WIX 3.5 and VS 2010.  The solution ended up being pretty simple.  Just need to update the Wix Project Properties to provide an additional parameter to the compiler and linker. These can be found at Wix Installer Project Properties > Tool Settings > Additional Parameters Compiler and Wix Installer Project Properties > Tool Settings > Additional Parameters Linker.  Just make sure to add ‘-ext WixIIsExtension’ in the fields and recompile.   Technorati Tags: WIX,WIX 3.5,Help

  Read the article

• WiX tricks and best practices

  - by Si

  We've been using WiX 3 for a while now, and despite the usual gripes about ease of use, it's going reasonably well. What I'm looking for is useful advice regarding: Setting up a WiX project (layout, references, file patterns) Integrating WiX into solutions, and build/release processes Configuring installers for new installations and upgrades Also interested in any good WiX hacks you'd like to share, thanks!

  Read the article

• WiX tricks and tips

  - by Si

  We've been using WiX 3 for a while now, and despite the usual gripes about ease of use, it's going reasonably well. What I'm looking for is useful advice regarding: Setting up a WiX project (layout, references, file patterns) Integrating WiX into solutions, and build/release processes Configuring installers for new installations and upgrades Also interested in any good WiX hacks you'd like to share, thanks!

  Read the article

• Can I set IP restrictions using the Wix IIS extension?

  - by evilfred

  Hi, Is it possible to set-up IP address restrictions for an IIS site through a Wix installer? I don't see it mentioned in the IIS extension documentation. I want the site to be available to only one specific IP address. Thanks!

  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 HeatDirectory Task - Setting the preprocessorVariable

  - by Stuart

  I'm trying to set the preprocessor variable in wix and i'm unable to find an example of this or explanation on how to do it anywhere on the internet, i'm hoping somebody here can explain or show me where im going wrong! I have tried the example shown here regarding setting var values http://www.ageektrapped.com/blog/setting-properties-for-wix-in-msbuild/ The documentation for using the HeatDirectory taks in wix can be found here and is not very useful at all! How do i set the preprocessorVariable to substitute the SourceDir for another variable name?

  Read the article

• InstallShield to WIX

  - by diddams

  I have an .msi that was created using InstallShield 2008. and now I need to use WIX to create a patch. Is this possible using Wix directly or do I need to convery my installshield .ism source to a Wix project

  Read the article

• Create a Desktop Shortcut to an existing FOLDER using WiX

  - by Sach

  I have the need to create a Desktop Shortcut to an existing FOLDER (NOT to a file) using Wix. To elaborate more, my installer program has a CustomAction program written using C# associated with it. This CustomAction program creates a folder named "BSS" of which the path is selected by user. C:\ProgramData\MT\BSS Now I need to place a Desktop Shortcut to this folder using WiX. However, I encounter a problem since this folder does not have a folder structure within WiX. The closest code I could find was the following. <Directory Id="DesktopFolder" Name="Desktop"/> <Directory Id="CommonAppDataFolder" Name="ProgramDataFolder"/> <Component Id="ComponentBSStrageShortcut" Guid="{8436995c-2e76-4030-b92d-c6b4bc243c43}"> <Shortcut Id="ShortcutBSStrageShortcut" Directory="DesktopFolder" WorkingDirectory="APPLICATIONFOLDER" Target="[CommonAppDataFolder]/MTK/BSStrage" Name="BSStrage" Show="normal"/> <RegistryValue Action="write" Key="SOFTWARE/MTK/BackStreet" Root="HKCU" Type="string" KeyPath="yes" Value="ApplicationFolderName"/> </Component> When I build the installer this way, it actually creates a shortcut on Desktop. However, WiX seems to think that BSStrage is a file/application so it places a shortcut to an imaginary application called BSStrage in the location C:\ProgramData\MT. But double clicking on it dosen't help as there is no program that can be used to open it. Obviously I'm doing it wrong here. Can someone please help me with this, so as how to overcome this problem. Note that I'm extremely new to Wix (it's been only two days) and has never worked with it before. Any code sample would be of great help.

  Read the article

• GUI for Dialog-design for WiX

  - by leiflundgren

  WiX is great in that there is no GUI, you just write the installer you want it to be. No fiddling with GUI-wizards! However, drawing GUI is actually one thing I prefer to use a GUI for. So, is there any Dialog-drawing program which exports WiX-data? (I suppose else-wise perhaps I could transform what Visual Studio's forms editor does to WiX-XML.) /L

  Read the article

• 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 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

• Change Wix Merge Module Package GUID?

  - by jenglert

  When is it necessary to change the package GUID of a merge module? <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Module Id="MyMergeModule" Language="1003" Version="1.0.0.0"> <Package Id="SOME_GUID" Manufacturer="Me" InstallerVersion="301" /> </Module> </Wix> Wix3 requires that the package GUID is explicitly specified for a merge module unlike for a product. My merge module will be used with an MSI that is built bi-weekly. These bi-weekly MSIs need to co-exist on the same machine as separate installations (e.g. versions 1, 2, 3, etc...) Do I need to change the package GUID of my merge module for each bi-weekly MSI build?

  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

• 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 to create Custom action project with WIX 2.0

  - by Venkat

  Hi, I have installed WIX 2.0 (and Votive). I need to create user defined custom actions using the Custom action project. I found the custom action project template in VS2008 when WIX 3.0 is installed. Now, i couldnt find any template in VS2005 with WIX 2.0. Can anyone plz let me know how can i create a custom action project( class with some custom action)..like this [CustomAction] public static ActionResult InstallItem1(Session session) I think Microsoft.WindowsInstaller and Microsoft.Deployment.WindowsInstaller are the references required (not sure) to create such methods but i couldnt find them in my machine.

  Read the article

• Self updating application install with WIX?

  - by Brian ONeil

  I am writing an application that needs to be installed on a large number of desktops and also needs to update itself. We are looking at WIX for creating the installation. I have used ClickOnce and it is not a good solution for this install. WIX seems to fit, but there is no good process for auto update that I have found. I have looked at ClickThrough, but it doesn't seem ready for prime time yet. Does anyone have another good solution to use with WIX (or maybe another install program) to auto update an application install?

  Read the article

• Making Wix uninstall an old plug-in when performing an upgrade

  - by IanM

  I have a main product which is installed using Wix and has its own UpgradeCode In between releases of the main product we sometimes release plug-ins which add or patch some functionality. The plug-ins are packaged in their own Wix generated .msi files with their own UpgradeCodes and generally install addition files is a separate folder from the main product. I want to create a new version of the main product which includes the functionality which was previously available in a plug-in. A user upgrading to the new version will no longer need the plug-in so it would be nice to uninstall it as part of the upgrade. Is there a way of making Wix uninstall a product with UpgradeCode2 when it is upgrading product with UpgradeCode1?

  Read the article

• vb.net auto detect dependency files for wix 3.7

  - by Khan

  I am in the process of learning WIX all thanks to MS for removing such a nice tool (vdproj) from the latest versions of visual studio. I have come to know that I can add my files (and dlls) to distribute in WIX using that tag. It is OK. But in vdproj it was very easy to add all files. I just need to right click in file view, and select 'add project output'. This was enough to add dozen of files that were required for my application. In visual studio 2012, and using WIX 3.7, what options do I have to automatically list all those dlls that are required by my application?

  Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >