Re: [WiX-users] WiX 3.5 patch: newly added feature is automaticallyinstalled

2012-04-20 Thread Zlatko Lovcevic
I have also a new subfeature consisting of new components only and that feature 
also gets automatically installed.




 From: Peter Shirtcliffe pshirtcli...@sdl.com
To: Zlatko Lovcevic zlatko9...@yahoo.com; General discussion for Windows 
Installer XML toolset. wix-users@lists.sourceforge.net 
Sent: Thursday, April 19, 2012 10:52 AM
Subject: RE: [WiX-users] WiX 3.5 patch: newly added feature is 
automaticallyinstalled
 
In a patch (small/minor update), you cannot add existing components to a new
feature or move components between features. That's not valid. There's a
summary here
http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/MajorMinorSm
all.htm


-Original Message-
From: Zlatko Lovcevic [mailto:zlatko9...@yahoo.com] 
Sent: 19 April 2012 08:28
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX 3.5 patch: newly added feature is
automaticallyinstalled

What causes newly added (not top level) feature using purely 
WiX (3.5) to be automatically installed? I added new feature which 
contained both existing and new components and it was way above the
INSTALLLEVEL and patch installation installed it automatically. I've checked
the verbose installation log and all I found was this:
PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'NewFeature'.
Feature: NewFeature; Installed: Absent;   Request: Local;   Action: Local 
-
-
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
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.
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn, MsiPackage and DisplayInternalUI

2012-04-20 Thread Bertrand D
Hi there,


As I want my msi to have its own ui, I defined in my bundle.wxs file (burn
bootstrapper project which references the WixBalExtension):

MsiPackage
SourceFile='..\OutlookAddinWix\bin\Release\fr-fr\OutlookAddinWix.msi'
DisplayInternalUI=yes EnableFeatureSelection=yes
SuppressSignatureVerification=yes After=PIAMsi Id=MyMsi /MsiPackage

The setup project UI is defined as:

UIRef Id=WixUI_InstallDir /
UIRef Id=WixUI_ErrorProgressText /

When I execute the bootstrapper it works as expected until my msi is called.
Then I have two windows: the boostrapper window and the msi one. The next
button works correctly.

The problem appears when a message box has to be displayed in the embedded
msi: the main msi window becomes unresponsive. 

For example when the following condition is not met:

Condition Message=Office PIA is missing. Please install it.
  
/Condition

The message is not displayed. Please note that if I use directly the msi it
works accordingly.

If I kill the msi main window then the message Office PIA is missing.
Please install it. appears inside a message box. If I click on the ok
button of the message box a warning is displayed (the page called failure
actually (rtftheme)). If I click on the link FailureLogFileLink nothing
happens. Same behaviour if I try to close the window by clicking on the
close button...

I can't find anything relevant in the log fle.

I used the WiX Toolset v3.6.2809.0.


Regards



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-MsiPackage-and-DisplayInternalUI-tp7484106p7484106.html
Sent from the wix-users mailing list archive at Nabble.com.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.5 patch: newly added feature is automaticallyinstalled

2012-04-20 Thread Skildum, Mathew
By default when a new sub feature is added it is automatically enabled if the 
parent is enabled.  This is the way MSI has always functioned in my experience. 
 I do not know where this functionality is documented.

It is always best to add new files to existing features so that you do not have 
to deal with this, or you issue a updated install (new MSI) as the update to 
get the functionality you want.

You could also try writing a custom action to turn the feature back off, that 
that would be difficult in my opinion especially if your patches are all 
cumulative.


From: Zlatko Lovcevic [zlatko9...@yahoo.com]
Sent: Friday, April 20, 2012 5:53 AM
To: Peter Shirtcliffe; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.5 patch: newly added feature is  
automaticallyinstalled

I have also a new subfeature consisting of new components only and that feature 
also gets automatically installed.




 From: Peter Shirtcliffe pshirtcli...@sdl.com
To: Zlatko Lovcevic zlatko9...@yahoo.com; General discussion for Windows 
Installer XML toolset. wix-users@lists.sourceforge.net
Sent: Thursday, April 19, 2012 10:52 AM
Subject: RE: [WiX-users] WiX 3.5 patch: newly added feature is 
automaticallyinstalled

In a patch (small/minor update), you cannot add existing components to a new
feature or move components between features. That's not valid. There's a
summary here
http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/MajorMinorSm
all.htm


-Original Message-
From: Zlatko Lovcevic [mailto:zlatko9...@yahoo.com]
Sent: 19 April 2012 08:28
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX 3.5 patch: newly added feature is
automaticallyinstalled

What causes newly added (not top level) feature using purely
WiX (3.5) to be automatically installed? I added new feature which
contained both existing and new components and it was way above the
INSTALLLEVEL and patch installation installed it automatically. I've checked
the verbose installation log and all I found was this:
PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'NewFeature'.
Feature: NewFeature; Installed: Absent;   Request: Local;   Action: Local
-
-
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
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.
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Installing into the roaming profile

2012-04-20 Thread Osanger, Martin
Hello,

Is there a Property or anything else I have to set on a per user installation 
with roaming profiles, so that the installation will be marked as roamed 
installation, and my setup will be shown in the ARP on another pc?

Kind regards,
martin

-Original Message-
From: Osanger, Martin [mailto:martin.osan...@fabasoft.com] 
Sent: Mittwoch, 18. April 2012 17:55
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing into the roaming profile

Hello,

My current situation (per user installation):

I install my files to the AppDataFolder directory (in a subfolder).
Now I can switch the pc's and have the installed data (saved to roaming 
profile) available. But I'm not able to uninstall the files, if I'm not on the 
pc where I installed the msi file (cached-msi-file and ARP entry was not roamed)

Some customers delete their LocalAppDataFolder on logoff, so I have to 
install it to the AppDataFolder

Are there any best practices for creating a WIX based MSI for roaming profiles?

Kind regards,
martin
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Installing into the roaming profile

2012-04-20 Thread Rob Mensching
I've never heard that Windows supported such behavior. Sounds interesting
if it does.

On Fri, Apr 20, 2012 at 6:37 AM, Osanger, Martin 
martin.osan...@fabasoft.com wrote:

 Hello,

 Is there a Property or anything else I have to set on a per user
 installation with roaming profiles, so that the installation will be marked
 as roamed installation, and my setup will be shown in the ARP on another pc?

 Kind regards,
 martin

 -Original Message-
 From: Osanger, Martin [mailto:martin.osan...@fabasoft.com]
 Sent: Mittwoch, 18. April 2012 17:55
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Installing into the roaming profile

 Hello,

 My current situation (per user installation):

 I install my files to the AppDataFolder directory (in a subfolder).
 Now I can switch the pc's and have the installed data (saved to roaming
 profile) available. But I'm not able to uninstall the files, if I'm not on
 the pc where I installed the msi file (cached-msi-file and ARP entry was
 not roamed)

 Some customers delete their LocalAppDataFolder on logoff, so I have to
 install it to the AppDataFolder

 Are there any best practices for creating a WIX based MSI for roaming
 profiles?

 Kind regards,
 martin

 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 For Developers, A Lot Can Happen In A Second.
 Boundary is the first to Know...and Tell You.
 Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
 http://p.sf.net/sfu/Boundary-d2dvs2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn, MsiPackage and DisplayInternalUI

2012-04-20 Thread Rob Mensching
The wixstdba isn't designed to show the internal MSI UI. You'll probably
want to make a custom BA that is designed to show the internal MSI UI.

On Fri, Apr 20, 2012 at 4:48 AM, Bertrand D bertrand.w...@yahoo.com wrote:

 Hi there,


 As I want my msi to have its own ui, I defined in my bundle.wxs file (burn
 bootstrapper project which references the WixBalExtension):

 MsiPackage
 SourceFile='..\OutlookAddinWix\bin\Release\fr-fr\OutlookAddinWix.msi'
 DisplayInternalUI=yes EnableFeatureSelection=yes
 SuppressSignatureVerification=yes After=PIAMsi Id=MyMsi
 /MsiPackage

 The setup project UI is defined as:

 UIRef Id=WixUI_InstallDir /
 UIRef Id=WixUI_ErrorProgressText /

 When I execute the bootstrapper it works as expected until my msi is
 called.
 Then I have two windows: the boostrapper window and the msi one. The next
 button works correctly.

 The problem appears when a message box has to be displayed in the embedded
 msi: the main msi window becomes unresponsive.

 For example when the following condition is not met:

 Condition Message=Office PIA is missing. Please install it.

/Condition

 The message is not displayed. Please note that if I use directly the msi it
 works accordingly.

 If I kill the msi main window then the message Office PIA is missing.
 Please install it. appears inside a message box. If I click on the ok
 button of the message box a warning is displayed (the page called failure
 actually (rtftheme)). If I click on the link FailureLogFileLink nothing
 happens. Same behaviour if I try to close the window by clicking on the
 close button...

 I can't find anything relevant in the log fle.

 I used the WiX Toolset v3.6.2809.0.


 Regards



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-MsiPackage-and-DisplayInternalUI-tp7484106p7484106.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 For Developers, A Lot Can Happen In A Second.
 Boundary is the first to Know...and Tell You.
 Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
 http://p.sf.net/sfu/Boundary-d2dvs2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] -cc CabCache and reusecab settings Bug? or as designed?

2012-04-20 Thread Abbott, Brian (GE Energy)
I'm trying to use wix to build an installer for distributing and setting up an 
automated test environment. This is really made up of 3 parts, the application 
code (which is installed via its own installer), the test code which I'm using 
wix for, and some databases that contain the data used during test. The 
Databases are where I run into trouble, I was hoping to package them up in my 
installer I've built for the test code but it takes forever to put them into a 
cab file, like an hour for the 500Mb of database files.  This is really 
unacceptable to me because I want to use this as part of an automated build 
process - thus began my search for an optimization.
First I found the -cc and -reusecab options and tried them but because the test 
code files are changing with each compile the cab gets rebuilt.
Next I tried using -reusecab but separating out the Database files into a 
separate cab, still it gets rebuilt.

So my question boils down to this:
Should -reusecab regenerate 'all' the cab files if any single one of them is 
out of date, or should it be regenerating only the out of date cab files?
Is there a better solution?

I think ideally if your wix project generates multiple cab files then -reusecab 
should check each one individually and only rebuild those that don't match the 
current files.


Brian Abbott
Software Quality Engineer


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn feedback

2012-04-20 Thread Neil Sleightholm
Sounds like the same issues I have been having, I am planing to blog about what 
I have found to help others. Thanks for the LicenceUrl tip, I had missed that 
and ended up writing my own theme based on the HyperlinkLecense one.

Neil

Neil Sleightholm
n...@x2systems.commailto:n...@x2systems.com


On 19 Apr 2012, at 17:34, Pally Sandher wrote:

I  upgraded to WiX v3.6 from v3.5 earlier this week and started trying to 
implement Burn as a replacement for dotnetinstaller.
So far it's pretty easy to get a chain of packages configured  I really like 
how well done it is (great job everyone involved =) ).

A few of the issues I've noticed with it (using v3.6.2816.0):

Documentation is very sparse but I guess it's still under construction so it's 
forgivable but still causes a lot of grief when you're basically left with 
reverse engineering to discover how to implement things.
It makes it very hard to get anywhere with customising it when this is all the 
documentation you have to follow 
http://wix.sourceforge.net/manual-wix3/wixstdba_foundation_customization.htm
I had to download the sources just to figure out what size to make the logo 
which this page says you can customise 
http://wix.sourceforge.net/manual-wix3/wixstdba_branding.htm since it isn't 
mentioned anywhere.
http://wix.sourceforge.net/manual-wix3/wixstdba_license.htm says you can have 
unlicensed installation experience if you don't provide a value for the 
LicenceUrl attribute when using 
WixStandardBootstrapperApplication.HyperlinkLicense. What you actually have to 
do is set the value to   as you get the following errors when you attempt to 
build is you try to use :
The bal:WixStandardBootstrapperApplication/@LicenseUrl attribute's value cannot 
be an empty string.  If you want the value to be null or empty, simply remove 
the entire attribute.
The bal:WixStandardBootstrapperApplication element must have a value for 
exactly one of the LicenseFile or LicenseUrl attributes.

WixStandardBootstrapperApplication.HyperlinkLicense provides an Options button 
which does pretty much nothing. There's no (easy) way to hide this button which 
I've found so far. I don't appear to be the only one on this list with the same 
enquiry.

Variable names cannot contain '.' which meant lots of fun when trying to check 
for existing installations of .NET 4.0 Client Profile before I learned this 
through trial  error. The bundle will build completely fine  then fail when 
you try to run it. You should not be able to build a bundle which fails to run 
because of the Variable names, as these are simple enough to check at build 
time.

Using Signtool.exe to sign the Burn output causes it to fail when run. I only 
figured this out through searching list posts. OMFG this was a serious waste of 
time  had me running in circles trying to figure it out for half a day before 
I stumbled across the information. This needs to be writ large across the Burn 
documentation so others don't fall foul of the same issue along with 
documentation on how to code sign Burn bundles properly.

Intellisense doesn't work in WiX 3.6 using the installer. I think Neil 
Sleightholm mentioned the fix is to copy the intellisense files from the 
binaries so it seems like a packaging issue with the WiX 3.6 installers but has 
been a problem since the RC0 release  still exists 2 weeks  2 builds later.

Quiet/passive and silent install modes would be nice (dotnetinstaller supports 
these). I don't see any way to set launch options for ExePackage elements to 
specify these type of scenarios. Good for saving time when checking builds  
when automated deployment tools are used etc.

That's it so far.

Palbinder Sandher
Software Platform Engineer
T:+44 (0) 141 945 8500
F:+44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer





--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn feedback

2012-04-20 Thread Rob Diaz
I agree that I've had similar troubles.  The lack of documentation has made
this tougher to do than it should be.

Did you find a resolution for the signtool issue?  Other than not doing it,
I mean.

Rob

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: Friday, April 20, 2012 5:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn feedback

Sounds like the same issues I have been having, I am planing to blog about
what I have found to help others. Thanks for the LicenceUrl tip, I had
missed that and ended up writing my own theme based on the HyperlinkLecense
one.

Neil

Neil Sleightholm
n...@x2systems.commailto:n...@x2systems.com


On 19 Apr 2012, at 17:34, Pally Sandher wrote:

I  upgraded to WiX v3.6 from v3.5 earlier this week and started trying to
implement Burn as a replacement for dotnetinstaller.
So far it's pretty easy to get a chain of packages configured  I really
like how well done it is (great job everyone involved =) ).

A few of the issues I've noticed with it (using v3.6.2816.0):

Documentation is very sparse but I guess it's still under construction so
it's forgivable but still causes a lot of grief when you're basically left
with reverse engineering to discover how to implement things.
It makes it very hard to get anywhere with customising it when this is all
the documentation you have to follow
http://wix.sourceforge.net/manual-wix3/wixstdba_foundation_customization.htm
I had to download the sources just to figure out what size to make the logo
which this page says you can customise
http://wix.sourceforge.net/manual-wix3/wixstdba_branding.htm since it isn't
mentioned anywhere.
http://wix.sourceforge.net/manual-wix3/wixstdba_license.htm says you can
have unlicensed installation experience if you don't provide a value for
the LicenceUrl attribute when using
WixStandardBootstrapperApplication.HyperlinkLicense. What you actually have
to do is set the value to   as you get the following errors when you
attempt to build is you try to use :
The bal:WixStandardBootstrapperApplication/@LicenseUrl attribute's value
cannot be an empty string.  If you want the value to be null or empty,
simply remove the entire attribute.
The bal:WixStandardBootstrapperApplication element must have a value for
exactly one of the LicenseFile or LicenseUrl attributes.

WixStandardBootstrapperApplication.HyperlinkLicense provides an Options
button which does pretty much nothing. There's no (easy) way to hide this
button which I've found so far. I don't appear to be the only one on this
list with the same enquiry.

Variable names cannot contain '.' which meant lots of fun when trying to
check for existing installations of .NET 4.0 Client Profile before I learned
this through trial  error. The bundle will build completely fine  then
fail when you try to run it. You should not be able to build a bundle which
fails to run because of the Variable names, as these are simple enough to
check at build time.

Using Signtool.exe to sign the Burn output causes it to fail when run. I
only figured this out through searching list posts. OMFG this was a serious
waste of time  had me running in circles trying to figure it out for half a
day before I stumbled across the information. This needs to be writ large
across the Burn documentation so others don't fall foul of the same issue
along with documentation on how to code sign Burn bundles properly.

Intellisense doesn't work in WiX 3.6 using the installer. I think Neil
Sleightholm mentioned the fix is to copy the intellisense files from the
binaries so it seems like a packaging issue with the WiX 3.6 installers but
has been a problem since the RC0 release  still exists 2 weeks  2 builds
later.

Quiet/passive and silent install modes would be nice (dotnetinstaller
supports these). I don't see any way to set launch options for ExePackage
elements to specify these type of scenarios. Good for saving time when
checking builds  when automated deployment tools are used etc.

That's it so far.

Palbinder Sandher
Software Platform Engineer
T:+44 (0) 141 945 8500
F:+44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the Virtual Environment** Integrated
Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow
G20 0SP Email Disclaimer






--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users





--
For Developers, A Lot Can Happen In A Second.
Boundary is the first