[WiX-users] Prompt Error messages about, Open Folders on uninstall

[Arun Krishnan [ NeSTIT]]

Hi All

 

I have an installer, which is working perfect ;  if any of the folders
are open  on  uninstall ,   is there any way to notify user about the
open folders , as it may cause a faulty uninstallation ?

 

Thanks

ArunK

 

 

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prompt Error messages about, Open Folders on uninstall

[Carter Young]

Please don't double post.  I saw this question yesterday...

Quoting "Arun Krishnan [ NeSTIT]" :

> Hi All
>
>
>
> I have an installer, which is working perfect ;  if any of the folders
> are open  on  uninstall ,   is there any way to notify user about the
> open folders , as it may cause a faulty uninstallation ?
>
>
>
> Thanks
>
> ArunK
>
>
>
>
>
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>




--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Get ProductVersion of Installation Package in a bootstrapper

[Ingo Fischer]

My understanding was, you can read the ProductVersion of each MSI of a 
bootstrapper in the event:
 
DetectPackageBegin(object sender, DetectPackageBeginEventArgs e)
 or in the event
DetectPackageCompleted(object sender, DetectPackageCompleteEventArgs e)
 
something like: e.ProductVersion
 
but I can not find it.
 
I would like to display the versions of the msi-files that are installed on the 
UI when running the bootstrapper.
 
  
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] EV code signing compatibility

[David Watson]

Hi,
Has anyone used one of the new EV Authenticode certificates to sign MSIs and 
bundles?

If so have you had any issues with it so far?

Also is it possible to export the public key into a cer file from the hardware 
token to allow you to embed it in an MSI to do UAC-less patches?



Cheers
Dave
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.



This message has been scanned for malware by Websense. www.websense.com

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Get ProductVersion of Installation Package in a bootstrapper

[Sean Hall]

You have to get use the PackageID to get that information from the
BootstrapperApplicationData.xml file.  Note that it wasn't available until
WiX 3.9.421.  C# code is at http://stackoverflow.com/questions/12846421.


On Wed, May 28, 2014 at 10:41 AM, Ingo Fischer
wrote:

> My understanding was, you can read the ProductVersion of each MSI of a
> bootstrapper in the event:
>
> DetectPackageBegin(object sender, DetectPackageBeginEventArgs e)
>  or in the event
> DetectPackageCompleted(object sender, DetectPackageCompleteEventArgs e)
>
> something like: e.ProductVersion
>
> but I can not find it.
>
> I would like to display the versions of the msi-files that are installed
> on the UI when running the bootstrapper.
>
>
>
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Build order problems Votive vs MSBuild

[Tony]

We've run into this issue in which it appears as though our .sln builds
correctly when built through VS (Votive installed), but when built using
MSBuild, the WiX project dependencies appear to be ignored.  This results
in a build order problem (csproj is built _after_ wixproj that needs its
output).  If the build order is forced (manually add a dependency in the
sln file), the MSBuild build works fine.  As such, it appears as if MSBuild
is used on the .sln, the auto generated project dependency list (and thus
build order) is not correct.

NOTE:  We do NOT have WiX installed on our build server.  I have modified
our wixproj files per
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html.

I found an old thread titled "Problem with build order under MSBuild 4.0"
(4/14/10) that describes an identical issue.  And another thread
titled "Wix3.6.1518.0 to 3.6.1915.0 issue" (7/20/11) in which this bug
http://sourceforge.net/p/wix/bugs/2588/ is linked.  But I can't tell if the
bug was fixed or just closed.

Any ideas?

VS/TFS2012, Wix 3.8
-- 
Tony
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Build order problems Votive vs MSBuild

[John Cooper]

With the proviso that WiX is installed on all of my build servers:

1) I use express references to projects containing assemblies that the wixproj 
will consume in the wixproj

2) I use Votive macros to layout the paths to all of my assemblies.  I never 
attempt to guess where the assembly will be as this is usually different on 
developer and build server environments

3) for slow MSBuild targets (such as ZIPping up assemblies into plugins for 
some of our clients, I work hard to ensure that all such targets have Inputs 
and Outputs attributes.  This helps prevent these targets from "over-running" 
their parent projects and perhaps not having their outputs ready for 
consumption by the wixproj when the wixproj runs.

4) I stuff all of my content into a separate wixlib prior to the run of the 
main installer wixproj.  The setup wixproj then links to the wixlib, and all 
the assembly projects are added as express references to the wixlib wixproj.

--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com


-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Wednesday, May 28, 2014 3:56 PM
To: WiX Users
Subject: [WiX-users] Build order problems Votive vs MSBuild

We've run into this issue in which it appears as though our .sln builds 
correctly when built through VS (Votive installed), but when built using 
MSBuild, the WiX project dependencies appear to be ignored.  This results in a 
build order problem (csproj is built _after_ wixproj that needs its output).  
If the build order is forced (manually add a dependency in the sln file), the 
MSBuild build works fine.  As such, it appears as if MSBuild is used on the 
.sln, the auto generated project dependency list (and thus build order) is not 
correct.

NOTE:  We do NOT have WiX installed on our build server.  I have modified our 
wixproj files per 
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html.

I found an old thread titled "Problem with build order under MSBuild 4.0"
(4/14/10) that describes an identical issue.  And another thread titled 
"Wix3.6.1518.0 to 3.6.1915.0 issue" (7/20/11) in which this bug 
http://sourceforge.net/p/wix/bugs/2588/ is linked.  But I can't tell if the bug 
was fixed or just closed.

Any ideas?

VS/TFS2012, Wix 3.8
--
Tony
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Best approach to override file versioning

[Rob Mensching]

Schedule RemoveExistingProducts very very early?

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: Jesper Alf Dam [mailto:j...@medical-insight.com] 
Sent: Monday, May 26, 2014 3:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Best approach to override file versioning

We have a product that ships with a number of independently versioned 
third-party libraries, in addition to our own files (whose file versions follow 
the product version)

Now, we've encountered a situation where some of the third party files we want 
to ship in our installer have a lower version than the ones used in our 
previous release.

This means that when a user tries to run the installer to upgrade the product, 
the following happens:

1. during the "costing" step, MSI figures that it already has a newer version 
of the file than the one we're trying to install (and therefore, there is no 
need to install the file from our installer) 2. MSI then uninstalls the old 
product version, removing the *newer* version of the file 3. MSI then installs 
the files from the new product version, except for the ones that got filtered 
out in step 1

The end result is that we get the new version of our product installed, but 
without the files whose versions were bumped "down". The existing version of 
those files has been uninstalled, and the version from the installer has been 
skipped, leaving us with neither. And this leaves us with a product that 
doesn't actually *work*.

This process strikes me as pretty obviously broken, but that is a matter for 
the Windows Installer.

Here and now, it is only a couple of files that have this problem, and we could 
handle those as a special case, but we would like to find a general solution 
that ensures that "whatever we have in the installer gets installed". We ship a 
set of files that have been tested together, and which form a complete, 
coherent product, and if, at some point in the future, we again choose/need to 
ship a few files whose versions have decreased since the last release, then we 
don't want to have to special-case that to make sure the right files get 
installed.

We would like to ensure that if newproductversion > oldproductversion, then 
*all* files from newproductversion get installed.

Note that all our files are installed locally for our product only. We don't 
install any shared DLLs, where versioning would obviously be more complicated. 
In our case, we really just want WiX and MSI to base their decisions on the 
product version, not the file versions, for all our files, now and in the 
future.

What would be the best way to achieve this?

We could use REINSTALLMODE=amus, but that seems like the sledgehammer approach. 
It is my understanding that this property is intended for administrative 
installs to specify, rather than something that should be burnt into the 
installer itself. Is there a better approach?


Thanks,

Jesper

--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Build order problems Votive vs MSBuild

[Rob Mensching]

Sounds a lot like: 
http://blogs.msdn.com/b/msbuild/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Wednesday, May 28, 2014 1:56 PM
To: WiX Users
Subject: [WiX-users] Build order problems Votive vs MSBuild

We've run into this issue in which it appears as though our .sln builds 
correctly when built through VS (Votive installed), but when built using 
MSBuild, the WiX project dependencies appear to be ignored.  This results in a 
build order problem (csproj is built _after_ wixproj that needs its output).  
If the build order is forced (manually add a dependency in the sln file), the 
MSBuild build works fine.  As such, it appears as if MSBuild is used on the 
.sln, the auto generated project dependency list (and thus build order) is not 
correct.

NOTE:  We do NOT have WiX installed on our build server.  I have modified our 
wixproj files per 
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html.

I found an old thread titled "Problem with build order under MSBuild 4.0"
(4/14/10) that describes an identical issue.  And another thread titled 
"Wix3.6.1518.0 to 3.6.1915.0 issue" (7/20/11) in which this bug 
http://sourceforge.net/p/wix/bugs/2588/ is linked.  But I can't tell if the bug 
was fixed or just closed.

Any ideas?

VS/TFS2012, Wix 3.8
--
Tony
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using '*' in Component Guids and Patches

[Rob Mensching]

IIRC, I don't think that's going to work out well. You can try but I think 
patching across directory moves probably doesn't work out great since IIRC 
moving Component directories during repair doesn't tend to work out real well 
either. But that's just from memory...

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: Farrukhw [mailto:farru...@gmail.com] 
Sent: Sunday, May 25, 2014 10:13 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using '*' in Component Guids and Patches

Hi
While searching for best practices, I came across  this thread 

, which is discussing the use of '*' instead of GUIDs in components. 

As far I know, while generating GUID dynamically from '*', if the destination 
of a Component is changes, so its GUID would also be changed.
There may be some other factors as well.

Let's say we released ver 1.0.0.0 and then in 1.0.1.0 we changed the 
destination of a Component from Dir1 to Dir2.

*Question:* If we generate Differential Patch between these two versions, would 
the file get patched who's destination was changed in ver 1.0.1.0?
Would using '*' in this case would be good?

Regards
Farrukh





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-in-Component-Guids-and-Patches-tp7594909.html
Sent from the wix-users mailing list archive at Nabble.com.

--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Generic wix Project

[Rob Mensching]

I think C# projects do the same thing.

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: Friday, May 23, 2014 8:20 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Generic wix Project

Look at a verbose MSBuild log.  The Clean target is probably fired by VS. 
There are a number of reasons why this might be the case.  Changes would depend 
on your business requirements.  You might add a MSBuild task which copies the 
files to a common area on a successful build.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Generic-wix-Project-tp7594883p7594888.html
Sent from the wix-users mailing list archive at Nabble.com.

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE 
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available 
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using '*' in Component Guids and Patches

[Bryan Wolf]

You should change the component code if the destination of the component
changes, as documented here:
http://msdn.microsoft.com/en-us/library/aa367849(v=vs.85).aspx

Changing the component code is incompatible with minor/small updates; since
you're talking about a patch and a major upgrade patch is more or less a
non-feature, the short answer is that it won't work. Don't change the path
of a component during the course of a patch - it's just not a compatible
use case.

Technically speaking, you can make it work through careful and very
elaborate tailoring of the MSI package and manipulation of the feature
tree, but you really really don't want to do this :-)


On Wed, May 28, 2014 at 5:29 PM, Rob Mensching  wrote:

> IIRC, I don't think that's going to work out well. You can try but I think
> patching across directory moves probably doesn't work out great since IIRC
> moving Component directories during repair doesn't tend to work out real
> well either. But that's just from memory...
>
> ___
>  FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
> -Original Message-
> From: Farrukhw [mailto:farru...@gmail.com]
> Sent: Sunday, May 25, 2014 10:13 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Using '*' in Component Guids and Patches
>
> Hi
> While searching for best practices, I came across  this thread <
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Best-Practices-Using-quot-quot-for-GUID-automation-td5234716.html
> >
> , which is discussing the use of '*' instead of GUIDs in components.
>
> As far I know, while generating GUID dynamically from '*', if the
> destination of a Component is changes, so its GUID would also be changed.
> There may be some other factors as well.
>
> Let's say we released ver 1.0.0.0 and then in 1.0.1.0 we changed the
> destination of a Component from Dir1 to Dir2.
>
> *Question:* If we generate Differential Patch between these two versions,
> would the file get patched who's destination was changed in ver 1.0.1.0?
> Would using '*' in this case would be good?
>
> Regards
> Farrukh
>
>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-in-Component-Guids-and-Patches-tp7594909.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using '*' in Component Guids and Patches

[Farrukhw]

It might not be a common practice, but I faced it due to some customer
requirement when we have to move a dll to another location. So ethically,
it should be a Major Upgrade which would handle it with no problem. But I
was asked to build a patch, as it is just one dll,

So we build a new dll with a new incremented version and while sing same
GUID for the component, patch didn't moved the file to new location, but
did updated the dll to the new version.

However, I tried to reproduced this using "*" instead of GUID and it simply
didn't worked.



On Thu, May 29, 2014 at 3:43 AM, Bryan Wolf-2 [via Windows Installer XML
(WiX) toolset]  wrote:

> You should change the component code if the destination of the component
> changes, as documented here:
> http://msdn.microsoft.com/en-us/library/aa367849(v=vs.85).aspx
>
> Changing the component code is incompatible with minor/small updates;
> since
> you're talking about a patch and a major upgrade patch is more or less a
> non-feature, the short answer is that it won't work. Don't change the path
> of a component during the course of a patch - it's just not a compatible
> use case.
>
> Technically speaking, you can make it work through careful and very
> elaborate tailoring of the MSI package and manipulation of the feature
> tree, but you really really don't want to do this :-)
>
>
> On Wed, May 28, 2014 at 5:29 PM, Rob Mensching <[hidden 
> email]>
> wrote:
>
> > IIRC, I don't think that's going to work out well. You can try but I
> think
> > patching across directory moves probably doesn't work out great since
> IIRC
> > moving Component directories during repair doesn't tend to work out real
> > well either. But that's just from memory...
> >
> > ___
> >  FireGiant  |  Dedicated support for the WiX toolset  |
> > http://www.firegiant.com/
> >
> > -Original Message-
> > From: Farrukhw [mailto:[hidden 
> > email]]
>
> > Sent: Sunday, May 25, 2014 10:13 PM
> > To: [hidden email]
> > Subject: [WiX-users] Using '*' in Component Guids and Patches
> >
> > Hi
> > While searching for best practices, I came across  this thread <
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Best-Practices-Using-quot-quot-for-GUID-automation-td5234716.html
> > >
> > , which is discussing the use of '*' instead of GUIDs in components.
> >
> > As far I know, while generating GUID dynamically from '*', if the
> > destination of a Component is changes, so its GUID would also be
> changed.
> > There may be some other factors as well.
> >
> > Let's say we released ver 1.0.0.0 and then in 1.0.1.0 we changed the
> > destination of a Component from Dir1 to Dir2.
> >
> > *Question:* If we generate Differential Patch between these two
> versions,
> > would the file get patched who's destination was changed in ver 1.0.1.0?
> > Would using '*' in this case would be good?
> >
> > Regards
> > Farrukh
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-in-Component-Guids-and-Patches-tp7594909.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
>
> > The best possible search technologies are now affordable for all
> companies.
> > Download your FREE open source Enterprise Search Engine today!
> > Our experts will assist you in its installation for $59/mo, no
> commitment.
> > Test it for FREE on our Cloud platform anytime!
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > [hidden email] 
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> --
>
> > Time is money. Stop wasting it! Get your web API in 5 minutes.
> > www.restlet.com/download
> > http://p.sf.net/sfu/restlet
> > ___
> > WiX-users mailing list
> > [hidden email] 
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> --
>
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> WiX-users mailing list
> [hidden email] 
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>