Re: [WiX-users] Bundle registers itself as separate product and can't be removed - 3.6.2520 problem only

2012-01-25 Thread Peter Bulyaki
Hi Bob,

I can't say I fully agree with you (or maybe there is a misunderstanding on
my part), because in my understanding the bundle is just a proxy that
installs multiple MSI products - each of which can be uninstalled
individually. One of the many requirements towards our installer is that
the bundle installer itself should not be a separately installed product -
only the MSIs. (Our MSIs can be installed individually, without the need
for the bundle installer.) The latest changes in 3.6.2520 made me downgrade
to the beta because of this issue.

I think that ours is a valid scenario:
We have 7 individual products, with 7 MSI installers. There are 2 ways to
install them:
1. Each MSI can be installed individually from the CD.
2. Additionally, there is a bundle installer that can install the above 7
products in one go.

Our management wants that 1. and 2. should leave the target computer in
exactly the same state (which means no bundle installed in ARP as a
separate product). Users will have to uninstall each of the 7 products
individually in both cases.

Cheers:
Peter

On Tue, Jan 24, 2012 at 6:11 PM, Bob Arnson b...@joyofsetup.com wrote:

 On 24-Jan-12 07:14, Peter Bulyaki wrote:
  So I would rephrase my question: is there a way to install a bundle
 without
  registering it not only in Programs and Features, but in general with
  Windoes Installer as a separate product?
 Bundles aren't MSI products. They need to run (and therefore be the
 entry point in ARP/PF) so they can clean up after being uninstalled.

 --
 sig://boB
 http://joyofsetup.com/



 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Run App After Setup

2012-01-25 Thread Rob Hamflett
On 24/01/2012 16:46, Parkes, Kevin wrote:
 The only snag is having the checkbox at the bottom of the dialog to overcome 
 the problem of its having a grey background - it there a way to get the 
 checkbox in the main bit of the dialog without the grey background?
Yes, but it's a bit hacky.  You make the checkbox control the same size 
as the checkbox, effectively cutting off the text.  You then place a 
second text control next to it that contains the text and mark it as 
transparent.  This looks right, but you won't be able to click the text 
to toggle the checkbox, and screen readers will get confused.

Rob


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] creating a WIX small or minor patch

2012-01-25 Thread tomer.c
Found Paraffin! 
http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
I think that this is what I need! So that my HEAT won't generate different 
GUIDs each time.
Are you familiar with it?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, January 24, 2012 4:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor patch

I don't think your problems are related to patch building. I think your second 
MSI is not a valid minor update.
Try running the second MSI as an upgrade of the first one using the command 
line mentioned in Rob's blog 
http://robmensching.com/blog/posts/2007/1/4/Doing-a-small-update-or-minor-upg
rade-in-MSI-Use
I think you'll get some similar errors in the log.
If this is the case, you go through the MSDN sections mentioned on making minor 
upgrades and check both of your MSIs to ensure you're following all the rules - 
they are quick tricky. Comparing the two MSIs by looking at them in Orca rather 
than by looking at the code so you can see what's actually been generated.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: 24 January 2012 14:00
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

I see, the other reason we don't compress into cab is time, since we compress 
everything into RARs for client delivery... so a cab will be redundant. But 
point taken, I won't let anyone change a thing :).

To the main problem... I still can't seem to be able to run the Pyro command no 
matter what...
After taking your advice I removed the ComponentRef Id=SampleComponent/ 
from within the PatchFamily Id='SamplePatchFamily' Version='1.0.0.0'
Supersede='yes' tag
And then I did get errors referring to my files, that is progress... but the 
errors are as mentioned before:
C:\Sample_1pyro.exe -v patch\patch.wixmsp -out patch\patch.msp -t RTM 
patch\diff.wixmst Microsoft (R) Windows Installer Xml Patch Builder version
3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved.

pyro.exe : warning PYRO1099 : Changing the ProductCode in a patch is not 
recommended because the patch cannot be uninstalled nor can it be sequenced 
along with other patches for the target product.
See http://msdn2.microsoft.com/library/aa367571.aspx for more information.
E:\4\139\Sources\Setup\common\Wix\Base\files.wxs(62) : error PYRO0305 :
Removing component 'QsConfig.exe' from feature 'ProductFeature' is not 
supported. Either the component was removed or the guid changed. Add the 
component back, undo the change to the component guid, or remove the entire 
feature.



The first section is:
Changing the ProductCode in a patch is not recommended because the patch cannot 
be uninstalled nor can it be sequenced along with other patches for the target 
product.
See http://msdn2.microsoft.com/library/aa367571.aspx for more information

I understand, I won't change the product ID between builds.

The second part:
E:\4\139\Sources\Setup\common\Wix\Base\files.wxs(62) : error PYRO0305 :
Removing component 'QsConfig.exe' from feature 'ProductFeature' is not 
supported. Either the component was removed or the guid changed. Add the 
component back, undo the change to the component guid, or remove the entire 
feature.

That I don't understand, I didn't remove anything, maybe they are getting 
different ids!? Both MSIs I used to generate the diff.wixmst are the same 
except for some code change in one of the assemblies...


Thanks again!


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Tuesday, January 24, 2012 3:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor patch

That would invalidate the MSI if you don't keep the relevant tables up to date 
too. Its not a recommended practice - do a proper build instead.

I've not built a patch targeting an unpacked MSI but I believe the media number 
would still need to be higher than the highest file id in the MSI file table. 
The patch itself will contain cabinets for the altered files using the media 
cabinet name.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: 24 January 2012 13:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

One more thing I remembered, in our MSIs we don't use CAB, we just create a 
folder next to the MSI, it's easier for us to replace/fix text/config files 
after a build was already create...
Does this influence the patch.wxs? I see that there is a Media tag that points 
to a cab file...

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Tuesday, January 24, 2012 11:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor 

Re: [WiX-users] Burn: patch for bundle

2012-01-25 Thread Vadym Verba
I'm not sure, if I understood this right.

Here is usecase: I have old v1.0 bundle installed and new patch bundle with
patches only (totally new bundle with new upgrade code or with the same
one?). I installed patch bundle and then decided to change/repair/uninstall
some patched product from v1.0 bundle. In this case downgrade will be
detected for it. What should BA do now? Continue installation anyway and rely
on valid patch sequence detection during msi execution?

If this is the case, is there any way to patch/change old v1.0 BA itself?

And how should I indicate that bundle is a patch for already existing one.

 

--

Date: Tue, 24 Jan 2012 12:15:26 -0500

From: Bob Arnson b...@joyofsetup.com

Subject: Re: [WiX-users] Burn: patch for bundle

To: wix-users@lists.sourceforge.net

Message-ID: 4f1ee72e.1070...@joyofsetup.com

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 

On 24-Jan-12 10:02, Vadym Verba wrote:

 I have a small but a very vital question: how to patch bundle?

Build a new bundle that contains the patches, either by themselves or 

with the original packages.

 

-- 

sig://boB

http://joyofsetup.com/

 

/pre
BR style=font-size:4px;
a href = http://www.sdl.com/sdl-vision;img 
src=http://www.sdl.com/images/email_new_logo.png; alt=www.sdl.com/sdl-vision 
border=0//a
BR
font face=arial  size=2a href =http://www.sdl.com/sdl-vision; 
style=color:005740; font-weight: boldwww.sdl.com/sdl-vision/a/font
BR
BR
font face=arial  size=1 color=#736F6E
bSDL PLC confidential, all rights reserved./b
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.BR
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.BR
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.
/font
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] creating a WIX small or minor patch

2012-01-25 Thread Peter Shirtcliffe
No. The recommendation is to use heat to generate your first version and then
make the changes manually thereafter. Our product and work practices make
this a suitable way to work. We use * for component guids to keep them
constant.

We have one product that heats files with each build but we service it with
major upgrades.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] 
Sent: 25 January 2012 09:10
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

Found Paraffin!
http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffi
n.aspx
I think that this is what I need! So that my HEAT won't generate different
GUIDs each time.
Are you familiar with it?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, January 24, 2012 4:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor patch

I don't think your problems are related to patch building. I think your
second MSI is not a valid minor update.
Try running the second MSI as an upgrade of the first one using the command
line mentioned in Rob's blog
http://robmensching.com/blog/posts/2007/1/4/Doing-a-small-update-or-minor-upg
rade-in-MSI-Use
I think you'll get some similar errors in the log.
If this is the case, you go through the MSDN sections mentioned on making
minor upgrades and check both of your MSIs to ensure you're following all the
rules - they are quick tricky. Comparing the two MSIs by looking at them in
Orca rather than by looking at the code so you can see what's actually been
generated.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: 24 January 2012 14:00
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

I see, the other reason we don't compress into cab is time, since we compress
everything into RARs for client delivery... so a cab will be redundant. But
point taken, I won't let anyone change a thing :).

To the main problem... I still can't seem to be able to run the Pyro command
no matter what...
After taking your advice I removed the ComponentRef Id=SampleComponent/
from within the PatchFamily Id='SamplePatchFamily' Version='1.0.0.0'
Supersede='yes' tag
And then I did get errors referring to my files, that is progress... but the
errors are as mentioned before:
C:\Sample_1pyro.exe -v patch\patch.wixmsp -out patch\patch.msp -t RTM
patch\diff.wixmst Microsoft (R) Windows Installer Xml Patch Builder version
3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved.

pyro.exe : warning PYRO1099 : Changing the ProductCode in a patch is not
recommended because the patch cannot be uninstalled nor can it be sequenced
along with other patches for the target product.
See http://msdn2.microsoft.com/library/aa367571.aspx for more information.
E:\4\139\Sources\Setup\common\Wix\Base\files.wxs(62) : error PYRO0305 :
Removing component 'QsConfig.exe' from feature 'ProductFeature' is not
supported. Either the component was removed or the guid changed. Add the
component back, undo the change to the component guid, or remove the entire
feature.



The first section is:
Changing the ProductCode in a patch is not recommended because the patch
cannot be uninstalled nor can it be sequenced along with other patches for
the target product.
See http://msdn2.microsoft.com/library/aa367571.aspx for more information

I understand, I won't change the product ID between builds.

The second part:
E:\4\139\Sources\Setup\common\Wix\Base\files.wxs(62) : error PYRO0305 :
Removing component 'QsConfig.exe' from feature 'ProductFeature' is not
supported. Either the component was removed or the guid changed. Add the
component back, undo the change to the component guid, or remove the entire
feature.

That I don't understand, I didn't remove anything, maybe they are getting
different ids!? Both MSIs I used to generate the diff.wixmst are the same
except for some code change in one of the assemblies...


Thanks again!


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Tuesday, January 24, 2012 3:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor patch

That would invalidate the MSI if you don't keep the relevant tables up to
date too. Its not a recommended practice - do a proper build instead.

I've not built a patch targeting an unpacked MSI but I believe the media
number would still need to be higher than the highest file id in the MSI file
table. The patch itself will contain cabinets for the altered files using the
media cabinet name.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: 24 January 2012 13:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

One more 

Re: [WiX-users] .NET config best practices

2012-01-25 Thread John Cooper
I would concur.  Saving as much configuration to a database as possible, and 
deferring as much configuration as possible to application configuration, is 
the most stable approach.  We use this on all of our products.  The installer 
modifies the web.config only enough to bootstrap the configuration 
process--it puts a connection string into the web.config.  The rest of 
configuration is handled by the application itself.

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



-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Tuesday, January 24, 2012 6:00 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET config best practices

My suggestion is that you store this information in some soft of database and 
have the application (or a configuration application ) manage the settings.
I think you'll find it difficult to be able to try and save / merge all this 
data as time goes on.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-config-best-practices-tp7222030p7222360.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
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.


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] .NET config best practices

2012-01-25 Thread rsmart8452
Thanks! I've been thinking about splitting this into two files so I'll explore 
this further.

RMartin
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Christopher Painter chr...@iswix.com
Date: Tue, 24 Jan 2012 14:26:10 
To: General discussion for Windows Installer XML 
toolset.wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net
Reply-To: chr...@iswix.com,
General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET config best practices

Sadly this is a huge huge hole / disconnect between how MSI works and how 
XML works.   MSI treats a Registry Value and File as atomic but an XML file 
is not atomic.  Elements, Attributes and Values are atomic.


The simplest way, assuming Unity can do this,  is to layer your 
configuration data into 2 files:


1) Stock File that the installer always overwrites and owns

2) Extension / Override file that a user can populate and the installer 
will never overwrite or own.


Then in code layer the data from the two files to drive the program.  If 
Unity can't do this, then yes, you are hosed.  You'll have to write a CA ( 
because WiX has support for XML write but not XML read ) to read the data, 
then overwrite the file and then reapply the data. (  Merge )


There is the remember property pattern ( as described for registry here 
http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Proper
ty-pattern )  but it really doesn't scale to an application driven but 
boatloads of XML.



From: Richard Martin rsmart8...@gmail.com

Sent: Tuesday, January 24, 2012 4:15 PM

To: wix-users@lists.sourceforge.net

Subject: [WiX-users] .NET config best practices


I'm confused about best practices to use when deploying and maintaining

.NET *.config files via MSI. Our app uses the UnityContainer to manage 
type

injection and type configuration, some of which is environmental, meaning

type config changes at each customer site. This Unity configuration is

stored in a *.config file along with SQL connections, WCF bindings, and

other static environmental information.


We almost always have to update the config with new Unity type mappings

added for each new release as the software grows.


There is a significant amount of configuration required during an install,

so we want to permanently persist the config on the machine even if the

software is uninstalled. Our install techs have had to uninstall the

software before an update to the next version could be applied, so the MSI

package needs to anticipate this scenario.


I'm trying to build a WiX installer that gracefully handles all these

requirements without breaking all the benefits that MSI brings to the

table, like using custom actions to work around challenges I'm having. I

would also like to take advantage of any best practices others have

established as appropriate. At this point, I have a working MSI with the

exception of this one config file.


Here's my idea of the dream config handling:


1) Initial install copies the *.config file


2) Config is updated with appropriate environmental settings


3) Install ensures this file is permanent and will not be removed by

uninstalling.


4) During a software update, settings are harvested from this file


5) The *.config included in the update package is copied over the old

version


6) The new config file is updated with settings harvested from the prior

*.config version.


This file does not make a good candidate for bundling in a component with

another file (KeyPath=no), since there is no other artifact I want left

behind during uninstall. I'm simply lost trying to get there. I've tried

multiple ideas and all have fallen flat, currently I have Permanent = 
yes

on the config's component, which allows the file to be copied and updated

with settings during initial install, but further release updates do not

copy in the new config file included in the package.


How do I get there? Or if these are unreasonable expectations, then what

changes should I make to my installer or our application to accomplish

these goals?


Thanks for any input!


RMartin


--

Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers

is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,

Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just 

Re: [WiX-users] ERROR1603

2012-01-25 Thread James Green
http://robmensching.com/blog/posts/2010/8/2/The-first-thing-I-do-with-an-MSI-log

Thanks Rob, probably the most useful piece of info I've heard regarding MSI's.  
I knew about the logs but not value 3.

Cheers,

James
LEGAL NOTICE
This message is intended for the use of the named recipient(s) only and may 
contain confidential and / or privileged information. If you are not the 
intended recipient, please contact the sender and delete this message. Any 
unauthorised use of the information contained in this message is prohibited.
Mango Business Solutions Limited is registered in England under No. 4560258 
with its registered office at Suite 3, Middlesex House, Rutherford Close, 
Stevenage, Herts, SG1 2EF, UK.

PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WIX - Issue with filenames that have two $$ in them.

2012-01-25 Thread Josh Suereth
Hi everyone!

I'm trying to bundle up Scala's documentation using WIX.   Right now, the
light program is exiting with error LIGHT0083 that it can't find the files
I'm bundling.  I have a file named Utility$$Escape$.html and it's
printing in the error message that its source path is Utility$Escape$.html

Is there some kind of escape character I can use for $ in WIX?  I tried
using #23; and that did not work.   It appears to be truncating that one $
off the name, and this is killing the bundle.


Thanks for the help, and wonderful product.  I love using it.

- Josh
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] MSI setup for different flavours of Product

2012-01-25 Thread David Watson
The best way to do this is to ask yourself (or whoever made the decision)
whether you really need multiple versions for customers. In most situations
you should be able to get away with just one installer and if you really need
to, allow some parts of it to be optional to the end user.

If this is impossible or out of your control you could make you installation
modular with a core product MSI and a documentation MSI(s) and make separate
burn bundles for customers. If you do this then most of your patches will be
to the core MSI and can be applied to all the products you release regardless
of customer and you may choose to patch any doc MSIs separately.

Dave

-Original Message-
From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] 
Sent: 25 January 2012 15:46
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] MSI setup for different flavours of Product

I'm hoping for some advice about MSI and Patching using Wix.

I am currently moving one of products from Installshield to MSI using Wix to
generate it. Our product has a number of different variations depending on
which customer we deliver to. Typically all the different versions differ in
a few documentation files (we give some customers more documentation about
the back end system than others). The way we achieved this previously with
installshield  was to have a folder on disk that sits alongside the product
installer. At the end of any installation the documentation files in the
folder would be copied to the users machine into the install location
(implemented using the Installshield scripting language).
 
Previously, we never did any 'real' (in the MSI sense) patching of our
products. Once we move to MSI, we would like to produce proper patches (small
updates mainly).   My question, what is the best way for us (in the MSI
world) to produce the variations of our product, so that we can patch easily.
What I am hoping for is a solution that is simpler than producing a different
product MSI release for effectively, each variant of the product because then
I would need to produce multiple patches when the product is basically the
same in each case (except for a few doc files).
 
Any help is appreciated.
 
sanjay   
-
-
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
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.


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

2012-01-25 Thread Blair
Are these problems in 3.5 or 3.6? Last year I discovered a defect in DTF
wherein a race condition upon completion of a DTF custom action call would
cause a failure return to Windows Installer, even when the managed code
custom action itself returned success. That was fixed in 3.6, but the bug
remains in 3.5. The race condition is in the native wrapper code. It tends
to manifest only when there is a heavy load (either CPU or disk) in the
machine at the moment that the custom action is completing, and thus was
very difficult to reproduce (I was fortunate enough to have exactly one box
that reproduced it with any (but still uncertain) regularity, out of dozens
of other boxes that would never reproduce it).

You can take the SfxCA.dll files from recent builds of 3.6 and use them with
3.5's RTM build to get that race condition fix and an unrelated memory leak
fix. I don't remember the bug numbers, but I do remember the investigation
and fix of the race condition.

I don't know what would cause the QuietExec issue, however.

-Blair


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

2012-01-25 Thread Christopher Painter
Blair,


 That is excellent information.  Yes, I am on 3.5 currently.  I'm no longer 
with Overwatch so I can make the call to go to 3.6 much easier.  


FWIW, in this install I have 1 immed. DTF CA that costs and then 2 more 
CA's that perform uninstall and install actions.   The cost CA always works 
and then the uninstall CA fails about .5% of the time based on 800+ 
machines deployed so far.  They are all Server 2008 R2 x64 SP1  Virtual 
Machines so maybe there's a problem there in CPU handling that exposes this 
race condition.


Only problem at this point is since the work around to 1603 is to run the 
advertisement again I can't rebuilt the package to see if 3.6 fixes it or 
not.



From: Blair os...@live.com

Sent: Wednesday, January 25, 2012 12:14 PM

To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net, chr...@iswix.com

Subject: RE: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec


Are these problems in 3.5 or 3.6? Last year I discovered a defect in DTF

wherein a race condition upon completion of a DTF custom action call would

cause a failure return to Windows Installer, even when the managed code

custom action itself returned success. That was fixed in 3.6, but the bug

remains in 3.5. The race condition is in the native wrapper code. It tends

to manifest only when there is a heavy load (either CPU or disk) in the

machine at the moment that the custom action is completing, and thus was

very difficult to reproduce (I was fortunate enough to have exactly one 
box

that reproduced it with any (but still uncertain) regularity, out of 
dozens

of other boxes that would never reproduce it).


You can take the SfxCA.dll files from recent builds of 3.6 and use them 
with

3.5's RTM build to get that race condition fix and an unrelated memory 
leak

fix. I don't remember the bug numbers, but I do remember the investigation

and fix of the race condition.


I don't know what would cause the QuietExec issue, however.


-Blair


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

2012-01-25 Thread Neil Sleightholm
As Chris said excellent information. Mine problem was with 3.5 and this ties in 
with what I was seeing; on my VMs running on an i7 host I never saw the problem 
but the tester often got it on his lower powered host. He need move to a VM on 
an ESX host and the problem largely went away. I think I will try the newer 
SfxCA.dll (or I might just go for 3.6).

Thanks

Neil

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: 25 January 2012 18:14
To: 'General discussion for Windows Installer XML toolset.'; chr...@iswix.com
Subject: Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

Are these problems in 3.5 or 3.6? Last year I discovered a defect in DTF 
wherein a race condition upon completion of a DTF custom action call would 
cause a failure return to Windows Installer, even when the managed code custom 
action itself returned success. That was fixed in 3.6, but the bug remains in 
3.5. The race condition is in the native wrapper code. It tends to manifest 
only when there is a heavy load (either CPU or disk) in the machine at the 
moment that the custom action is completing, and thus was very difficult to 
reproduce (I was fortunate enough to have exactly one box that reproduced it 
with any (but still uncertain) regularity, out of dozens of other boxes that 
would never reproduce it).

You can take the SfxCA.dll files from recent builds of 3.6 and use them with 
3.5's RTM build to get that race condition fix and an unrelated memory leak 
fix. I don't remember the bug numbers, but I do remember the investigation and 
fix of the race condition.

I don't know what would cause the QuietExec issue, however.

-Blair


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn - ExePackage that depends on many files

2012-01-25 Thread Romeo S.
I tried creating a payload for the dependency files. I just can't figure out
how to store them in the correct subdirectory. It seems they are all stored
in the same directory as the setup.exe

[My3rdPartyInstaller] 
|..[1033_XXX_XX] 
|.[] 
|..[directory1] 
|.[] 
|..[directory2] 
|.[] 
|..[directoryN] 
|..setup.exe 

How can I extract them in their respective place e.g [directory1]

Thanks,
Romeo

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ExePackage-that-depends-on-many-files-tp7205293p7224919.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

2012-01-25 Thread Christopher Painter
I'm going to be creating a trojan installer that serves as a health check 
and deploying it daily to 2200 machines.  I'll be able to stress test the 
fix made in 3.6 and see what happen.s



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

Sent: Wednesday, January 25, 2012 1:06 PM

To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com

Subject: RE: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec


As Chris said excellent information. Mine problem was with 3.5 and this 
ties in with what I was seeing; on my VMs running on an i7 host I never saw 
the problem but the tester often got it on his lower powered host. He need 
move to a VM on an ESX host and the problem largely went away. I think I 
will try the newer SfxCA.dll (or I might just go for 3.6).


Thanks


Neil


-Original Message-

From: Blair [mailto:os...@live.com] 

Sent: 25 January 2012 18:14

To: 'General discussion for Windows Installer XML toolset.'; 
chr...@iswix.com

Subject: Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec


Are these problems in 3.5 or 3.6? Last year I discovered a defect in DTF 
wherein a race condition upon completion of a DTF custom action call would 
cause a failure return to Windows Installer, even when the managed code 
custom action itself returned success. That was fixed in 3.6, but the bug 
remains in 3.5. The race condition is in the native wrapper code. It tends 
to manifest only when there is a heavy load (either CPU or disk) in the 
machine at the moment that the custom action is completing, and thus was 
very difficult to reproduce (I was fortunate enough to have exactly one box 
that reproduced it with any (but still uncertain) regularity, out of dozens 
of other boxes that would never reproduce it).


You can take the SfxCA.dll files from recent builds of 3.6 and use them 
with 3.5's RTM build to get that race condition fix and an unrelated memory 
leak fix. I don't remember the bug numbers, but I do remember the 
investigation and fix of the race condition.


I don't know what would cause the QuietExec issue, however.


-Blair



--

Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers is 
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro 
Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn - ExePackage that depends on many files

2012-01-25 Thread Romeo S.
Nvm, I forgot to put the Name attribute.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ExePackage-that-depends-on-many-files-tp7205293p7224976.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Combining 32- and 64-bit installers

2012-01-25 Thread Malcolm D. McCrimmon
I'm working for a company that's currently overhauling its evaluation process, 
and one of the things we're trying to do is combine our 32- and 64-bit MSI 
installers into one package.  I saw that on stack overflow 
(http://stackoverflow.com/questions/1922259/how-to-implement-single-installer-for-32-64-platforms),
 this question had already been asked and the answer was not possible-that I 
would have to use a bootstrapper to combine the two MSI's.  That question was 
answered in 2009, though; has this changed since?

Thanks,
Malcolm
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Combining 32- and 64-bit installers

2012-01-25 Thread Dieter Lunn
No. MSI can only support one architecture per script as far as I know.
You still need a bootstrapper to launch the appropriate installer.

Dieter Lunn
http://ubiety.ca



On Wed, Jan 25, 2012 at 2:40 PM, Malcolm D. McCrimmon
malco...@windward.net wrote:
 I'm working for a company that's currently overhauling its evaluation 
 process, and one of the things we're trying to do is combine our 32- and 
 64-bit MSI installers into one package.  I saw that on stack overflow 
 (http://stackoverflow.com/questions/1922259/how-to-implement-single-installer-for-32-64-platforms),
  this question had already been asked and the answer was not possible-that 
 I would have to use a bootstrapper to combine the two MSI's.  That question 
 was answered in 2009, though; has this changed since?

 Thanks,
 Malcolm
 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Wix Bootstrapping Issues

2012-01-25 Thread Andrew Collier
I'm trying to build a bootstrapper msi but I'm running into issues: Does anyone 
know what I'm doing wrong?

 *Source:*

?xml version=1.0 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
 Bundle Name=MSI Bundle Version=1.0.0.0 Manufacturer=TEST 
UpgradeCode=9FDA14AC-7C26-42EF-A553-742B9D6C19F9 
 BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense 
/
 Chain
 MsiPackage Id=WSE SourceFile=C:\Users\acollier\Documents\WSE.msi 
Name=WSE 3.0/
 MsiPackage Id=Omnikey 
SourceFile=C:\Users\acollier\Documents\HID_OMNIKEY5x2x.msi Name=Omnikey5x2x 
Drivers/
 MsiPackage Id=TestApp SourceFile=C:\Users\acollier\Documents\test.msi 
Name=test application /
 /Chain
 /Bundle
/Wix

 *Command Prompt Error:*

C:\Program Files (x86)\Windows Installer XML v3.6\bincandle.exe C:\Users\acoll
ier\Documents\chain.wxs -ext WixBalExtension.dll
Microsoft (R) Windows Installer Xml Compiler version 3.6.2221.0
Copyright (C) Microsoft Corporation. All rights reserved.

chain.wxs

C:\Program Files (x86)\Windows Installer XML v3.6\binlight.exe C:\Users\acolli
er\Documents\chain.wixobj -ext WixBalExtension.dll
Microsoft (R) Windows Installer Xml Linker version 3.6.2221.0
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Users\acollier\Documents\chain.wixobj : error LGHT0104 : Not a valid object f
ile; detail: Root element is missing.


 Any Help would be appreciated
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Wix Bootstrapping Issues

2012-01-25 Thread Bob Arnson
On 25-Jan-12 17:50, Andrew Collier wrote:
 I'm trying to build a bootstrapper msi but I'm running into issues: Does 
 anyone know what I'm doing wrong?
Does it work if you use MSBuild? There's a bootstrapper project template 
for Visual Studio.

-- 
sig://boB
http://joyofsetup.com/


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Bundle registers itself as separate product and can't be removed - 3.6.2520 problem only

2012-01-25 Thread Bob Arnson
On 25-Jan-12 03:37, Peter Bulyaki wrote:
 One of the many requirements towards our installer is that
 the bundle installer itself should not be a separately installed product -
 only the MSIs.
See the Bundle element doc:

DisableRemove   YesNoType wix_xsd_simple_type_yesnotype.htm   Determines 
whether the bundle can be removed via the Programs and Features (also 
known as Add/Remove Programs). If the value is yes then the 
Uninstall button will not be displayed. The default is no which 
ensures there is an Uninstall button to remove the bundle. If the 
DisableModify attribute is also yes or button then the bundle will 
not be displayed in Progams and Features and another mechanism (such as 
registering as a related bundle addon) must be used to ensure the bundle 
can be removed.



 Our management wants that 1. and 2. should leave the target computer in
 exactly the same state (which means no bundle installed in ARP as a
 separate product).
Burn does not support that scenario.

 Users will have to uninstall each of the 7 products
 individually in both cases.
And that's the reason why: Burn prevents users from having to uninstall 
multiple packages by hand, instead of automating and handling 
dependencies and uninstall order.

-- 
sig://boB
http://joyofsetup.com/

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX - Issue with filenames that have two $$ in them.

2012-01-25 Thread Bob Arnson
On 25-Jan-12 11:46, Josh Suereth wrote:
 I'm trying to bundle up Scala's documentation using WIX.   Right now, the
 light program is exiting with error LIGHT0083 that it can't find the files
 I'm bundling.  I have a file named Utility$$Escape$.html and it's
 printing in the error message that its source path is Utility$Escape$.html
Oops. Yeah, please open a bug on SourceForge.

-- 
sig://boB
http://joyofsetup.com/


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn: patch for bundle

2012-01-25 Thread Bob Arnson
On 25-Jan-12 04:15, Vadym Verba wrote:
 Here is usecase: I have old v1.0 bundle installed and new patch bundle with
 patches only (totally new bundle with new upgrade code or with the same
 one?).

You'll have to do some additional work to associate the bundles. I 
haven't done it, so I'm not sure of the exact procedure, but see the doc 
for the RelatedBundle element.

-- 
sig://boB
http://joyofsetup.com/


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Signing the burn bootstrapper

2012-01-25 Thread Bob Arnson
On 24-Jan-12 15:09, Paul Fazio wrote:
 However, when I attempt to install I get the following error: Setup 
 failed while installing the MSIs. Unspecified error. 

Where? The Burn log will have additional details, like an error code.

-- 
sig://boB
http://joyofsetup.com/


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WIX - Issue with filenames that have two $$ in them.

2012-01-25 Thread Josh Suereth
Actually, I caught the pre-processor docs.  Replacing every $ with $$
works.  I just had to get my regex replacement correct.  Sorry for the bum
email.

- Josh

On Wed, Jan 25, 2012 at 9:36 PM, Bob Arnson b...@joyofsetup.com wrote:

 On 25-Jan-12 11:46, Josh Suereth wrote:
  I'm trying to bundle up Scala's documentation using WIX.   Right now, the
  light program is exiting with error LIGHT0083 that it can't find the
 files
  I'm bundling.  I have a file named Utility$$Escape$.html and it's
  printing in the error message that its source path is
 Utility$Escape$.html
 Oops. Yeah, please open a bug on SourceForge.

 --
 sig://boB
 http://joyofsetup.com/



 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

2012-01-25 Thread Blair
Except for that one repeatable machine, the problem always went away upon
retry (the same behavior you all have reported). That one machine was able
to repro more than once in a row, and after about four days I even got it to
repro in the debugger. That's when I finally discovered exactly what was
happening, and then I was able to stage a repro at will.

I submitted the fix to WiX, and a couple of weeks later walked another team
through their attempts to verify the fix.

Blair

-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com] 
Sent: Wednesday, January 25, 2012 11:57 AM
To: Neil Sleightholm; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec

I'm going to be creating a trojan installer that serves as a health check
and deploying it daily to 2200 machines.  I'll be able to stress test the
fix made in 3.6 and see what happen.s



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

Sent: Wednesday, January 25, 2012 1:06 PM

To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com

Subject: RE: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec


As Chris said excellent information. Mine problem was with 3.5 and this ties
in with what I was seeing; on my VMs running on an i7 host I never saw the
problem but the tester often got it on his lower powered host. He need move
to a VM on an ESX host and the problem largely went away. I think I will try
the newer SfxCA.dll (or I might just go for 3.6).


Thanks


Neil


-Original Message-

From: Blair [mailto:os...@live.com] 

Sent: 25 January 2012 18:14

To: 'General discussion for Windows Installer XML toolset.';
chr...@iswix.com

Subject: Re: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec


Are these problems in 3.5 or 3.6? Last year I discovered a defect in DTF
wherein a race condition upon completion of a DTF custom action call would
cause a failure return to Windows Installer, even when the managed code
custom action itself returned success. That was fixed in 3.6, but the bug
remains in 3.5. The race condition is in the native wrapper code. It tends
to manifest only when there is a heavy load (either CPU or disk) in the
machine at the moment that the custom action is completing, and thus was
very difficult to reproduce (I was fortunate enough to have exactly one box
that reproduced it with any (but still uncertain) regularity, out of dozens
of other boxes that would never reproduce it).


You can take the SfxCA.dll files from recent builds of 3.6 and use them with
3.5's RTM build to get that race condition fix and an unrelated memory leak
fix. I don't remember the bug numbers, but I do remember the investigation
and fix of the race condition.


I don't know what would cause the QuietExec issue, however.


-Blair



--

Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn Protocols

2012-01-25 Thread Romeo S.
Hi,

I'm just curious what can burn and netfx protocols supports? I need to
install SQLServer Express with my bundle I would like to see the progress
bar moves while it is installing instead of installing in the background. It
may look like that the installer hangs and doing nothing.

Tried both protocols and neither works so I would like to know what they
support.

Thanks,
Romeo

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

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users