[WiX-users] Major Upgrade: some files are randomly not installed

[little.forest]

Hi All,

I run into a stange problem. Forgive me if this question is a bit of long. I try to make it shorter.
I need your hlep.

We're using WiX version 3.0.4805.0.

The problem is:
---------------
I have 3 builds. They have exactly the same feature set. They are just built at different time. So we can say they are almost identical. I ALWAYS use "Major Upgrade". That means every time the new build will uninstall the previous build first and then install the new one. Of course, the build server updates the package code, product code, and the product version before making the build. All of these 3 builds have the same upgrade code. I thought these 3 builds can be used to upgrade each other. Namely, any build can upgrade another build without problem. But I found this is not true. Some times, when upgrading from a build to another, some files are not installed during upgrading. Then it caused the application crash. So this is very serious for us..

My question is:
---------------
does anyone get the similar issue? Is this a known issue? Or even a bug in major upgrade(this is the last thing I'd like to say)? Please help.

I'd like to clarify something here:
-----------------------------------
1. By installing each build alone without having any "previous" build, the installation is fine. All files are installed properly.
2. I'm sure "Major Upgrade" works. Because I keep the same UpgradeCode among these builds. Of course, I change package code, product code and product version each time before making a build. During upgrading, I can even visually see the previous build folder is removed prior the current build installation.
3. During upgrading, sometimes 1 file is missing; sometimes, 3 files are missing.
4. It always happens to one particular file or three files, but not other files. All of these 3 files have their own distinct GUID. And no, these GUIDs are never used by any other files or component.
5. I checked the log file, for successful upgrading, there are some log like this(for failed upgrading, these records can't be found in log file):
MSI (s) (C4:54) [17:29:02:497]: Executing op: FileCopy(SourceName=nvhelxcr.dll|Win32Interop.dll,SourceCabKey=Win32Interop.dll,DestName=Win32Interop.dll,Attributes=1536,FileSize=10752,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=1.0.3399.27010,Language=0,InstallMode=58982400,,,,,,,)
MSI (s) (C4:54) [17:29:02:497]: File: C:\Program Files\MyCompany\MyApp\Win32Interop.dll;To be installed;Won't patch;No existing file
MSI (s) (C4:54) [17:29:02:497]: Source for file 'Win32Interop.dll' is compressed
InstallFiles: File: Win32Interop.dll, Directory: C:\Program Files\MyCompany\MyApp\, Size: 10752
MSI (s) (C4:54) [17:29:02:497]: Note: 1: 2318 2: C:\Program Files\MyCompany\MyApp\Win32Interop.dll
MSI (s) (C4:54) [17:29:02:497]: Note: 1: 2360
6. I didn't really change anything when building these builds. They were just built at different time.

To make more testing, I made 5 builds.
Here are their versions and testing results:
--------------------------------------------
4.0.59, 4.0.64, 4.0.65, 4.0.77, and 4.0.78

4.0 is the version, 59, 64 etc. is the build stamp.

I then made the testing. I tried 20 upgrade installation among these 5 builds.
Here are the results I got(I also attach a screen shot of this testing matrix, not sure if you can see it or not. But it should be the same as this table below):

| 59 | 64 | 65 | 77 | 78
---------------------------------------
59 | - | OK | OK | OK | OK
---------------------------------------
64 | KO-E2| - | KO-E2| OK | OK
---------------------------------------
65 | KO-E2| OK | - | OK | OK
---------------------------------------
77 | KO-E1| KO-E1| OK | - | OK
---------------------------------------
78 | KO-E1| OK | KO-E1| KO-E1| -
---------------------------------------

The build stamp listed in the first row and column.

Here is how to read this matrix:
--------------------------------
1. For each unit, read the row first and then column. For example, the unit in the 2nd row and 4th column is read as "59->65". It means we need to install build 59 first and then build 65. So this upgrade(from 65 to 59) is OK.
2. "-" means there is no upgrade
3. "OK" means the upgrade is good. A good installation should install 37 files.
4. "KO-E1" means upgrade is NOT OK, Error Case 1: it only installs 34 files, missing 3 files such as Win32Interop.dll etc.
5. "KO-E2" means upgrade is NOT OK, Error Case 2: it only installs 36 files, missing Win32Interop.dll.

This problem is really annoying. I tried my best to think about the whole thing, but I couldn't figure it out. I hope that is my problem. But, really, I went through my code again, there is nothing special about these files. As what you can see, the build 78 can be installed on top of 77, but not vice versa. It doesn't make sense.
This problem might have happened before in our builds. But no one may have paid any attention on it until today.

I really appreciate if any one can give me some clue.

Many thanks in advance.
/Brian


__________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

[little.forest]

Sorry, I forgot to attach the screen shot of the testing matrix.
Here it is in the attachment. Hopefully you can see it.

Thanks you all.
/Brian



__________________________________________________________________
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

[little.forest]

I'd like to post my code in the Upgrade part. This is our "Major Upgrade" code:
        <Upgrade Id='$(var.UpgradeCode)'>
            <UpgradeVersion Property="OLDAPPFOUND"
                            OnlyDetect='no'
                            Minimum="0.0.0"
                            IncludeMinimum="yes"
                            Maximum="99.99.32767"
                            IncludeMaximum="no"
                            />
        </Upgrade>
        <InstallExecuteSequence>
            <RemoveExistingProducts After='InstallValidate' />
        </InstallExecuteSequence>

 
Basically:
1. We need "Major Upgrade" because some times we may include one dll is the build, but decide remove it in the later build. So we'd like to make a clean installation for each installation.
2. We need the "Downgrade" working because some times we may put an "older but working" build in our provisioning server to urge the user to "Downgrade" the "current but not working" build. So we don't need to prevent "Downgrade".
 
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.
 
Thanks!
/Brian


__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Jeff Reed]

Post by little.forest
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.

Perhaps you could try isolating the problem, by taking each version of the product that you've released so far and installing, then uninstalling on a "clean" machine? I like to use virtual machines so that when I shut down, I can throw the state away. Maybe you'll find some orphaned files in certain versions, and that would explain the behavior you're experiencing?

I'm fairly new to WiX, but if I was in your shoes, that is one technique I would try.

-Jeff

[little.forest]

Thanks Jeff.

Actually, I did that in VMWare. But the result was the same - major upgrade was broken.

I then narrowed it down: it seems it only happens to 3 files. So I thought why these 3 files? I then remove them from the package and rebuilt them. This time it seems working. By saying "seems", I mean I'm not 100% sure. But at least that 2 new made builds can upgrade themselves each other. I then thought, hmm, if I re-added them in, things maybe fixed? So I re-added these 3 files in, of course, I changed their GUID and their Component ID. But you know what? It stopped working again. This drives me nuts.

I then used Orca to open these msi file to look into the problematic files. I found their file versions are different among the builds. I then thought it might be something about the file version.

I contine to search the post in this community and found this:
http://n2.nabble.com/Overide-a-file-version-to-force-upgrade-td699008.html#a699008

Mike Dimmick -2 said:
I believe InstallShield lies in the Version column of the File table if this option is set (setting it to something huge like 65535.65535.65535.65535, which is the maximum supported value). I don’t think this is a particularly good idea, however. You can’t do it with WiX – the linker takes the information directly from thefile’s resources.

I'm glad to find out this "dirty fact". But it's sad to learn that WiX doesn't support it.

I've a question to MSI. For "Major Upgrade", if the current build is uninstalled entirely before the new build installing, why bother to "compare" the file version anyways? Should the new file be installed anyways without caring about the file version in the "Major Upgrae" case?

Well, I know I probably shouldn't ask this in here. And I know MSI team might even have a reasonable explanation. But the problem is, I do major upgrade, old files gone, new files not installed - I got a broken installation. The whole thing is just because file version. And there is no way to ignore the file version checking in Major Upgrade case.

Anyways, I'll make sure all of my file versions are the same to avoid this problem.

Thanks.

have a nice day,
/Brian


________________________________
From: Jeff Reed <***@duckcreektech.com>
To: General discussion for Windows Installer XML toolset. <wix-***@lists.sourceforge.net>
Sent: Friday, April 24, 2009 5:25:34 PM
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Post by little.forest
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.

Perhaps you could try isolating the problem, by taking each version of the product that you've released so far and installing, then uninstalling on a "clean" machine?  I like to use virtual machines so that when I shut down, I can throw the state away.  Maybe you'll find some orphaned files in certain versions, and that would explain the behavior you're experiencing?

I'm fairly new to WiX, but if I was in your shoes, that is one technique I would try.

-Jeff

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Wilson, Phil]

Going back to the big picture here, if you have your RemoveExistingProducts towards the end of the upgrade then the upgrade will use file update rules to decide what to replace. The upgrade is on top of the existing files, so you need to increment file versions to get files updated.
If you want your upgrade to always remove the old files then sequence RemoveExistingProducts early, such as immediately after InstallInitialize.

Version lying is not a good idea, so WiX perhaps decided not to provide it. The issue is that the version of the file on disk will never match the version in the actual file, so the install is broken, and I don't believe you can predict what things like a repair will do in every situation.

Phil Wilson

-----Original Message-----
From: little.forest [mailto:***@ymail.com]
Sent: Monday, April 27, 2009 5:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Thanks Jeff.

Actually, I did that in VMWare. But the result was the same - major upgrade was broken.

I then narrowed it down: it seems it only happens to 3 files. So I thought why these 3 files? I then remove them from the package and rebuilt them. This time it seems working. By saying "seems", I mean I'm not 100% sure. But at least that 2 new made builds can upgrade themselves each other. I then thought, hmm, if I re-added them in, things maybe fixed? So I re-added these 3 files in, of course, I changed their GUID and their Component ID. But you know what? It stopped working again. This drives me nuts.

I then used Orca to open these msi file to look into the problematic files. I found their file versions are different among the builds. I then thought it might be something about the file version.

I contine to search the post in this community and found this:
http://n2.nabble.com/Overide-a-file-version-to-force-upgrade-td699008.html#a699008

Mike Dimmick -2 said:
I believe InstallShield lies in the Version column of the File table if this option is set (setting it to something huge like 65535.65535.65535.65535, which is the maximum supported value). I don’t think this is a particularly good idea, however. You can’t do it with WiX – the linker takes the information directly from thefile’s resources.

I'm glad to find out this "dirty fact". But it's sad to learn that WiX doesn't support it.

I've a question to MSI. For "Major Upgrade", if the current build is uninstalled entirely before the new build installing, why bother to "compare" the file version anyways? Should the new file be installed anyways without caring about the file version in the "Major Upgrae" case?

Well, I know I probably shouldn't ask this in here. And I know MSI team might even have a reasonable explanation. But the problem is, I do major upgrade, old files gone, new files not installed - I got a broken installation. The whole thing is just because file version. And there is no way to ignore the file version checking in Major Upgrade case.

Anyways, I'll make sure all of my file versions are the same to avoid this problem.

Thanks.

have a nice day,
/Brian


________________________________
From: Jeff Reed <***@duckcreektech.com>
To: General discussion for Windows Installer XML toolset. <wix-***@lists.sourceforge.net>
Sent: Friday, April 24, 2009 5:25:34 PM
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Post by little.forest
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.

Perhaps you could try isolating the problem, by taking each version of the product that you've released so far and installing, then uninstalling on a "clean" machine?  I like to use virtual machines so that when I shut down, I can throw the state away.  Maybe you'll find some orphaned files in certain versions, and that would explain the behavior you're experiencing?

I'm fairly new to WiX, but if I was in your shoes, that is one technique I would try.

-Jeff

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https

[little.forest]

Hi Phil,

Thank you for your reply.

I did try "RemoveExistingProducts after InstallInitialize". It didn't work. I mean, old product was removed, but some files were not installed - because of version things.

What we need is really simple - we just need the "down-grade" working. We surely would like to increase the file version number for each release as long as down-grade working. The reason for that is, as what I posted in previous thread:
some times we may put an "older but working" build in our provisioning server to urge the user to "Downgrade" the "current but not working" build.
 
All we need is, this "down-grade" happens silently without any user involvement.

The problem now is, say, we have two builds: Build1 and Build2.

[Wilson, Phil]

Assuming I understand what you're trying to do with the downgrade, sequencing RemoveExistingProducts early in one of the documented places (such as after InstallInitialize and before any script actions) will accomplish a downgrade. That sequencing results in an uninstall of the existing product followed by an install of the incoming product. This will downgrade if your Upgrade table allows it. If you have files that are shared with other products they won't be uninstalled however.

Phil Wilson

-----Original Message-----
From: little.forest [mailto:***@ymail.com]
Sent: Tuesday, April 28, 2009 11:16 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Hi Phil,

Thank you for your reply.

I did try "RemoveExistingProducts after InstallInitialize". It didn't work. I mean, old product was removed, but some files were not installed - because of version things.

What we need is really simple - we just need the "down-grade" working. We surely would like to increase the file version number for each release as long as down-grade working. The reason for that is, as what I posted in previous thread:
some times we may put an "older but working" build in our provisioning server to urge the user to "Downgrade" the "current but not working" build.
 
All we need is, this "down-grade" happens silently without any user involvement.

The problem now is, say, we have two builds: Build1 and Build2.

[Edward Forgács]

I am experiencing the exact same behaviour with one of our installation packages. Like you, we only do major upgrades.

Out of 17 files, 4 are getting missed on a major upgrade. I'm not convinced that it has anything to do with versions, as almost every DLL has a different version in the newer version, including one of the problematic files (and most of the ones that work too).

We are virtually at the point of shipping to a customer without upgrade capabilities. Did you end up solving the missing files issue?

I am wondering if it's possible that this was caused by the current version of the product accidentally being shipped without the Checksum="yes" attribute on the DLLs and EXEs? However, adding that into the upgrade hasn't fixed anything, it's still deletes the exact same files on uninstall, and doesn't put them back.

It is incredibly frustrating that this could ever happen - the installation ends up in a completely corrupted state, without any errors whatsoever during the upgrade.

Regards,
Edward

-----Original Message-----
From: little.forest [mailto:***@ymail.com]
Sent: Tuesday, 28 April 2009 10:02 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Thanks Jeff.

Actually, I did that in VMWare. But the result was the same - major upgrade was broken.

I then narrowed it down: it seems it only happens to 3 files. So I thought why these 3 files? I then remove them from the package and rebuilt them. This time it seems working. By saying "seems", I mean I'm not 100% sure. But at least that 2 new made builds can upgrade themselves each other. I then thought, hmm, if I re-added them in, things maybe fixed? So I re-added these 3 files in, of course, I changed their GUID and their Component ID. But you know what? It stopped working again. This drives me nuts.

I then used Orca to open these msi file to look into the problematic files. I found their file versions are different among the builds. I then thought it might be something about the file version.

I contine to search the post in this community and found this:
http://n2.nabble.com/Overide-a-file-version-to-force-upgrade-td699008.html#a699008

Mike Dimmick -2 said:
I believe InstallShield lies in the Version column of the File table if this option is set (setting it to something huge like 65535.65535.65535.65535, which is the maximum supported value). I don’t think this is a particularly good idea, however. You can’t do it with WiX – the linker takes the information directly from thefile’s resources.

I'm glad to find out this "dirty fact". But it's sad to learn that WiX doesn't support it.

I've a question to MSI. For "Major Upgrade", if the current build is uninstalled entirely before the new build installing, why bother to "compare" the file version anyways? Should the new file be installed anyways without caring about the file version in the "Major Upgrae" case?

Well, I know I probably shouldn't ask this in here. And I know MSI team might even have a reasonable explanation. But the problem is, I do major upgrade, old files gone, new files not installed - I got a broken installation. The whole thing is just because file version. And there is no way to ignore the file version checking in Major Upgrade case.

Anyways, I'll make sure all of my file versions are the same to avoid this problem.

Thanks.

have a nice day,
/Brian


________________________________
From: Jeff Reed <***@duckcreektech.com>
To: General discussion for Windows Installer XML toolset. <wix-***@lists.sourceforge.net>
Sent: Friday, April 24, 2009 5:25:34 PM
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Post by little.forest
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.

Perhaps you could try isolating the problem, by taking each version of the product that you've released so far and installing, then uninstalling on a "clean" machine?  I like to use virtual machines so that when I shut down, I can throw the state away.  Maybe you'll find some orphaned files in certain versions, and that would explain the behavior you're experiencing?

I'm fairly new to WiX, but if I was in your shoes, that is one technique I would try.

-Jeff

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
h

[Edward Forgács]

Well, I ended up finding a solution to this. The app is a .NET app, which means that the assemblies are versioned in Major.Minor.Build.Revision format.

Due to the way the compiler generates the Revision number, it can actually "downgrade" for a newer version, which seems to confuse Windows Installer in this scenario. In reality, at least the Build number should get incremented before we ship, but we don't always do this, causing the bug.

By setting the CompanionFile attribute, all the versioning goes off the main EXE, which always has at least the Build component incremented for an upgrade, effectively solving the problem.

Regards,
Edward


-----Original Message-----
From: Edward Forgács
Sent: Tuesday, 5 May 2009 2:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Major Upgrade: some files are randomly not installed

I am experiencing the exact same behaviour with one of our installation packages. Like you, we only do major upgrades.

Out of 17 files, 4 are getting missed on a major upgrade. I'm not convinced that it has anything to do with versions, as almost every DLL has a different version in the newer version, including one of the problematic files (and most of the ones that work too).

We are virtually at the point of shipping to a customer without upgrade capabilities. Did you end up solving the missing files issue?

I am wondering if it's possible that this was caused by the current version of the product accidentally being shipped without the Checksum="yes" attribute on the DLLs and EXEs? However, adding that into the upgrade hasn't fixed anything, it's still deletes the exact same files on uninstall, and doesn't put them back.

It is incredibly frustrating that this could ever happen - the installation ends up in a completely corrupted state, without any errors whatsoever during the upgrade.

Regards,
Edward

-----Original Message-----
From: little.forest [mailto:***@ymail.com]
Sent: Tuesday, 28 April 2009 10:02 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Thanks Jeff.

Actually, I did that in VMWare. But the result was the same - major upgrade was broken.

I then narrowed it down: it seems it only happens to 3 files. So I thought why these 3 files? I then remove them from the package and rebuilt them. This time it seems working. By saying "seems", I mean I'm not 100% sure. But at least that 2 new made builds can upgrade themselves each other. I then thought, hmm, if I re-added them in, things maybe fixed? So I re-added these 3 files in, of course, I changed their GUID and their Component ID. But you know what? It stopped working again. This drives me nuts.

I then used Orca to open these msi file to look into the problematic files. I found their file versions are different among the builds. I then thought it might be something about the file version.

I contine to search the post in this community and found this:
http://n2.nabble.com/Overide-a-file-version-to-force-upgrade-td699008.html#a699008

Mike Dimmick -2 said:
I believe InstallShield lies in the Version column of the File table if this option is set (setting it to something huge like 65535.65535.65535.65535, which is the maximum supported value). I don’t think this is a particularly good idea, however. You can’t do it with WiX – the linker takes the information directly from thefile’s resources.

I'm glad to find out this "dirty fact". But it's sad to learn that WiX doesn't support it.

I've a question to MSI. For "Major Upgrade", if the current build is uninstalled entirely before the new build installing, why bother to "compare" the file version anyways? Should the new file be installed anyways without caring about the file version in the "Major Upgrae" case?

Well, I know I probably shouldn't ask this in here. And I know MSI team might even have a reasonable explanation. But the problem is, I do major upgrade, old files gone, new files not installed - I got a broken installation. The whole thing is just because file version. And there is no way to ignore the file version checking in Major Upgrade case.

Anyways, I'll make sure all of my file versions are the same to avoid this problem.

Thanks.

have a nice day,
/Brian


________________________________
From: Jeff Reed <***@duckcreektech.com>
To: General discussion for Windows Installer XML toolset. <wix-***@lists.sourceforge.net>
Sent: Friday, April 24, 2009 5:25:34 PM
Subject: Re: [WiX-users] Major Upgrade: some files are randomly not installed

Post by little.forest
I appreciate if anyone can tell me why some times some files are not installed during Major Upgrade.

Perhaps you could try isolating the problem, by taking each version of the product that you've released so far and installing, then uninstalling on a "clean" machine?  I like to use virtual machines so that when I shut down, I can throw the state away.  Maybe you'll find some orphaned files in certain versions, and that would explain the behavior you're experiencing?

I'm fairly new to WiX, but if I was in your shoes, that is one technique I would try.

-Jeff

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforg