[WiX-users] WiXUI errors
I'm using command line:
c:\work\installlight setup.wixobj -ext WixUIExtension
and i'm getting such an output:
Microsoft (R) Windows Installer Xml Linker version 3.5.1030.0
Copyright (C) Microsoft Corporation. All rights reserved.
c:\work\install\setup.wxs(1571) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFWI_UI' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549EB1}'.
c:\work\install\setup.wxs(1577) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFWIUI_Common' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549E
B1}'.
c:\work\install\setup.wxs(1578) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFUI_ErrorText' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549
EB1}'.
c:\work\install\setup.wxs(1579) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFUI_ProgressText' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC
549EB1}'.
The only advice i've managed to google is to use WiXUIExtension but i'm
already using it. What can I do else?
--
/callvote set1v1 q3tourney2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] _Validation table
Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] wix upgrade issue.
we have upgrade all the visual studio projects to visual studio 2008 But In Build machine we have visual studio 2005 and Wix 3.0.5419(Wix is upgrade from Wix3.0.2925). I have not upgraded Visual studio 2008 in build server. I installed .NET Framework3.5 and compiling all the .net projects. we have wixextension project, and is compiled in Visual studio 2008. This dll is used to compile the wix projects. But when I try to compile the wix projects , It is giving the error as follows. candle.exe : error CNDL0307: Either 'Microsoft.Tools.WindowsInstallerXml.Assemb lyDefaultWixExtensionAttribute' was not defined in the assembly or the type def ined in extension 'C:\C# Source\ProductDeployment.Wix.Extension\bin\Release\ProductDeployment.Wix.Exten sion.dll' could not be loaded. is it because of the dll compiled with .net framework3.5 version ? should I install Visual studio 2008 also in build machine? Please let me know what is the correct solution for it. -- View this message in context: http://n2.nabble.com/wix-upgrade-issue-tp4092985p4092985.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component Keypath Problem
ricky sundrani wrote: I have a component whose purpose is to modify the machine.config file. What it does is add a new line to machine.config using XmlConfig element. But when i clicked on the repair button for repair, the component described above is called again i.e the line which was added to machine.config is added again. So i decided on using a registrykey and registry value as a component keypath that would aid during the repair process.. If your REINSTALLMODE property contains m then all registry values are rewritten and so your component will get installed again. Use VerifyPath in your XmlConfig to prevent double entries. -- sig://boB http://joyofsetup.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with WiX/MSBuild with TargetPath
Fenstad, Darrel B wrote: I have read the closed Tracker Item https://sourceforge.net/tracker/index.php?func=detailaid=2777114group_id=105970atid=642714. It and another page I found on the Web implies that a fix went into WiX 3.0.5322.0 to address this issue. However, I am using WiX 3.0.5419.0 (verified version in 'Add/Remove Programs') and I continue to have troubles solving the issue. The Item 2777114 suggests that one needs to use the new !(TargetPath) syntax to resolve the problem, but that does not evaluate to a path (I just see the string !(TargetPath) in the output). !(TargetPath) is available only in PreBuildEvent and PostBuildEvent. -- sig://boB http://joyofsetup.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug causing ICE 17 failure
Rob Mensching wrote: It has been a long time since we found a dependency between tables that wasn't automatically added by the WiX toolset. Is it possible that a ControlCondition table is required by the ICEs whenever there is a Dialog table... or something screwy like that? Apparently, though it's not documented nor is it a requirement of MSI itself. -- sig://boB http://joyofsetup.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Remove registry entry on install
I need to prevent users from uninstalling my app via the Add/Remove Programs Tool. To do that I need to remove a registry entry (http://support.microsoft.com/kb/314481). I've tried using the following Wix code, but it has no effect: Registry Id=UninstallKey Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] Action=removeKeyOnInstall / InstallExecuteSequence ... RemoveRegistryValues / Is there a more appropriate way to accomplish this? -- View this message in context: http://n2.nabble.com/Remove-registry-entry-on-install-tp4093847p4093847.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component Keypath Problem
Hi Bob, I set the REINSTALLMODE property to 'p' and its working fine now as per my requirements. Thanks. On Tue, Dec 1, 2009 at 5:59 PM, Bob Arnson b...@joyofsetup.com wrote: ricky sundrani wrote: I have a component whose purpose is to modify the machine.config file. What it does is add a new line to machine.config using XmlConfig element. But when i clicked on the repair button for repair, the component described above is called again i.e the line which was added to machine.config is added again. So i decided on using a registrykey and registry value as a component keypath that would aid during the repair process.. If your REINSTALLMODE property contains m then all registry values are rewritten and so your component will get installed again. Use VerifyPath in your XmlConfig to prevent double entries. -- sig://boB http://joyofsetup.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards. Ricky -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] error message for 64 bit installer on 32 bit machine
Hi, When we try to install a 64 bit MSI on a 32 bit machine, the error message is not clear. The error message is: This installation package is not support by this processor type. Can we change this message? Thanks Regards, Srivardhan. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] _Validation table
Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiXUI errors
I don't recognize the SUFWI dialog set and WixUIExtension doesn't either.
The only UI types in WixUIExtension are WixUI_Advanced, WixUI_FeatureTree,
WixUI_InstallDir, WixUI_Minimal, WixUI_Mondo.
-Original Message-
From: pushist1y [mailto:mister.p...@gmail.com]
Sent: Tuesday, December 01, 2009 12:52 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiXUI errors
I'm using command line:
c:\work\installlight setup.wixobj -ext WixUIExtension
and i'm getting such an output:
Microsoft (R) Windows Installer Xml Linker version 3.5.1030.0
Copyright (C) Microsoft Corporation. All rights reserved.
c:\work\install\setup.wxs(1571) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFWI_UI' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549EB1}'.
c:\work\install\setup.wxs(1577) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFWIUI_Common' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549E
B1}'.
c:\work\install\setup.wxs(1578) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFUI_ErrorText' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC549
EB1}'.
c:\work\install\setup.wxs(1579) : error LGHT0094 : Unresolved reference to
symbo
l 'WixUI:SUFUI_ProgressText' in section
'Product:{503B2C46-49ED-4DB1-BA1A-D701EC
549EB1}'.
The only advice i've managed to google is to use WiXUIExtension but i'm
already using it. What can I do else?
--
/callvote set1v1 q3tourney2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] website being removed after upgrade
As a general rule, if the component is simply an upgraded version of its
previous self and could assume the same identity, it's guid should stay the
same. So, no, don't change the guids.
One possibility would be to create an HKLM registry value as the keypath of
the IIS components (a different value for each). That way, the component
isn't ever removed until you remove the last instance of the product (after
this new release).
-Original Message-
From: Scharp, Craig [mailto:craig.sch...@fuelquest.com]
Sent: Tuesday, December 01, 2009 7:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] website being removed after upgrade
Hi Blair,
Thanks for the response. Guids are the same, but the directory is
definitely different since that's the main purpose of the upgrade (to
replace the website content). Should the guids change for all
components on a major upgrade? Also, what I want to do is replace the
website content, but leave IIS alone. If the IIS: website is inside a
component, will that always be replaced on an upgrade?
Also, after testing more, I am able to recreate this in iis 7. So, now
the site is getting blown away in both environments (IIS 6 and IIS 7).
The original issue was that I was losing the application pool after
upgrade, but only in iis 6. It appears that after trying to resolve
that issue, I have mucked something up where my site is getting removed
in both environments. I will go back to where I was when it was only
losing the app pool in iis 6.
Thanks again for your time and suggestions, I definitely appreciate it!
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, November 30, 2009 10:56 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] website being removed after upgrade
Did either component's guid change between the two versions?
Are the directories the two components live in identical between the two
versions?
-Original Message-
From: Scharp, Craig [mailto:craig.sch...@fuelquest.com]
Sent: Monday, November 30, 2009 9:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] website being removed after upgrade
Hi all,
Has anyone run into the issue where website is being removed after a
major upgrade on Windows Server 2003 (IIS 6)? This does not happen on
server 2008 (IIS 7). My original install creates a database and
website. Now, I'm trying to perform upgrades in IIS 6, after the
upgrade the website is blown away.
To resolve it, I have to change UpgradeVersion to not remove previous
product. Doing this allows the upgrade to work properly fine, but
leaves the older version in add/remove programs. I would prefer to
replace the older version if possible. I'm using wix version
3.0.5217.0. I have tried using the SkipIISCA custom action, but no
luck.
Thanks in advance for any ideas or solutions!
Here's some sample code from the wix file:
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion Minimum=$(var.ProductVersion)
IncludeMinimum=yes Maximum=$(var.ProductVersion)
IncludeMaximum=yes Language=1033 Property=SELFFOUND
OnlyDetect=yes /
UpgradeVersion Minimum=$(var.RTMProductVersion)
IncludeMinimum=yes Maximum=$(var.ProductVersion) IncludeMaximum=no
Language=1033 Property=PREVIOUSFOUND /
/Upgrade
InstallExecuteSequence
!-- Custom Action=SkipIISCA
After=CostFinalize![CDATA[WebsiteFeature 3 AND Not
Installed]]/Custom --
!-- Custom Action=SkipIISCA
After=CostFinalize1/Custom --
Custom Action=VerifyPreviousVersion
After=FindRelatedProductsNOT PREVIOUSFOUND/Custom
Custom Action=PreventDowngrading
After=FindRelatedProductsSELFFOUND/Custom
/InstallExecuteSequence
Component Id=NewWebsiteConfigASP Guid={MYGUID}
iis:WebSite Id=IISWebsite Description=[WEBSITEDESCRIPTION]
Directory=TARGETDIR AutoStart=yes ConfigureIfExists=yes
StartOnInstall=yes
iis:WebAddress Id=IISWebAddress Port=[WEBSITEPORT]
IP=[WEBSITEIP] Header=[WEBSITEHOSTHEADER] /
iis:WebDirProperties Id=IISWebDirProperties Execute=yes
Read=yes
DefaultDocuments=default.aspx,index.aspx,index.htm,index.html,default.h
tm,default.html /
iis:WebDir Id=IISAppDataWebDir Path=App_Data
iis:WebDirProperties Id=IISAppDataWebDirProperties
Write=yes Read=yes
DefaultDocuments=default.aspx,index.aspx,index.htm,index.html,default.h
tm,default.html /
/iis:WebDir
iis:WebApplication Id=WebApplication
Name=[WEBAPPLICATIONNAME] WebAppPool=WebAppPool
/iis:WebApplication
/iis:WebSite
iis:WebAppPool Id=WebAppPool Name=[WEBAPPLICATIONPOOLNAME]
Identity=networkService /
ConditionTARGETMODE = NewWebsite AND SCRIPTLANGUAGE =
ASP/Condition
/Component
Component Id=ExistingWebsiteConfigASP Guid={MYGUID}
iis:WebSite Id=IISWebsiteExisting
[WiX-users] setupbld diagnosing?
My WiX project has a handful of prerequisites, for example, the application requires .NET 3.5 SP1. My WiX project correctly does not run unless SP1 is installed. I understand that this needs to be done in a bootstrapper. However, after a couple of hours of reading on the Internet and experimenting, I'm feeling like I'm not getting anywhere. So... I tried something simple, to use setupbld to wrap a test MSI. When I run the created setup.exe either from the command line or by double-clicking on it, nothing seems to happen. Is there debugging information for the created setup.exe? Here's the command line that I use to build: PS O:\projects\TestInstall\bin\Debug setupbld -o setup.exe -msu TestInstall.msi -title Test Setup.exe -setup C:\Program Files\Windows Installer XML v3\bin\setup.exe This is what I see when I run: PS O:\projects\TestInstall\bin\Debug .\setup.exe PS O:\projects\TestInstall\bin\Debug In other words, I immediately get back the command prompt. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Pyro error
If the warning is not causing any issues I think we can ignore that. We can take care of this in the SP1 release. No I did not. DO you want me to try it with the option? Ok let me know if you need any information. Thanks Anurag -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, November 30, 2009 11:45 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error Regarding the warning: since you released, you are stuck with the warning unless you are willing to change both filenames and the component guid (along with any registry paths you declare in that same component). Regarding the error: you don't happen to have -wx in your pyro commandline, do you? I'll try to reproduce your error here, but it may be later in the week (or even next week) before I can get to it. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Monday, November 30, 2009 7:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Pyro error No we don't explicitly designate the file and the first file is the FSCREG.cfg file. We did release the MSI. I did try that as well and still getting the error. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, November 24, 2009 11:18 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error Regarding the warning: in your AdminInstall_Component component, do you explicitly designate which file is the keypath? If you don't, the first one listed often becomes the keypath. If you have already released your MSI, you might be too late to easily fix this, however. Regarding the error: to know definitively if the anti-virus is to blame, try turning off the real-time scanning right before you start your build (make sure to turn it back on right after the build finishes). If that doesn't clear the error, I'll help you keep digging. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Tuesday, November 24, 2009 9:00 AM To: Anurag Pahwa; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Pyro error Tried the WIX_TEMP and still getting the same error. pyro.exe : warning PYRO1097 : File 'FSSAClient.exe' in Component 'AdminInstall_Component' was changed, but the KeyPath file 'FSCReg.cfg' was not. This file will not be pa tched on the target system if the REINSTALLMODE does not contain 'A'. The KeyPath file should also be changed and included in your patch. C:\wix\temp\tyqlnkaz\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\wix\temp\tyqlnkaz\Patch.msp'. Any ideas. -Original Message- From: Anurag Pahwa Sent: Tuesday, November 24, 2009 9:25 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Pyro error I'll try that. I think problem might be the FSCReg.cfg file is a non versioned file whereas the FSSACLient.exe is a versioned file. Isn't it weird that it expects the FSCReg.cfg to be changed when we change the fssaclient.exe file? I'm not removing anything from the patch. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, November 24, 2009 2:20 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error The error may possibly be caused by anti-virus software running on your build box. Or, it might be related to the earlier warnings (I couldn't tell). Try using the WIX_TEMP environment variable to move the temp folder used and suppress that folder (the one you specify in your WIX_TEMP value) in your anti-virus. What are the changes in the AdminInstall_Component between the two builds? You shouldn't normally be adding/removing/renaming files in a minor upgrade/small update (which working patches are) inside of a component. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Monday, November 23, 2009 7:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Pyro error Hi Guys, I'm getting these pyro warnings and then the error. Any ideas? pyro.exe : warning PYRO1097 : File 'FSSAClient.exe' in Component 'AdminInstall_Component' was changed, but the KeyPath file 'FSCReg.cfg' was not. This file will not be pa tched on the target system if the REINSTALLMODE does not contain 'A'. The KeyPath file should also be changed and included in your patch. C:\Documents and Settings\a-anup\Local Settings\Temp\zbp-1f6q\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\Documents and Settings\a-anup\Local Setting s\Temp\zbp-1f6q\Patch.msp'. Thanks Anurg -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.
Re: [WiX-users] setupbld diagnosing?
John L Krupka wrote: You should be able to set up preconditions on those things in the msi. Setupbld is not the place for that to the best of my knowledge. This is where my lack of understanding how MSIs work raises its head. My MSI has a condition where it needs .NET 3.5 SP1, and refuses to run if it is not installed. I need trigger the .NET setup in that case. There are also a couple of other installs that need to be run before mine. I'm under the impression that I need a bootstrapper for these things, but don't fully understand how these things work yet. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
