from:"John Ludlow"

Re: [WiX-users] When is Wix 3.10 publicly available ?

2015-06-23 Thread John Ludlow

See these blog posts. Both of these have a note about progress on 3.10

https://www.firegiant.com/blog/2015/6/2/wix-online-meeting-68-highlights/
https://www.firegiant.com/blog/2015/6/16/wix-online-meeting-70-highlights/


On 22 June 2015 at 17:55, Rob Mensching r...@firegiant.com wrote:

 PS: WiX v3.10 is available now: http://wixtoolset.org/releases/

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

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: Monday, June 22, 2015 5:07 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] When is Wix 3.10 publicly available ?

 Those issues are discussed in the weekly on-line meeting, Tuesday evening,
 and summarized in this  blog 
 https://www.firegiant.com/blog/2015/6/16/wix-online-meeting-70-highlights/
 
 .  If I recall from the comments in the last meeting, the 'RC' will be
 announced soon.  The stable release is expected to wait until after the
 Microsoft release of VS2015 is completed.  Subsequently it is likely that
 there will be 'service releases' of 3.10.n rather than a focus on a 3.11 (or
 3.1x) and a focus on the 4.x efforts.  But those are issues which are
 discussed in the weekly meeting on, Tuesday evening, and I think all are
 welcome to participate.


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] using a custom action to read properties from a XML file

2015-02-28 Thread John Ludlow

And a slightly more recent one:

http://www.wrightfully.com/part-1-of-writing-your-own-net-based-installer-with-wix-overview/

On 28 February 2015 at 12:09, John Ludlow john.ludlow...@gmail.com wrote:

 Here's some links to articles about managed BAs:


 http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx


 http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

 Personally, I think that might be overcomplicating it slightly.

 On 28 February 2015 at 00:22, Davis, Jeff jda...@nanometrics.com wrote:

 What does use Burn and a managed BA  mean?   What would that look like?



 Jeff


 -Original Message-
 From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
 Sent: Friday, February 27, 2015 9:30 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from a
 XML file

 Or use Burn and a managed BA, where you can do it without a CA and pass
 it as a property to the MSI.

 -Original Message-
 From: Davis, Jeff [mailto:jda...@nanometrics.com]
 Sent: Friday, February 27, 2015 11:07 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from a
 XML file

 Jeremiahf,

 I like your approach.  I'll write the C# code to do what I want it to do
 and then figure out how to make it a CA.  Instead of trying to write a CA
 to do what I want.

 Jeff


 -Original Message-
 From: Jeremiahf [mailto:jeremi...@gmail.com]
 Sent: Thursday, February 26, 2015 6:49 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from a
 XML file

 I've had to do this before. My method was to create an application to
 read/modify an XML file. Then took my code and turned it into a CA. Saved a
 lot of headache trying to debug what was going on. Also as John stated,
 scheduled the CA to execute first.

 J

 On Thu, Feb 26, 2015 at 5:37 PM, John Cooper jocoo...@jackhenry.com
 wrote:

  Ok, so, you'll need to run in the UI Sequence pretty early.
 
  Question, how does Va'lue set MAC_ID?  Normally, I would expect
 Value
  to be replaced by MAC_ID.
 
  You'll need to add an
 
  InstallUISequence
 
  Element with a Custom Action=your XML setter entry point here
  Before=LaunchConditions /
 
  What does your entry point look like?
 
  --
  John Merryweather Cooper
  Senior Software Engineer | Integration Development Group | Continuing
  Development Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:
  431050 | jocoo...@jackhenry.com
 
  -Original Message-
  From: Davis, Jeff [mailto:jda...@nanometrics.com]
  Sent: Thursday, February 26, 2015 5:27 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] using a custom action to read properties from
  a XML file
 
  I have custom UI dialog that has a Text control that has the variable.
  When the MSI runs it should populate that field with the data read
  from the XML.
 
  Control Type=MaskedEdit Id=MacID Width=270 Height=15
  X=52 Y=184 Property=MAC_ID  Text=[MACIDTemplate]   /
  Control Type=Text Id=MacIDLabel Width=36 Height=10
 X=11
  Y=188 Text=MAC ID /
 
 
 
  -Original Message-
  From: John Cooper [mailto:jocoo...@jackhenry.com]
  Sent: Thursday, February 26, 2015 3:08 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] using a custom action to read properties from
  a XML file
 
  Well, which sequence is the custom action running?  UI or Execute?  If
  in the execute sequence, only public secure properties (properties in
  all upper case with a Secure=yes attribute) will be visible in the
  UI sequence.  If in the UI sequence, are you firing this from a button,
 or is
  it just scheduled?   If from a button, you're not going to get any
  logging.  Try scheduling in directly in UI so you can get some logging.
 
  --
  John Merryweather Cooper
  Senior Software Engineer | Integration Development Group | Continuing
  Development Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:
  431050 |jocoo...@jackhenry.com
 
  -Original Message-
  From: Davis, Jeff [mailto:jda...@nanometrics.com]
  Sent: Thursday, February 26, 2015 4:54 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] using a custom action to read properties from
  a XML file
 
  Nothing happens.   The value does not get populated in the UI.  It still
  shows the default value of 0.
 
  But I am really just coding in the dark on this.  I'm not sure what I am
  doing and not even sure I have everything correct.   I just don't get
 the
  whole custom action concept and how properties get read and set?
 
  This was just a stab at what I thought would work.
 
  Jeff
 
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Thursday, February 26, 2015 2:33 PM
  To: General discussion about the WiX toolset

Re: [WiX-users] using a custom action to read properties from a XML file

2015-02-28 Thread John Ludlow

Here's some links to articles about managed BAs:

http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

Personally, I think that might be overcomplicating it slightly.

On 28 February 2015 at 00:22, Davis, Jeff jda...@nanometrics.com wrote:

What does use Burn and a managed BA mean? What would that look like?

Jeff

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, February 27, 2015 9:30 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from a
XML file

Or use Burn and a managed BA, where you can do it without a CA and pass it
as a property to the MSI.

-Original Message-
From: Davis, Jeff [mailto:jda...@nanometrics.com]
Sent: Friday, February 27, 2015 11:07 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from a
XML file

Jeremiahf,

I like your approach. I'll write the C# code to do what I want it to do
and then figure out how to make it a CA. Instead of trying to write a CA
to do what I want.

Jeff

-Original Message-
From: Jeremiahf [mailto:jeremi...@gmail.com]
Sent: Thursday, February 26, 2015 6:49 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from a
XML file

I've had to do this before. My method was to create an application to
read/modify an XML file. Then took my code and turned it into a CA. Saved a
lot of headache trying to debug what was going on. Also as John stated,
scheduled the CA to execute first.

On Thu, Feb 26, 2015 at 5:37 PM, John Cooper jocoo...@jackhenry.com
wrote:

Ok, so, you'll need to run in the UI Sequence pretty early.

Question, how does Va'lue set MAC_ID? Normally, I would expect Value
to be replaced by MAC_ID.

You'll need to add an

InstallUISequence

Element with a Custom Action=your XML setter entry point here
Before=LaunchConditions /

What does your entry point look like?

-Original Message-
From: Davis, Jeff [mailto:jda...@nanometrics.com]
Sent: Thursday, February 26, 2015 5:27 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from
a XML file

I have custom UI dialog that has a Text control that has the variable.
When the MSI runs it should populate that field with the data read
from the XML.

Control Type=MaskedEdit Id=MacID Width=270 Height=15
X=52 Y=184 Property=MAC_ID Text=[MACIDTemplate] /
Control Type=Text Id=MacIDLabel Width=36 Height=10
X=11
Y=188 Text=MAC ID /

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Thursday, February 26, 2015 3:08 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from
a XML file

Well, which sequence is the custom action running? UI or Execute? If
in the execute sequence, only public secure properties (properties in
all upper case with a Secure=yes attribute) will be visible in the
UI sequence. If in the UI sequence, are you firing this from a button,
or is
it just scheduled? If from a button, you're not going to get any
logging. Try scheduling in directly in UI so you can get some logging.

-Original Message-
From: Davis, Jeff [mailto:jda...@nanometrics.com]
Sent: Thursday, February 26, 2015 4:54 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from
a XML file

Nothing happens. The value does not get populated in the UI. It still
shows the default value of 0.

But I am really just coding in the dark on this. I'm not sure what I am
doing and not even sure I have everything correct. I just don't get the
whole custom action concept and how properties get read and set?

This was just a stab at what I thought would work.

Jeff

-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Thursday, February 26, 2015 2:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from
a XML file

When you say not working, what do you mean exactly? Is it just not
calling your CA, not finding the file, not getting

Re: [WiX-users] using a custom action to read properties from a XML file

2015-02-26 Thread John Ludlow

When you say not working, what do you mean exactly? Is it just not
calling your CA, not finding the file, not getting any results, or is it
throwing an exception?

Here are some things you can try:

Check whether there any evidence in the log that the custom action has been
called, and what the CustomActionData is. Also, put a few session.Log calls
in strategic places in the code to see where it's getting to.

Try writing similar code in a console application and seeing whether it can
load the XML file

And of course, the real way :
http://blog.torresdal.net/2008/10/26/wix-and-dtf-debug-a-managed-custom-action-and-how-to-generate-an-msi-log/

Here are some possible theories:

If the custom action data is what you have there, I would suggest that the
relative path isn't being evaluated from where you think it would be - you
may need to use a property to build up a full path to the file.

Is it possible that the XML file has a namespace? If the document has a
namespace and you don't handle that in your code (both in the C# and in the
XPath) you won't get any results.

Hope that helps

John

On 26 February 2015 at 21:32, Davis, Jeff jda...@nanometrics.com wrote:

 I am having a heck of time trying get my mind wrapped around the way to
 create and use a custom action in my C# Wix Project in Visual Studio 2013.

 I want to be able to open a specified XML file and return an attribute
 from a specified key and then use that to initialized a property in the
 installer and display it in the dialog.  Then when installer is run it will
 write the value to a target XML file to the same key and attribute.   In My
 case I have a MAC_ID  Property that is in a UI text box that I want to
 initialize from a XML file attribute and then write to a new XML file
 during the install.   The write is pretty straightforward since it is built
 into WIx.  But I can't get the read working.

 I created this Custom Action

 public class CustomActions
 {
 [CustomAction]
 public static ActionResult ReadXmlValue(Session session)
 {
 string fileName = session.CustomActionData[FileName];
 string xmlnode = session.CustomActionData[Node];
 string key = session.CustomActionData[Key];

 XmlDocument xmlDoc = new XmlDocument();
 xmlDoc.Load(fileName);
 if (xmlDoc.DocumentElement != null)
 {
 XmlNodeList nodeList =
 xmlDoc.DocumentElement.SelectNodes(xmlnode);

 if (nodeList != null)
 foreach (XmlNode node in nodeList)
 {
 var selectSingleNode = node.SelectSingleNode(key);
 if (selectSingleNode != null) session[Value] =
 selectSingleNode.InnerText;
 }
 }

 return ActionResult.Success;
 }
 }


 My WXS script looks like this


Property Id=MAC_ID Secure=yes Value=0/
 Property Id=MACIDTemplate
   ![CDATA[-]]
 /Property

 CustomAction Id=myActionId BinaryKey=myAction
 DllEntry=ReadXMLValue Execute=deferred Return=check /
 CustomAction Id=SetCustomActionDataValue Return=check
 Property=myActionId Value=FileName='.\FilesToInstall\Program
 Files\Zygo\MetroProX\cfg\NewView.IC.xml';Node='\Settings\Section\Section\Section\add';Key='Mac'
 /
 CustomAction Id=ReadXMLValue Property=Value Value=[MAC_ID] /

 InstallExecuteSequence
   Custom Action=SetCustomActionDataValue Before=myActionIdNOT
 Installed/Custom
   Custom Action=myActionId Before=InstallFinalizeNOT
 Installed/Custom
 /InstallExecuteSequence


 But I don't think I have this setup right?


 Jeff Davis

 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] using a custom action to read properties from a XML file

2015-02-26 Thread John Ludlow

Sorry, I missed the mixed use of CustomActionData and session properties

Immediate custom action is what I am trying to do. I have no need for it
to be deferred.

Ok, firstly, there is Execute=deferred on your myActionId action.

Secondly, in your action code you are getting CustomActionData, which is
only available for custom actions. Try changing your C# like so:

string fileName = session[FILENAME];
string xmlnode = session[NODE];
string key = session[KEY];

And your WXS like so:

CustomAction Id=myActionId BinaryKey=myAction
DllEntry=ReadXMLValue Execute=immediate Return=check /
CustomAction Id=set_FILE Property=FILE Value=... /
CustomAction Id=set_NODE Property=FILE Value=... /
CustomAction Id=set_KEY Property=FILE Value=... /

(obviously, with the correct values and sequence entries)

I do have one question:

Is the file you are trying to access one that you install, or one that is
expected to already be on the system? If you're installing it then you
either need to make your action deferred, put the action after
InstallFinalize, or schedule an InstallExecute somewhere, since an
immediate action is not normally guaranteed to run after InstallFiles
without one of these measures.

I would recommend getting a book like this one:
https://www.packtpub.com/application-development/wix-36-developers-guide-windows-installer-xml.
It covers this stuff in some detail.

On 26 February 2015 at 23:08, John Cooper jocoo...@jackhenry.com wrote:

Well, which sequence is the custom action running? UI or Execute? If in
the execute sequence, only public secure properties (properties in all
upper case with a Secure=yes attribute) will be visible in the UI
sequence. If in the UI sequence, are you firing this from a button, or is
it just scheduled? If from a button, you're not going to get any
logging. Try scheduling in directly in UI so you can get some logging.

Nothing happens. The value does not get populated in the UI. It still
shows the default value of 0.

This was just a stab at what I thought would work.

Jeff

When you say not working, what do you mean exactly? Is it just not
calling your CA, not finding the file, not getting any results, or is it
throwing an exception?

Here are some things you can try:

Check whether there any evidence in the log that the custom action has
been called, and what the CustomActionData is. Also, put a few session.Log
calls in strategic places in the code to see where it's getting to.

Try writing similar code in a console application and seeing whether it
can load the XML file

And of course, the real way :

http://blog.torresdal.net/2008/10/26/wix-and-dtf-debug-a-managed-custom-action-and-how-to-generate-an-msi-log/

Here are some possible theories:

If the custom action data is what you have there, I would suggest that the
relative path isn't being evaluated from where you think it would be - you
may need to use a property to build up a full path to the file.

Is it possible that the XML file has a namespace? If the document has a
namespace and you don't handle that in your code (both in the C# and in the
XPath) you won't get any results.

Hope that helps

John

On 26 February 2015 at 21:32, Davis, Jeff jda...@nanometrics.com wrote:

I am having a heck of time trying get my mind wrapped around the way
to create and use a custom action in my C# Wix Project in Visual Studio
2013.

I want to be able to open a specified XML file and return an attribute
from a specified key and then use that to initialized a property in
the installer and display it in the dialog. Then when installer is run
it will
write the value to a target XML file to the same key and attribute. In
My
case I have a MAC_ID Property that is in a UI text box that I want to
initialize from a XML file attribute and then write to a new XML file
during the install. The write is pretty straightforward since it is
built
into WIx. But I can't get the read working.

I created

Re: [WiX-users] WiX 3.9 R2 - Debugging WPF Burn Application

2015-01-31 Thread John Ludlow

We have the following code in our Run method:

#ifdef DEBUG
Debugger.Launch();
#endif

When we compile as debug and then run the bundle, we get a prompt to attach
a debugger from this Debugger.Launch() call. On the dev box (with Visual
Studio installed) this would normally be a list of open Visual Studio
instances - we simply choose the one that has the correct solution open,
and we can debug. When debugging remotely, the prompt is different - it's a
Retry/Cancel prompt. We make sure we have the remote debug monitor
installed, select Retry and then choose to Attach Process in the correct
instance of Visual Studio on our dev box. Then we enter the machine IP and
connection credentials and we can debug.

On 31 January 2015 at 20:11, Phill Hogland phogl...@rimage.com wrote:

To debug my WPF BA, I just build all projects against the installed
released
wix 3.9 RTM (or 3.9 R2 installed). Then I go back to my WPF project and
enable debug/trace in project properties, add a Debugger.Launch() line to
the code of interest, and set the start path to point at the bundle exe.
Then compile the WPF project and the bundle again. Then right-click on the
WPF project (in VS) select Debug instance.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-9-R2-Debugging-WPF-Burn-Application-tp7599102p7599103.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is
your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bundle within a bundle

2014-10-07 Thread John Ludlow

I saw some install failures when I tried this but this may have been down
to some incorrect handling in my custom BA. I haven't tried this with a
package based on the WixStdBA

You will also get the child package listed as an entry in the ARP because
there's no way for the parent bundle to tell the child bundle to hide
itself. (http://wixtoolset.org/issues/4454/)

On 7 October 2014 14:27, Kevin Parkes kevin.par...@wacom.eu wrote:

 I know it's possible to have one bundle as an ExePackage within a second
 bundle, but is it a good idea? Any gotchas or downside?

 Thanks




 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-within-a-bundle-tp7597164.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Removing bundle from ARP

2014-10-03 Thread John Ludlow

Do you mean that if you install the bundle, then uninstall the packages
individually (not using the bundle) then the bundle is still registered?

If so, that's expected, and no there's no action in the bundle that gets
invoked if you uninstall each package outside the bundle.

On 3 October 2014 14:51, vorsichtdiekurve mp.mateusz.polan...@gmail.com
wrote:

 Hi there,
 I somehow managed to write my own managed bootstrapper application.
 It seems to work correctly. The chained packages install/uninstall in the
 desired way.
 However, the bundle itself remains registered in ARP even when all the
 related packages have been removed.
 Is there a burn engine action/method/whatever i could invoke to unregister
 the bundle and possibly also remove unnecessary registry entries for it?
 Shouldn't it automatically unregister when all of the chained packages are
 absent on the machine?
 Thnaks in advance for any help.
 Mateusz



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


 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] What does '' and '!' inside CDATA[] do?

2014-05-13 Thread John Ludlow

Pay attention to when these actions are sequenced. In particular, as the
linked article mentions, any action that relies on these conditions should
be sequenced after CostFinalize.


On 13 May 2014 23:03, b.ras...@leonit.nl wrote:

 Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar
 basti...@careercontrol.nl.




 --
 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

--
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

[WiX-users] Relative path sometimes used for WiX extension references.

2014-04-11 Thread John Ludlow

Hi,

When I add a reference to WixUtilExtension in my WiX project, this is what
gets added to the .wixproj:

ItemGroup
   WixExtension Include=WixUtilExtension
  HintPath$(WixExtDir)\WixUtilExtension.dll/HintPath
  NameWixUtilExtension/Name
   /WixExtension
/ItemGroup

When my colleague does this, he sometimes gets the above, but usually gets
this:

ItemGroup
  WixExtension Include=WixUtilExtension
HintPath
..\..\..\..\..\..\..\..\..\..\..\..\..\Program Files (x86)\WiX Toolset
v3.8\bin\WixUtilExtension.dll
/HintPath
NameWixUtilExtension/Name
  /WixExtension
/ItemGroup

Which causes an error for me. Although we both have WiX 3.8 installed to
the default location (c:\Program Files (x86)\WiX Toolset v3.8) I have all
my source on a different drive, so that's where the relative path starts
from. Since there's no way that a relative path will ever be able to
reference a file on a different drive, it fails on my machine.

My colleague is having to check his project changes carefully to make sure
he doesn't accidentally break it, and we think the tools could help us
more. I'm pretty sure that in his case Votive is thinking aha, I can draw
a relative path from here to there! and just using that, while in my case
it's deciding it can't possibly do that so it's falling back on whatever
$(var.WixExtDir) tells it to do.

I found a bug (http://sourceforge.net/p/wix/bugs/2209/) on SourceForge, but
though it says migrated I was unable to find a bug on the new bug
tracking system. The closest I could find was this one :
http://wixtoolset.org/issues/2834/ but that's a totally separate issue. I
wonder if 2209 got lost along the way from SF to the new system. Should I
create it in the new system?

In terms of a fix, I feel like it should always use $(WixExtDir) regardless
of whether a relative path *could* be used.

Meanwhile, we have to decide how to handle it on our side until it's fixed.
We have tools that we could use to check this for us, but that's less than
ideal. We could also do what this guy does :
http://wixtoolset.org/issues/2834/ and keep our WiX toolset in source
control but for various reasons we didn't want to do that.

Any ideas?

Thanks
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Custom Actions - Renaming Functions

2014-03-19 Thread John Ludlow

This may be a silly question, but have you also cleared out your temp
directories? Also, did you

I think it should be possible to export the DLL using Orca to a file on
disk, and then examine it to see what exported functions it has (say, with
Dependency Walker). This should settle the question of whether it's the
exported function that's the issue or something else.


On 19 March 2014 22:07, Levi Wilson l...@leviwilson.com wrote:

 Yes, I actually started by using ReSharper to rename my CA method, as I
 have unit tests around all of them. After that I updated all of my wxs
 files so that they are correct. I backed out the changes for now, but I can
 try it again later to see what the full log is. I may be able to put
 together a sample app to illustrate it on GitHub or something.

 Thanks,

 Levi


 On Wed, Mar 19, 2014 at 6:00 PM, Hoover, Jacob
 jacob.hoo...@greenheck.comwrote:

  I assume you've also modified your C# CustomAction to include the updated
  name and rebuilt it?  Do you have a full log available (or at least some
 of
  the lines before that where the CA is being extracted).  If need be, one
  could peek into the temp file after extraction and ensure it's using the
  updated assembly.
 
  -Original Message-
  From: Levi Wilson [mailto:l...@leviwilson.com]
  Sent: Wednesday, March 19, 2014 4:53 PM
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] C# Custom Actions - Renaming Functions
 
  Is it me, or is it impossible to rename a C# custom action function once
  you've built it?
 
  My wxs files are correct to reflect the new name. I have verified that
 the
  binary file that is in there has the newly named method after I build it
 (I
  saved it from Orca and did `dumpbin saved.dll /EXPORTS` to see it).
  However, when I go to run the install I get:
 
  Error 1723. There is a problem with this Windows Installer package. A DLL
  required for this install to complete could not be run. Contact your
  support personnel or package vendor.  Action ValidateSQLAdminCredentials,
  entry: ValidateSQLAdminCredentials, library:
  C:\Users\VMWARE~1\AppData\Local\Temp\MSI8F83.tmp
 
  The one that is reflected isn't even the one that I renamed, but that
  would be the first time it tried to load my DLL.
 
  I've cleared out my bin and obj directories in my CA project as well as
 my
  installer project.
 
  What am I missing or where can I look to help troubleshoot? I'm using Wix
  3.8
 
 
 --
  Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is
  the definitive new guide to graph databases and their applications.
 Written
  by three acclaimed leaders in the field, this first edition is now
  available. Download your free book today!
  http://p.sf.net/sfu/13534_NeoTech
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 --
  Learn Graph Databases - Download FREE O'Reilly Book
  Graph Databases is the definitive new guide to graph databases and
 their
  applications. Written by three acclaimed leaders in the field,
  this first edition is now available. Download your free book today!
  http://p.sf.net/sfu/13534_NeoTech
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] uI on silent uninstall

2014-03-19 Thread John Ludlow

That's probably because the MSI is running in the just-a-progress-bar mode
during uninstall. MSI message boxes are being suppressed.


On 19 March 2014 22:56, Pavan Konduru pavan.kond...@accelrys.com wrote:

 Did you declare the custom action in the .wxs file?

 -Original Message-
 From: Harold Wood (H10 Capital) [mailto:v-wow...@microsoft.com]
 Sent: Wednesday, March 19, 2014 3:29 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] uI on silent uninstall

 I did that and it didn't work.

 -Original Message-
 From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
 Sent: Wednesday, March 19, 2014 3:20 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] uI on silent uninstall

 Make the condition REMOVE=ALL

 -Original Message-
 From: Harold Wood (H10 Capital) [mailto:v-wow...@microsoft.com]
 Sent: Wednesday, March 19, 2014 2:49 PM
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] uI on silent uninstall

 Ok this is what I have so far:

 Product.wxs


   !--Display the uninstall message box so user is informed we will
 not remove the databases--
   Custom Action =UninstallMessage
 After=InstallFinalizeRemove/Custom
   Custom Action =UninstallMessage.Show
  After=UninstallMessageRemove/Custom

 CustomAction.cs

 [CustomAction]
   public static ActionResult UninstallMessage(Session session)
   {
   if (session == null)
   {

 logEventsApp.WriteLoggingEvent(string.Format(CultureInfo.InvariantCulture,
 {0} ; {1}, Resources.ArgumentNullError, session), session);
   throw new ArgumentNullException(session,
 Resources.ArgumentNullError);
   }

   // This is just to display a message box that informs the user
 that they will have to remove the databases manually
   StringBuilder notificationMessage = new StringBuilder(The
 actual databases will not be removed from the server by this.);
   notificationMessage.Append(\r\n\r\n);
   notificationMessage.Append(You will have to manually remove the
 Databases from your server.);

   Record record = new Record();
   record.FormatString = notificationMessage.ToString();
   MessageResult value = session.Message(InstallMessage.Info |
 (InstallMessage)MessageIcon.Warning | (InstallMessage)MessageButtons.OK,
 record);

   return ActionResult.Success;
   }

 And im still not getting the message box.  So what am I doing wrong?

 Thanks

 Woody

 --
 Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is
 the definitive new guide to graph databases and their applications. Written
 by three acclaimed leaders in the field, this first edition is now
 available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




 --
 Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is
 the definitive new guide to graph databases and their applications. Written
 by three acclaimed leaders in the field, this first edition is now
 available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is
 the definitive new guide to graph databases and their applications. Written
 by three acclaimed leaders in the field, this first edition is now
 available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download

Re: [WiX-users] WiX Queries

2014-03-18 Thread John Ludlow

With regard to creating bootstrapper applications, the official
documentation is a little lacking but here are some resources which may
help:

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx

http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book (no
it's not free but it's worth the asking price and Chapter 16 covers managed
bootstrapper applications)

If you just want to be able to specify the log location on the command
line, I believe there is an argument for that. By default (I'm not even
sure if there's an option to change this) each package will get a log, and
they're all pretty well named based on the package ID so it's pretty
obvious what log relates to which package.

On 18 March 2014 22:49, Rob Mensching r...@firegiant.com wrote:

1. Yes. You can handle disk switching in the source resolution callback
from the engine.

2. Use same UpgradeCode for upgrading Bundles and make sure newer versions
have higher versions.

3. Yes, via the various Execute callbacks.

4. You can definitely read the Variable that contains the log file for the
MSI. I've never tried but you may be able to set it after Plan() but before
Apply() and have it write to a custom location. If not, I'm certain you can
copy/move the logs at the end of the install.

5. We always appreciate contributions to the documentation. Currently, the
source code in the WiX toolset itself provides a lot of guidance.

6. Yes, in the ExecutePackageComplete (or something close to that name)
callback. You can also get all the intermediate messages from Windows
Installer via MsiExecuteMessage (or something close to that name) callback.

7. Wixstdba expects themes to be embedded into the Bundle so updating a
theme requires rebuilding the bundle when using wixstdba.

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

-Original Message-
From: Deepak Malik [mailto:deepak.ma...@microsoft.com]
Sent: Tuesday, March 18, 2014 3:17 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX Queries

Hi Team,

Could you please help me answer these to them.

Wix Burn (General):

We will have different MSI's spread out across multiple DVD's. For
example, we'll have a Disk1 which contains an MSI for some base features.
Disk2 will contains MSI's that add additional specialized product
features. Disk3 MSI's will add even more specialized product features. Is
it possible to create a Chain that references different DVD's? If so,
how? We do not want the bootstrapper application to embed the MSI's.

How does Wix Burn handle upgrades? What information, if any, would the
Bundle need to include in order to handle upgrades? If creating a
managed custom bootstrapper, what do we have to implement to handle
upgrades?

Does Burn automatically roll back Install1 if Install2 fails? Do we get
to control this? If so, where?

We would like to generate MSI log files for each MSI run in our Chain.
Is it possible to specify where these files go? How?

Wix Burn (Custom Managed Bootsrapper App)

We need solid documentation/examples of managed bootstrapper working with
Wix burn. Documentation is sparse to say the least...

Is it possible to capture the exit code of an MSI in the bootstrapper
application? If so, how?

Wix Burn (Standard Bootstrapper Application)

http://wixtoolset.org/documentation/manual/v3/bundle/wixstdba/wixstdba_customize.htmlshows
how to manipulate the predefined layouts. Is it possible to create
additional layouts and NOT have to recompile the application? For example
- we can imagine having screen1 display options for MSI1 and screen2
display options for MSI2. If MSI3 is introduced later which has its own
set of options, would we have to define a new layout and then rebuild the
entire bootstrapper app? Or is there a way to plug in the new layout at
the end without rebuilding?

Regards,
Deepak Malik

--
Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is
the definitive new guide to graph databases and their applications. Written
by three acclaimed leaders in the field, this first edition is now
available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the

Re: [WiX-users] ICE03 or Unresolved reference

2014-03-11 Thread John Ludlow

You would need to define the table schema using the CustomTable element.

Try using dark.exe on an msi which has thay merge modules and seeing what
CustomTable elements you get in the output.

Hope that helps
On 11 Mar 2014 02:15, Dmitry Nechaev 
dmitry.nech...@objectconsulting.com.au wrote:

 Hi All

 I started to work with WIX and got stack with weird behaviour of WIX 3.8
 for Visual Studio 2013.

 I'm trying to merge Crystal Reports msm module into the project as below:

 A File with Crystal Reports MSM:
 InstallExecuteSequence
   MsiPublishAssemblies Sequence=1502 /
   MsiUnpublishAssemblies Sequence=1501 /
 /InstallExecuteSequence

 AdvertiseExecuteSequence
   MsiPublishAssemblies Sequence=1502 /
 /AdvertiseExecuteSequence

 A file with assembly info:
 Feature Id=ProductFeature Title=SetupFARMS Level=1 
 ComponentGroupRef Id=FARMSBin.Components /
 /Feature

 Feature Id=CrystalReports Title=Crystal Reports Runtime
 Description=Crystal Reports Runtime Level=1
   MergeRef Id=CrystalReportsMSM /
 /Feature


 !-- To prevent ICE03 errors from the Crystal merge module --
 EnsureTable Id=Verb /
 ... twentish entries like these
 EnsureTable Id=ActionText /

 !--
 EnsureTable Id=SeagateIPService /
 EnsureTable Id=SeagateCondition /
 EnsureTable Id=HelpPlugin /
 EnsureTable Id=HelpFilter /
 EnsureTable Id=HelpFileToNamespace /
 EnsureTable Id=HelpFile /
 EnsureTable Id=Extention /
 EnsureTable Id=CrystalRedirection /
 EnsureTable Id=BOBJSourcePath /
 EnsureTable Id=BOBJMetabase /
 --

 When I compile the project as is, I get a lot of ICE03 errors:
 ICE03: Table: SeagateIPService Column: ServiceName Missing specifications
 in _Validation Table (or Old Database) ...\SetupFARMS.msi

 When I fix this with InsureTable I get opposite error:
 Unresolved reference to symbol 'WixCustomTable:SeagateIPService' in
 section 'Product:{C2C67BDE-89AA-4F6B-9773-73763856F023}'. ...\Assemble.wxs

 There is no way for me to fix ICE03 error for this MSM using InsureTable
 for the last dozen of tables commented out in the code above.

 Could someone help me with this please?

 The msm module I took from here:

 https://smpdl.sap-ag.de/~sapidp/01200252310634042010E/crxir2sp6_net_mm.zip


 Thanks everyone.

 Dmitry Nechaev

 EMAIL DISCLAIMER This email message and its attachments are confidential
 and may also contain copyright or privileged material. If you are not the
 intended recipient, you may not forward the email or disclose or use the
 information contained in it. If you have received this email message in
 error, please advise the sender immediately by replying to this email and
 delete the message and any associated attachments. Any views, opinions,
 conclusions, advice or statements expressed in this email message are those
 of the individual sender and should not be relied upon as the considered
 view, opinion, conclusions, advice or statement of this company except
 where the sender expressly, and with authority, states them to be the
 considered view, opinion, conclusions, advice or statement of this company.
 Every care is taken but we recommend that you scan any attachments for
 viruses.

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] if(language==en-US) logic?

2014-03-02 Thread John Ludlow

http://stackoverflow.com/questions/1805405/find-vista-language-using-wix

This SO question might be helpful
On 1 Mar 2014 10:15, Bin Yin ybdes...@gmail.com wrote:

 is there any logic in WiX as:

 if (OSLanguage==en-US)
 {
 copy file1 to dir1
 }
 else if(OSLanguage==zh-CN)
 {
 copy file2 to dir2
 }
 else if(OSLanguage==de-DE)
 {
 copy file3 to dir3
 }
 else
 {
 copy file4 to dir4
 }

 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] SQL Server 64 Bit

2014-02-26 Thread John Ludlow

No problemo :)


On 26 February 2014 13:17, Steven Ogilvie steven.ogil...@titus.com wrote:

 Ravi,

 Please provide verbose logging of where it is failing...

 http://support.microsoft.com/kb/223300

 The simplest way for logging a single session is to start the installer
 with the /l switch

   msiexec /i c:\path\to\myinstall.msi /l*v c:\path\to\myinstall.log
 (thanks John)

 Steve

 -Original Message-
 From: Ravishankar [mailto:ravishankar.krishnasw...@idsfortune.com]
 Sent: February-26-14 4:13 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] SQL Server 64 Bit

 Hi,
 I have a installer(msi) created on the development machine with the below
 specifications

 1.Win 7(64 bit)
 2.SQL Server 2008 R2 - SP2(32 Bit)
 3.VS 2010

 I have used the sql:SqlDatabase funcationality of creating Database and
 executing *.sql scripts, this works on the development machine perfectly

 Now am trying to install on a separate machine with below specs and it
 FAILS

 1.Win 2008 Server R2
 2.SQL Server 2008 R2 - SP2(64 Bit)
 3.(.NET framework 4.0)

 Its urgent and i need your help

 Thanks and Regards
 Ravi Shankar K



 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to not copy a file in subsequent installations?

2014-02-26 Thread John Ludlow

BTW, you did mention the scheduling in your original mail - I missed it. My
bad.


On 26 February 2014 15:39, John Ludlow john.ludlow...@gmail.com wrote:

 Aha!

 MSI (s) (00:64) [09:59:21:043]: File: C:\Program
 Files\WixWindowsService2012\WixWindowsService2012.exe.config;   To be
 installed;  Won't patch;No existing file
 MSI (s) (00:64) [09:59:21:043]: Source for file
 'WixWindowsService2012.exe.config' is compressed

 So why is there No existing file?

 Where do you have your RemoveExistingProducts action scheduled? I think
 what's happening is your REP is removing the file, then when your newer
 version comes along it finds the file missing so it install its copy.

 If possible, move RemoveExistingProducts later in the sequence.

 Check these links out:


 http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-major-msi-upgrade/
 http://msdn.microsoft.com/en-us/library/aa371197(v=vs.85).aspx


 On 26 February 2014 15:10, faujong fiefie.ni...@gmail.com wrote:

 I recreated the .MSI file today, and reran the installation with the
 following command:
 msiexec /i

 C:\Installs\WixWindowsService2012Setup\bin\Release\WixWindowsService2012Setup.msi
 /l*v C:\Installs\WixWindowsService2012Setup\bin\Release\install.log.

 It still overrides the config file, and this is from the log file:

 MSI (s) (00:9C) [09:59:20:624]: Executing op:

 FileRemove(,FileName=WixWindowsService2012.exe.config,,ComponentId={blabla})
 MSI (s) (00:9C) [09:59:20:626]: Verifying accessibility of file:
 WixWindowsService2012.exe.config

 MSI (s) (00:64) [09:59:20:715]: Executing op:
 ComponentRegister(ComponentId={blabla},KeyPath=C:\Program

 Files\WixWindowsService2012\WixWindowsService2012.exe.config,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)

 MSI (s) (00:64) [09:59:21:042]: Executing op:

 FileCopy(SourceName=fctymilg.con|WixWindowsService2012.exe.config,SourceCabKey=WixWindowsService2012.exe.config,DestName=WixWindowsService2012.exe.config,Attributes=512,FileSize=538,PerTick=65536,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=1770114632,HashPart2=-1876651659,HashPart3=212308780,HashPart4=-2030918298,,)

 MSI (s) (00:64) [09:59:21:043]: File: C:\Program
 Files\WixWindowsService2012\WixWindowsService2012.exe.config;   To be
 installed;  Won't patch;No existing file
 MSI (s) (00:64) [09:59:21:043]: Source for file
 'WixWindowsService2012.exe.config' is compressed

 Why does the installation remove and copy the file, even though the config
 file in the installer has a different date and time with the config file
 on
 the installed folder ?

 Thank you.




 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-not-copy-a-file-in-subsequent-installations-tp7592929p7592949.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to not copy a file in subsequent installations?

2014-02-26 Thread John Ludlow

Aha!

MSI (s) (00:64) [09:59:21:043]: File: C:\Program
Files\WixWindowsService2012\WixWindowsService2012.exe.config;   To be
installed;  Won't patch;No existing file
MSI (s) (00:64) [09:59:21:043]: Source for file
'WixWindowsService2012.exe.config' is compressed

So why is there No existing file?

Where do you have your RemoveExistingProducts action scheduled? I think
what's happening is your REP is removing the file, then when your newer
version comes along it finds the file missing so it install its copy.

If possible, move RemoveExistingProducts later in the sequence.

Check these links out:

http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-major-msi-upgrade/
http://msdn.microsoft.com/en-us/library/aa371197(v=vs.85).aspx


On 26 February 2014 15:10, faujong fiefie.ni...@gmail.com wrote:

 I recreated the .MSI file today, and reran the installation with the
 following command:
 msiexec /i

 C:\Installs\WixWindowsService2012Setup\bin\Release\WixWindowsService2012Setup.msi
 /l*v C:\Installs\WixWindowsService2012Setup\bin\Release\install.log.

 It still overrides the config file, and this is from the log file:

 MSI (s) (00:9C) [09:59:20:624]: Executing op:

 FileRemove(,FileName=WixWindowsService2012.exe.config,,ComponentId={blabla})
 MSI (s) (00:9C) [09:59:20:626]: Verifying accessibility of file:
 WixWindowsService2012.exe.config

 MSI (s) (00:64) [09:59:20:715]: Executing op:
 ComponentRegister(ComponentId={blabla},KeyPath=C:\Program

 Files\WixWindowsService2012\WixWindowsService2012.exe.config,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)

 MSI (s) (00:64) [09:59:21:042]: Executing op:

 FileCopy(SourceName=fctymilg.con|WixWindowsService2012.exe.config,SourceCabKey=WixWindowsService2012.exe.config,DestName=WixWindowsService2012.exe.config,Attributes=512,FileSize=538,PerTick=65536,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=1770114632,HashPart2=-1876651659,HashPart3=212308780,HashPart4=-2030918298,,)

 MSI (s) (00:64) [09:59:21:043]: File: C:\Program
 Files\WixWindowsService2012\WixWindowsService2012.exe.config;   To be
 installed;  Won't patch;No existing file
 MSI (s) (00:64) [09:59:21:043]: Source for file
 'WixWindowsService2012.exe.config' is compressed

 Why does the installation remove and copy the file, even though the config
 file in the installer has a different date and time with the config file on
 the installed folder ?

 Thank you.




 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-not-copy-a-file-in-subsequent-installations-tp7592929p7592949.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to not copy a file in subsequent installations?

2014-02-26 Thread John Ludlow

Um, yes.

Have you considered using *afterInstallExecute *or *afterInstallExecuteAgain
*instead?


On 26 February 2014 15:49, faujong fiefie.ni...@gmail.com wrote:

 Hi John,
 No existing file is because prior to it the installation removed the file
 MSI (s) (00:9C) [09:59:20:624]: Executing op:

 FileRemove(,FileName=WixWindowsService2012.exe.config,,ComponentId={blabla})
 MSI (s) (00:9C) [09:59:20:626]: Verifying accessibility of file:
 WixWindowsService2012.exe.config


 This is in Product.wxs (I set Schedule=afterInstallInitialize in
 MajorUpgrade element)
 Product Id=* Name=WixWindowsService2012..UpgradeCode=bla
 Package InstallerVersion=200../
 Upgrade Id=bla
 UpgradeVersion OnlyDetect=no Property=PREVIOUSFOUND
Minimum=1.0.0.0  IncludeMinimum=yes
Maximum=99.0.0.0 IncludeMaximum=no /
 /Upgrade
 MajorUpgrade Schedule=afterInstallInitialize/
 :
 Component Id=ProductComponent Win64=yes
 File Id=WixWindowsService2012.exe
 Name=WixWindowsService2012.exe
 Source=$(var.WixWindowsService2012.TargetPath) Vital=yes KeyPath=yes
 DiskId=1/
 ServiceInstall../ServiceInstall
 ServiceControl Id=StartService Start=install Stop=both
 Remove=uninstall Name=WixWindowsService2012 Wait=yes /
 /Component





 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-not-copy-a-file-in-subsequent-installations-tp7592929p7592952.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom action to write into a file while installing and uninstalling MSI file

2014-02-26 Thread John Ludlow

Is this just for logging purposes? Is the normal MSI log not sufficient?

If it's not, then depending on your situation, there's a number of options:

 * The XmlFile element in the Util extension can be tied to a component and
update a target file when that component is installed or uninstalled.
 * The IniFile table
 * A custom action based on the C++ or C# custom action templates that the
VS integration gives you

Ideally you want a technique that's table driven and transactional (so that
the manifest reflects the state of the system after a rollback).


On 26 February 2014 20:44, Mamidi, Balasubrahmanyam 
balu.mam...@flightsafety.com wrote:

 Hi, we package the lessons and give to users in the format of msi file
 using wix installer. When users install/ Uninstall these lessons MSI file
 on their PC's, I should able to log this information with date time   MSI
 name into text file( file needs to create if not exists) under location
 (per say C:\FlightSafety).

 Can someone help to write these custom actions or any other solutions?

 Thanks,
 Balu

 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.

 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to not copy a file in subsequent installations?

2014-02-25 Thread John Ludlow

Have a read of this:

http://msdn.microsoft.com/en-us/library/aa370531(v=vs.85).aspx

Now, before you do your upgrade, have a look at the file's modified and
creation dates. If they match, then MSI takes that as a signal that they
can be overwritten (because it sets those dates to the same value during
install). It can also, optionally, do a hash check.

If a user has modified the file, then the dates should be different and MSI
will leave the file alone.

So the question is whether the file would be modified post installation? If
so, then you would need to look at a verbose upgrade log for further
details.

On 25 February 2014 20:13, faujong fiefie.ni...@gmail.com wrote:

n the Product.wxs, I set Schedule=afterInstallInitialize in the
MajorUpgrade so that if the installation fails, it will roll back to the
previous version.

Our Windows Service uses app.config that the installer copied to the
installed machine. We do this by including the below line in the
Product.wxs:

Component Id=Config Win64=yes
File

Source=$(var.WixWindowsService2012.TargetDir)WixWindowsService2012.exe.config
Name=WixWindowsService2012.exe.config
Vital=yes KeyPath=yes /
/Component
We only want to copy this app.config file on the first installation, and we
do NOT want to copy it in the subsequent installations.

When I comment out the above Component element in the Product.wxs, the
installation failed because during installation, it deletes the app.config
on the installed folder, and since the Windows Service requires it to run,
the installation fails.

Following
http://stackoverflow.com/questions/1912037/copy-if-not-exist-in-wix, I
thought if I set the File element to be like below, it will NOT copy the
file if the file already exists in the installed folder:
File

Source=$(var.WixWindowsService2012.TargetDir)WixWindowsService2012.exe.config/
But, the above command still override the file.

How can I make the installation to not copy the app.config to the installed
folder if app.config already exists there ?

Thank you.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-not-copy-a-file-in-subsequent-installations-tp7592929.html
Sent from the wix-users mailing list archive at Nabble.com.

http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to not copy a file in subsequent installations?

2014-02-25 Thread John Ludlow

Follow the instructions here:

http://support.microsoft.com/kb/223300

The simplest way for logging a single session is to start the installer
with the /l switch

msiexec /i c:\path\to\myinstall.msi /l*v c:\path\to\myinstall.log

On 25 February 2014 23:56, fiefie.niles fiefie.ni...@gmail.com wrote:

Where can I get the verbose install log from ?

Sent via the Samsung Galaxy S(tm)III, an ATT 4G LTE smartphone

Original message
From: Hoover, Jacob jacob.hoo...@greenheck.com
Date:02/25/2014 5:12 PM (GMT-06:00)
To: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to not copy a file in subsequent
installations?

What are the exact options you are using when reinstalling? (You can pass
nasty options to msiexec to have it force overwrite things.) A verbose
install log will tell you exactly why it's doing it.

-Original Message-
From: Fiefie Niles [mailto:fiefie.ni...@nadex.com]
Sent: Tuesday, February 25, 2014 3:37 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] How to not copy a file in subsequent
installations?

If that's the case, then why when I re-install today, it overrides the
app.config, even though the time of the app.config in the installer and on
the installed folder is different ?

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, February 25, 2014 3:29 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] How to not copy a file in subsequent
installations?

It's date a time, not just date.

-Original Message-
From: faujong [mailto:fiefie.ni...@gmail.com]
Sent: Tuesday, February 25, 2014 3:16 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to not copy a file in subsequent
installations?

Thank you for your reply.

The first installation was today, so the app.config file date is today's
date.
I then today modified the app.config file on the installed folder.

Do I understand it correctly that
1. when I re-install again today, it overrides the app.config file because
the dates of the file in the installer and on the installed folder are the
same, ie today's date ?
2. If I install tomorrow, since the dates of the file installer will be
tomorrow's date, and the date of the fiile on the installed folder is
tomorrow, it will NOT override the file ?

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-not-copy-a-file-in-subsequent-installations-tp7592929p7592931.html
Sent from the wix-users mailing list archive at Nabble.com.

http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

This electronic mail message and any attachments may contain confidential
and/or privileged information that is only intended for use by, North
American Derivatives Exchange, Inc. (Nadex) or third-parties to whom it
is directed. The contents of this electronic mail message are not to be
copied, modified, published, transmitted, distributed, performed,
displayed, or sold in any way. If you are not the addressee, you are
prohibited from disclosing, copying, distributing or taking any action
based on the contents of this message. If you have received this message by
mistake, please contact the sender immediately. All email sent to or from
the Nadex corporate email system may be retained, monitored and/or reviewed
by Nadex personnel. Nadex is located at 311 South Wacker Drive, Suite 2675,
Chicago, IL 60606. Nadex is subject to U.S. regulatory oversight by the
CFTC. Futures, options and swaps trading involves risk and may not be
appropriate for all investors. The contents hereof are not an offer, or a
solicitation of an offer, to buy or sell any particular financial
instrument

Re: [WiX-users] Burn custom UI, second browse button

2014-02-13 Thread John Ludlow

I think you may need to use something like this:
http://wixextba.codeplex.com/


On 13 February 2014 11:21, Hans De Groot hans.degr...@nice.com wrote:

 Hello,

 I'm trying to a second location + browse button the standard bootstrapper
 application. I currently have this:
 Page Name=Options
 Text X=11 Y=70 Width=-11 Height=30
 FontId=2#(loc.OptionsHeader)/Text
 Text X=11 Y=111 Width=-11 Height=17
 FontId=3#(loc.OptionsLocationLabel)/Text
 Editbox Name=FolderEditbox X=11 Y=133 Width=-91
 Height=21 TabStop=yes FontId=3 FileSystemAutoComplete=yes /
 Button Name=BrowseButton X=-11 Y=132 Width=75 Height=23
 TabStop=yes FontId=3#(loc.OptionsBrowseButton)/Button

 Text X=11 Y=158 Width=-11 Height=17
 FontId=3#(loc.OptionsLogfileLabel)/Text
 Editbox Name=LogFolderEditbox X=11 Y=180 Width=-91
 Height=21 TabStop=yes FontId=3 FileSystemAutoComplete=yes /
 Button Name=BrowseButtonLog X=-11 Y=179 Width=75
 Height=23 TabStop=yes FontId=3#(loc.OptionsBrowseButton)/Button

 Button Name=OptionsOkButton X=-91 Y=-11 Width=75
 Height=23 TabStop=yes FontId=0#(loc.OptionsOkButton)/Button
 Button Name=OptionsCancelButton X=-11 Y=-11 Width=75
 Height=23 TabStop=yes FontId=0#(loc.OptionsCancelButton)/Button

 /Page


 This works for the layout part, but not for the functional part. The
 browse button does not do anything. And when I change it to BrowseButton it
 interacts with the install folder edit box.
 How do I change the stba to support multiple input fields with a browse
 button.

 Hope you can help,
 Regards,
 Hans de Groot


 --
 Android apps run on BlackBerry 10
 Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
 Now with support for Jelly Bean, Bluetooth, Mapview and more.
 Get your Android app in front of a whole new audience.  Start now.

 http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Digitally Sign BootStrapper project

2013-12-09 Thread John Ludlow

JCHoover responded to that SO question.

You should also check out these discussion threads on this forum:

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Signing-bundles-changes-needed-to-each-bundle-wixproj-td7591050.html

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Signing-bundles-changes-needed-to-each-bundle-wixproj-td7591062.html#a7591092

I've also added another answer to build on Jacob's.

On 9 December 2013 15:23, Brian Enderle bria...@gmail.com wrote:

I have posted a question on StackOverflow asking how to digitally sign a
bootstrapper:

http://stackoverflow.com/questions/20381525/wix-digitally-sign-bootstrapper-project
.
I can successfully sign an installer (MSI file) but am having some issues
with the bootstrapper (EXE file).

I would appreciate any input on this.

Brian

If you can't explain it simply, you don't understand it well enough. -
Albert Einstein

--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!

http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Hex codes in bundle errors

2013-12-04 Thread John Ludlow

Hi,

I'm writing a bundles to chain some installs together. Currently this is
WiX 3.6, though I'll be considering an upgrade to 3.8 at some point. The
bundle uses the RtfTheme theme, customized with the
bal:WixStandardBootstrapperApplication/@ThemeFile attribute.

My question is this: Is there a way to remove the hex codes from the error
message when a bundle fails. We have a bal:Condition element which throws a
message if certain prerequisites aren't installed, and this message gets
prefixed with the hex code 0x81f40001.

Personally, I don't have a problem with this but the QA engineer asked me
to change this as she didn't like the look of it, and I said I'd try to
find out if there was a way.

So if there's a SuppressHexCodesInErrorMessages variable or attribute
somewhere that I haven't found, please point me in the right direction.

Thanks

John
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-03 Thread John Ludlow

A poll might be a good idea - at least then we / you know what the
situation is. If it turns out there's no sensible default because everyone
*is* doing everything a different way, then it's sensible to not provide a
default. If it turns out that actually a lot of people do it a similar way
then maybe it's worth providing a default.

Or perhaps it's just worth improving the documentation because that
improves both cases without breaking anybody.

I'd be happy to submit a documentation update. (And yes, the codeproject
article I said I'd do on extensions is still sitting half-finished waiting
for me to find time for it). One thing I think might be helpful is if
there's a topic on signing (or perhaps two - one for bundles and one for
MSIs). At the moment the experience is that I google sign wix bundle and
get to the insignia page - which tells me not to use that.

One (or two) topic(s) that listed the 3 (I think?) options for signing
might be easier for people to get to grips with. I think the options are:

For signing a Bundle:
   1) Build the bundle, then use the following commands as a post build
step:
 insignia   -ib bundle.exe   -o engine.exe
 signtool  /a engine.exe  /sha1 hash   /t timestamp url
 insignia   -ab engine bundle.exe   -o bundle.exe
 signtool /a bundle.exe  /sha1 hash   /t timestamp url

   2) Use the CustomAfterWixTargets property to specify a .targets file
which contains the SignBundle and SignBundleEngine targets

   3) Add the SignBundle and SignBundleEngine targets into your .wixproj
(probably by adding an Import reference in your .wixproj to a .targets
file)

For signing an MSI:
   1) Build the MSI with external cabs, sign the cabs, then use insignia to
inscribe the MSI with the signature the cabs use (only relevant for MSIs
which use external cabs, I think?)

   2) Use the CustomAfterWixTargets property to specify a .targets file
which contains the SignCabs and SignMsi targets

   3) Add the SignCabs and SignMsi targets into your .wixproj (probably by
adding an Import reference in your .wixproj to a .targets file)

Does that seem right?

Also, I did notice something in the help source:

  !-- TODO: mention the SignContainers target --

I haven't used external containers yet so this one is new to me. However,
if I was to update the documentation I should probably include  this as
well.

Thanks



On 3 December 2013 04:47, Blair Murri os...@live.com wrote:

 At one time at MSFT (don't know if it is still the case) the machine that
 did codesigning for (most? all?) teams worldwide was solely located in
 (IIRC) Puerto Rico, and the files had to be securely electronically
 transported there, signed, and securely transported back, by a system owned
 by the group managing production signing (despite most build servers being
 in Redmond, Washington). Direct access to the signtool tool wasn't of any
 use in that case.

 At my current client, there is no official signing in any build leg that
 developers have direct access to. You tell them where your files are and
 they sign them. They sign everything before the packaging step of the
 build, but they have to script signing things that are contained by
 other things built during packaging, like external cabs any everything we
 stick into a bundle.

 Seems like everyone does it differently. Maybe we should take a poll to
 see if there is any one majority way that we could optimize for, but even
 inside of MSFT it had to be done differently for production signing and
 internal only-test signing.

 -Blair

  Date: Mon, 2 Dec 2013 22:08:16 +
  From: john.ludlow...@gmail.com
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
  wixproj
 
  Fair enough. I guess we have it set up quite simply - a cert in a folder
 on
  the file server with restricted access. This is imported into the
  certificate store on the build machine by the build and selected by sha1
  hash when calling signtool. We also timestamp.
 
  Therefore simply providing a path to signtool, the sha1 and the
  timestamping url via properties would work for us - that seems like a
  sensible default which could be overridden
 
  Thanks
  On 2 Dec 2013 18:24, Rob Mensching r...@robmensching.com wrote:
 
   My experience is that you really want your private key under lock and
 key.
   I heard the room with the private key at MSFT had a hand print reader.
 Even
   the WiX toolset submits our binaries off to a signing service to get
   signed. Never saw two organizations implement signing the same way.
 sigh/
  
   -Original Message-
   From: John Ludlow [mailto:john.ludlow...@gmail.com]
   Sent: Monday, December 2, 2013 10:09 AM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Signing bundles - changes needed to each
 bundle
   wixproj
  
   I suppose that's a good point, Rob - there's lots of ways to sign
 stuff.
   We tend to go to the signtool

Re: [WiX-users] wixtoolset.org popups

2013-12-03 Thread John Ludlow

I'm not seeing any adverts. On Chrome I do have AdBlockerPlus, but it
didn't report a blocked popup, and when I disabled it and refreshed I
didn't see anything.

Of course, it might be that you're hitting a different server than I am.


On 3 December 2013 13:44, Christopher Painter chr...@iswix.com wrote:


 Is anyone else getting popup advertisements on wixtoolset.org?
 Advertisements from infinityads are what I'm seeing.


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

Hi,

We're writing an installer using a bundle to chain two MSIs together. The
bundle should be signed (we generally sign installers and EXEs and DLLs).
Currently, we're using WiX 3.6 (we currently use Visual Studio 2008, and
3.7 didn't support that version of Visual Studio).

We've discovered the 0x80004005 error described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td7587152.html

However, the fix for this seems to be to tweak the project files. This is
not a preferred solution for us, as over the next year we will be creating
a significant number of these as we adopt this technology for some of our
existing installers. Since any tweaks to the projects are hidden (they
require right clicking the project, choosing Edit... and effectively
unloading the project from the solution). We'd have to remember to do that
each time we create a bundle, and I'd rather not have that point of failure.

I'm planning on using insignia.exe to extract engine.exe, sign it and then
import it. However, it's been suggested this is also less than ideal
(though it's better than having to remember to tweak a project file).

I was wondering whether this is improved in later versions of WiX. I
imagine it would be pretty simple for WiX to include this functionality in
the default .wixproj project template, meaning we don't have to remember to
do it ourselves. If this is the case, would this also support timestamping?

Or are there any other inventive solutions for solving this issue?

Thanks

John
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

Hi Rob,

How would this be invoked from the build? Your message prompted some
digging, and I found CustomAfterWixTargets. Would you recommend setting
this to the path to my own msbuild .targets file, and providing the SignXXX
targets in there?

I tried this and it seemed to work.

If this is best practice, it would be worth updating the documentation to
this effect.

On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:

Generally, I've seen people use the instructions to check the WiX toolset
into their build process and provide a standard .props/.targets file for
encapsulating all the custom logic for their build.

-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Monday, December 2, 2013 4:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Signing bundles - changes needed to each bundle
wixproj

Hi,

We've discovered the 0x80004005 error described here:

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td7587152.html

Or are there any other inventive solutions for solving this issue?

Thanks

John

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

I see - that was the impression I got from the documentation, but I tend to
prefer to stay out of those because any changes to the .wixprojs are
relatively hidden, and we'd have to do the change for each bundle .wixproj
(and probably each MSI .wixproj). Given the hidden nature, it's easy to
forget (and more than a little cumbersome to implement each change).

We could partially solve this using tools to mandate that this change was
done before checkin, but we'd have to write a check for that tool. It's not
difficult, but if we don't need to do it then we'd rather not. Similarly,
we could write tools to auto-fix this - again, not difficult, but if we
don't need to do it then we'd rather not.

Ideally, however, the wix targets that come out of the box would have this
already.

I was wondering whether there's a reason why editing the .wixproj is
preferred over CustomAfterWixTargets. If Visual Studio did a better job of
exposing the underlying msbuild code then I'd just tweak the .msbuild file,
but given how cumbersome it is, I'd rather avoid this if I can help it.




On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:

 You could do that. I tend to add an explicit .props/.targets file to the
 .wixprojs myself but you have options with MSBuild.

 Documentation improvements are always appreciated.

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Monday, December 2, 2013 8:07 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
 wixproj

 Hi Rob,

 How would this be invoked from the build? Your message prompted some
 digging, and I found CustomAfterWixTargets. Would you recommend setting
 this to the path to my own msbuild .targets file, and providing the SignXXX
 targets in there?

 I tried this and it seemed to work.

 If this is best practice, it would be worth updating the documentation to
 this effect.


 On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:

  Generally, I've seen people use the instructions to check the WiX
  toolset into their build process and provide a standard
  .props/.targets file for encapsulating all the custom logic for their
 build.
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Monday, December 2, 2013 4:23 AM
  To: General discussion for Windows Installer XML toolset.
  Subject: [WiX-users] Signing bundles - changes needed to each bundle
  wixproj
 
  Hi,
 
  We're writing an installer using a bundle to chain two MSIs together.
  The bundle should be signed (we generally sign installers and EXEs and
 DLLs).
  Currently, we're using WiX 3.6 (we currently use Visual Studio 2008,
  and
  3.7 didn't support that version of Visual Studio).
 
  We've discovered the 0x80004005 error described here:
 
  http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-
  Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td758
  7152.html
 
  However, the fix for this seems to be to tweak the project files. This
  is not a preferred solution for us, as over the next year we will be
  creating a significant number of these as we adopt this technology for
  some of our existing installers. Since any tweaks to the projects are
  hidden (they require right clicking the project, choosing Edit... and
  effectively unloading the project from the solution). We'd have to
  remember to do that each time we create a bundle, and I'd rather not
 have that point of failure.
 
  I'm planning on using insignia.exe to extract engine.exe, sign it and
  then import it. However, it's been suggested this is also less than
  ideal (though it's better than having to remember to tweak a project
 file).
 
  I was wondering whether this is improved in later versions of WiX. I
  imagine it would be pretty simple for WiX to include this
  functionality in the default .wixproj project template, meaning we
  don't have to remember to do it ourselves. If this is the case, would
 this also support timestamping?
 
  Or are there any other inventive solutions for solving this issue?
 
  Thanks
 
  John
 
  --
   Rapidly troubleshoot problems before they affect your
  business. Most IT organizations don't have a clear picture of how
  application performance affects their revenue. With AppDynamics, you
  get 100% visibility into your Java,.NET,  PHP application. Start your
  15-day FREE TRIAL of AppDynamics Pro!
  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.c
  lktrk ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
  --
   Rapidly troubleshoot problems before they affect your
  business. Most IT organizations don't have

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

Thanks for that, Blair.

We've discussed changing the .wixprojs, and there is some appeal for that
within the team. However, due to my preference to stay out of the .wixprojs
as much as I can, I think I'll push for the CustomAfterWixTargets property
method.

Thanks Blair and Rob

John



On 2 December 2013 17:52, Blair Murri os...@live.com wrote:

 I don’t believe there’s a preference to one over the other. Each has its
 own costs and risks. Whichever works better in your environment. MSBuild is
 flexible in that regard. (What I do with my clients tends to vary based on
 the client’s needs and customs).






 -Blair





 From: John Ludlow
 Sent: Monday, December 02, 2013 9:49 AM
 To: General discussion for Windows Installer XML toolset.





 I see - that was the impression I got from the documentation, but I tend to
 prefer to stay out of those because any changes to the .wixprojs are
 relatively hidden, and we'd have to do the change for each bundle .wixproj
 (and probably each MSI .wixproj). Given the hidden nature, it's easy to
 forget (and more than a little cumbersome to implement each change).

 We could partially solve this using tools to mandate that this change was
 done before checkin, but we'd have to write a check for that tool. It's not
 difficult, but if we don't need to do it then we'd rather not. Similarly,
 we could write tools to auto-fix this - again, not difficult, but if we
 don't need to do it then we'd rather not.

 Ideally, however, the wix targets that come out of the box would have this
 already.

 I was wondering whether there's a reason why editing the .wixproj is
 preferred over CustomAfterWixTargets. If Visual Studio did a better job of
 exposing the underlying msbuild code then I'd just tweak the .msbuild file,
 but given how cumbersome it is, I'd rather avoid this if I can help it.




 On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:

  You could do that. I tend to add an explicit .props/.targets file to the
  .wixprojs myself but you have options with MSBuild.
 
  Documentation improvements are always appreciated.
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Monday, December 2, 2013 8:07 AM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
  wixproj
 
  Hi Rob,
 
  How would this be invoked from the build? Your message prompted some
  digging, and I found CustomAfterWixTargets. Would you recommend setting
  this to the path to my own msbuild .targets file, and providing the
 SignXXX
  targets in there?
 
  I tried this and it seemed to work.
 
  If this is best practice, it would be worth updating the documentation to
  this effect.
 
 
  On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:
 
   Generally, I've seen people use the instructions to check the WiX
   toolset into their build process and provide a standard
   .props/.targets file for encapsulating all the custom logic for their
  build.
  
   -Original Message-
   From: John Ludlow [mailto:john.ludlow...@gmail.com]
   Sent: Monday, December 2, 2013 4:23 AM
   To: General discussion for Windows Installer XML toolset.
   Subject: [WiX-users] Signing bundles - changes needed to each bundle
   wixproj
  
   Hi,
  
   We're writing an installer using a bundle to chain two MSIs together.
   The bundle should be signed (we generally sign installers and EXEs and
  DLLs).
   Currently, we're using WiX 3.6 (we currently use Visual Studio 2008,
   and
   3.7 didn't support that version of Visual Studio).
  
   We've discovered the 0x80004005 error described here:
  
   http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-
   Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td758
   7152.html
  
   However, the fix for this seems to be to tweak the project files. This
   is not a preferred solution for us, as over the next year we will be
   creating a significant number of these as we adopt this technology for
   some of our existing installers. Since any tweaks to the projects are
   hidden (they require right clicking the project, choosing Edit... and
   effectively unloading the project from the solution). We'd have to
   remember to do that each time we create a bundle, and I'd rather not
  have that point of failure.
  
   I'm planning on using insignia.exe to extract engine.exe, sign it and
   then import it. However, it's been suggested this is also less than
   ideal (though it's better than having to remember to tweak a project
  file).
  
   I was wondering whether this is improved in later versions of WiX. I
   imagine it would be pretty simple for WiX to include this
   functionality in the default .wixproj project template, meaning we
   don't have to remember to do it ourselves. If this is the case, would
  this also support timestamping?
  
   Or are there any other inventive solutions for solving this issue

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

I suppose that's a good point, Rob - there's lots of ways to sign stuff. We
tend to go to the signtool method (actually a specific version of signtool
for reasons I can't remember) and I kind of figured that would be the
(ahem) generically preferred method of signing things that WiX cares about.

Anyway, thanks for your help.


On 2 December 2013 17:59, Rob Mensching r...@robmensching.com wrote:

 Ditto.

 And if you come up with a way to set these targets by default correctly
 for the multitude of ways for signing binaries, we'd love to discuss it on
 wix-devs.

 -Original Message-
 From: Blair Murri [mailto:os...@live.com]
 Sent: Monday, December 2, 2013 9:53 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
 wixproj

 I don’t believe there’s a preference to one over the other. Each has its
 own costs and risks. Whichever works better in your environment. MSBuild is
 flexible in that regard. (What I do with my clients tends to vary based on
 the client’s needs and customs).






 -Blair





 From: John Ludlow
 Sent: Monday, December 02, 2013 9:49 AM
 To: General discussion for Windows Installer XML toolset.





 I see - that was the impression I got from the documentation, but I tend
 to prefer to stay out of those because any changes to the .wixprojs are
 relatively hidden, and we'd have to do the change for each bundle .wixproj
 (and probably each MSI .wixproj). Given the hidden nature, it's easy to
 forget (and more than a little cumbersome to implement each change).

 We could partially solve this using tools to mandate that this change was
 done before checkin, but we'd have to write a check for that tool. It's not
 difficult, but if we don't need to do it then we'd rather not. Similarly,
 we could write tools to auto-fix this - again, not difficult, but if we
 don't need to do it then we'd rather not.

 Ideally, however, the wix targets that come out of the box would have this
 already.

 I was wondering whether there's a reason why editing the .wixproj is
 preferred over CustomAfterWixTargets. If Visual Studio did a better job of
 exposing the underlying msbuild code then I'd just tweak the .msbuild file,
 but given how cumbersome it is, I'd rather avoid this if I can help it.




 On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:

  You could do that. I tend to add an explicit .props/.targets file to
  the .wixprojs myself but you have options with MSBuild.
 
  Documentation improvements are always appreciated.
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Monday, December 2, 2013 8:07 AM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Signing bundles - changes needed to each
  bundle wixproj
 
  Hi Rob,
 
  How would this be invoked from the build? Your message prompted some
  digging, and I found CustomAfterWixTargets. Would you recommend
  setting this to the path to my own msbuild .targets file, and
  providing the SignXXX targets in there?
 
  I tried this and it seemed to work.
 
  If this is best practice, it would be worth updating the documentation
  to this effect.
 
 
  On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:
 
   Generally, I've seen people use the instructions to check the WiX
   toolset into their build process and provide a standard
   .props/.targets file for encapsulating all the custom logic for
   their
  build.
  
   -Original Message-
   From: John Ludlow [mailto:john.ludlow...@gmail.com]
   Sent: Monday, December 2, 2013 4:23 AM
   To: General discussion for Windows Installer XML toolset.
   Subject: [WiX-users] Signing bundles - changes needed to each bundle
   wixproj
  
   Hi,
  
   We're writing an installer using a bundle to chain two MSIs together.
   The bundle should be signed (we generally sign installers and EXEs
   and
  DLLs).
   Currently, we're using WiX 3.6 (we currently use Visual Studio 2008,
   and
   3.7 didn't support that version of Visual Studio).
  
   We've discovered the 0x80004005 error described here:
  
   http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-
   7-
   Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td7
   58
   7152.html
  
   However, the fix for this seems to be to tweak the project files.
   This is not a preferred solution for us, as over the next year we
   will be creating a significant number of these as we adopt this
   technology for some of our existing installers. Since any tweaks to
   the projects are hidden (they require right clicking the project,
   choosing Edit... and effectively unloading the project from the
   solution). We'd have to remember to do that each time we create a
   bundle, and I'd rather not
  have that point of failure.
  
   I'm planning on using insignia.exe to extract engine.exe, sign it
   and then import it. However, it's been suggested

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

2013-12-02 Thread John Ludlow

Fair enough. I guess we have it set up quite simply - a cert in a folder on
the file server with restricted access. This is imported into the
certificate store on the build machine by the build and selected by sha1
hash when calling signtool. We also timestamp.

Therefore simply providing a path to signtool, the sha1 and the
timestamping url via properties would work for us - that seems like a
sensible default which could be overridden

Thanks
On 2 Dec 2013 18:24, Rob Mensching r...@robmensching.com wrote:

 My experience is that you really want your private key under lock and key.
 I heard the room with the private key at MSFT had a hand print reader. Even
 the WiX toolset submits our binaries off to a signing service to get
 signed. Never saw two organizations implement signing the same way. sigh/

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Monday, December 2, 2013 10:09 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
 wixproj

 I suppose that's a good point, Rob - there's lots of ways to sign stuff.
 We tend to go to the signtool method (actually a specific version of
 signtool for reasons I can't remember) and I kind of figured that would be
 the
 (ahem) generically preferred method of signing things that WiX cares about.

 Anyway, thanks for your help.


 On 2 December 2013 17:59, Rob Mensching r...@robmensching.com wrote:

  Ditto.
 
  And if you come up with a way to set these targets by default
  correctly for the multitude of ways for signing binaries, we'd love to
  discuss it on wix-devs.
 
  -Original Message-
  From: Blair Murri [mailto:os...@live.com]
  Sent: Monday, December 2, 2013 9:53 AM
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] Signing bundles - changes needed to each
  bundle wixproj
 
  I don't believe there's a preference to one over the other. Each has
  its own costs and risks. Whichever works better in your environment.
  MSBuild is flexible in that regard. (What I do with my clients tends
  to vary based on the client's needs and customs).
 
 
 
 
 
 
  -Blair
 
 
 
 
 
  From: John Ludlow
  Sent: Monday, December 02, 2013 9:49 AM
  To: General discussion for Windows Installer XML toolset.
 
 
 
 
 
  I see - that was the impression I got from the documentation, but I
  tend to prefer to stay out of those because any changes to the
  .wixprojs are relatively hidden, and we'd have to do the change for
  each bundle .wixproj (and probably each MSI .wixproj). Given the
  hidden nature, it's easy to forget (and more than a little cumbersome to
 implement each change).
 
  We could partially solve this using tools to mandate that this change
  was done before checkin, but we'd have to write a check for that tool.
  It's not difficult, but if we don't need to do it then we'd rather
  not. Similarly, we could write tools to auto-fix this - again, not
  difficult, but if we don't need to do it then we'd rather not.
 
  Ideally, however, the wix targets that come out of the box would have
  this already.
 
  I was wondering whether there's a reason why editing the .wixproj is
  preferred over CustomAfterWixTargets. If Visual Studio did a better
  job of exposing the underlying msbuild code then I'd just tweak the
  .msbuild file, but given how cumbersome it is, I'd rather avoid this if
 I can help it.
 
 
 
 
  On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:
 
   You could do that. I tend to add an explicit .props/.targets file to
   the .wixprojs myself but you have options with MSBuild.
  
   Documentation improvements are always appreciated.
  
   -Original Message-
   From: John Ludlow [mailto:john.ludlow...@gmail.com]
   Sent: Monday, December 2, 2013 8:07 AM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Signing bundles - changes needed to each
   bundle wixproj
  
   Hi Rob,
  
   How would this be invoked from the build? Your message prompted some
   digging, and I found CustomAfterWixTargets. Would you recommend
   setting this to the path to my own msbuild .targets file, and
   providing the SignXXX targets in there?
  
   I tried this and it seemed to work.
  
   If this is best practice, it would be worth updating the
   documentation to this effect.
  
  
   On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:
  
Generally, I've seen people use the instructions to check the WiX
toolset into their build process and provide a standard
.props/.targets file for encapsulating all the custom logic for
their
   build.
   
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Monday, December 2, 2013 4:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Signing bundles - changes needed to each
bundle wixproj
   
Hi,
   
We're

Re: [WiX-users] Microsoft Reciprocal License explaination

2013-11-20 Thread John Ludlow

If you modify WiX itself, then I'd argue that it's actually in your best
interest to contribute the changes back anyway, regardless of whether you
distribute those binaries. That way, they can be included in future
versions of WiX and you don't have to re-apply the changes every time you
upgrade the toolset.

The only reason I can see not to do this is because it depends on
proprietary code, which either has no use outside your environment, or is
considered part of your own product and can't be distributed.


On 20 November 2013 04:55, Rob Mensching r...@robmensching.com wrote:

 Depends on which lawyers you ask but I'd still leave you with my last
 comment:

 Your stuff is yours but don't steal from the community.
 If you improve our stuff, give back.


 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, November 20, 2013 11:34 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Microsoft Reciprocal License explaination

 But if I change something in the WiX toolset and don't distribute the
 modified WiX binaries (I only distribute msi packages generated with the
 modified WiX), I don't have to distribute the source code to my
 modifications, do I?

 --
 Nicolás

 2013/11/20 Rob Mensching r...@robmensching.com:
  If one does not claim the WiX code as part their own stuff (i.e. all the
 copyrights are left in place) and one does not change any code (i.e. WiX
 code is same as code published on WiX toolset site) then from my
 understanding (you'll need to get your own lawyer) they are still complying
 with MS-RL.
 
  Basically, when one changes something *in* the WiX toolset, those
 changes must be published. Ideally, those changes are provided to the
 community so everyone benefits from work done by volunteers around the
 world.
 
  Said another way, Your stuff is yours but don't steal from the
 community. If you improve our stuff, give back.
 
  -Original Message-
  From: Christopher Painter [mailto:chr...@iswix.com]
  Sent: Wednesday, November 20, 2013 11:10 AM
  To: General discussion about the WiX toolset.; General discussion about
 the WiX toolset.
  Subject: Re: [WiX-users] Microsoft Reciprocal License explaination
 
 
 
  The problem is the way they say normally  not included.  Got to love
 lawyers.
 
  FWIW, I get into grey areas with my tool IsWiX.   Include very small
 pieces of WiX in my solution   ( mainly the use of
 Microsoft.Deployment.WindowsInstaller, the inclusion of schema (XSD) files
 for validation and snippets of the help file displayed in the UI to educate
 the developer).   I'm not actually making any changes to WiX though and
 I want to publish under MS-PL not MS-RL because if anyone ever wants to
 pick up this ball and run with it, I'd be honored.
 
  I can only assume that OuterCurve won't want to waste going after me...
 there isn't any money and I'm not doing anything malicious.
 
  
   From: Rob Mensching r...@robmensching.com
  Sent: Tuesday, November 19, 2013 9:01 PM
  To: General discussion about the WiX toolset.
  wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Microsoft Reciprocal License explaination
 
  http://wixtoolset.org/about/license/
 
  -Original Message-
  From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
  Sent: Wednesday, November 20, 2013 6:48 AM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Microsoft Reciprocal License explaination
 
  2013/11/19 Joe Dimagio joedim...@gmail.com:
  Hey everyone,
 
  I'm doing some research to see if WiX is right for my corporation to
 use.
 
  Reading the MS RL, it looks like if I distribute my product using
  WiX, I need to include my source files including the wxs, wxl, wxi,
  wixproj, as well as my own product's source code as well.  Is this
  correct?  I'm not a lawyer but this seems like an all encompassing
  license that seems pretty prohibitive for a company to use if I'm
 reading it correct.
 
  No, not at all. That would be like saying that using an open source
 compiler means you have to distribute your source code if you compiled your
 binaries with it, or that you have to distribute your code if you used an
 open source text editor to write it; none of that makes sense.
  The license only affects WiX, not what you generate with it.
 
  However, I would like some clarifications from the developers about code
 from WiX that gets embedded into the final msi, especially the standard
 custom actions. I think that code should be explicitly under a more
 liberal license...
 
  --
  Nicolás
 


 --
 Shape the Mobile Experience: Free Subscription Software experts and
 developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing
 conversations that shape the rapidly evolving mobile

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-19 Thread John Ludlow

That should have read:

If you make this change, you can also remove the following line:

RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]'
Type='string' Value='' KeyPath='yes' /


On 19 November 2013 08:34, John Ludlow john.ludlow...@gmail.com wrote:

 That's because of this:

   Directory Id='DesktopFolder'  Name='PFiles'

 This will put files on the users desktop - are you sure that's what you
 want? (Hint: it's probably not) Change this to ProgramFilesFolder (or
 ProgramFiles64Folder). Remember how you were getting a similar error
 previously?

 If you make this change, you can also remove the following line:


 Alternatively, use a script to modify each component so it contains a
 registry entry.


 On 19 November 2013 07:50, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John/All,

 I have used the below commands:


 heat dir D:\Project\ESI\Code\trunk\db -cg trunkdb -gg -sfrag -dr
 TORTDEMO -out trunkdb.wxs
 candle TortEngineDemo.wxs trunkdb.wxs
 light -b D:\Project\ESI\Code\trunk\db -out TrunkDBDemo.msi
 TortEngineDemo.wixobj trunkdb.wixobj

 This does create the TrunkDBDemo.msi and when i run it it also creates
 the Tort Demo folder on the desktop and the db directory in which i can
 find all the files that were there in the source directory. The required
 registry entry is also created.
 The change i have done is added the part *-b
 D:\Project\ESI\Code\trunk\db  *to the Light command
 *. *
 But the Light does throw up some many errors such as :

 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(921) : error
 LGHT0204 :
 ICE38: Component cmp159DEBB341761ACFD08D530D4AB638B2 installs to user
 profile. It must use a registry key under HKCU as its KeyPath, not a file.

 In the trunkdb.wxs file i have the like below(files are attached)
 Component Id=cmp159DEBB341761ACFD08D530D4AB638B2
 Guid={AA11F234-AF77-4F2C-B4A2-355A25C71234}

 File Id=fil13F4C3BF2526AB7CCACA852D90DAA880
 KeyPath=yes Source=SourceDir\alarm.db/
 Do i need to change this file to registry key when generating this file
 from heat? Please suggest as to what the error could be for?

 Regards,
 Suvra Jyoti


 On 18-11-2013 21:31, John Ludlow wrote:

  Yeah I didn't explain that path thing very well. I was referring to
 this path:

   C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs

 This probably shouldn't be here. Best to keep this out of the WiX install
 directory. If this is a file which is generated for every build, then
 either use an intermediates folder in your build tree, or put it into the
 %tmp% directory. This is probably because you're not specifying a full path
 for the -out parameter.

 I'm not entirely clear on why you're launching an installer from
 CruiseControl - that seems a little weird to me. It sounds like you're
 trying to use MSI to achieve a continuous deployment scenario, and it's not
 really designed for that - is that what you're trying to do?

 I've not actually used the heat -var argument, so the advice I can give
 you will be limited. However, I believe that if you add
 -var:TrunkDbRootDir to your heat command, it will generate something like
 this:

 File Source=$(var.TrunkDbRootDir)\file.ext/

 You will have to define that variable elsewhere, and it's up to you to
 make sure that it points to the correct place so that the path is correct
 when the variable is resolved. Someone with more experience of heat.exe
 might be able to help you further.

 Hope that helps


 On 18 November 2013 14:36, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 When I are created the  trunkdb.wxs file i had ditected it to
 D:\Project\ESI\Code\trunk\db. These files exist now also and are part of
 the SVN source control. I do not get what you mean by C:\Program Files
 (x86) and I'm not sure how it came up with that path . I am just
 executing Light from the path C:\Program Files (x86)\WiX Toolset v3.7\bin
 where in my two source files are also placed(tortenginedemo.wxs and
 trunkdb.wxs). By File/@Source i guess you mean that as of now in the
 fragment the path is only SourceDIr. Let me know how we can do that.

 I need this to be dynamic in the sense that a batch file would execute
 that would create the directory *db** (*D:\Project\ESI\Code\trunk\db
 *). * The WIX installer that needs to be created should install the
 “db” directories that is created by the batch file. Basically i need to
 execute the installer when the scroipts for cruise control are fired. The
 firing of the cruisecontrol script fires the installer as well through a
 batch file.

 This is the approach that has been decided as of now. In case you other
 pointers do let me know specially the You will need to either specify the
 -var argument to heat.exe with a variable name (and tweak the value so that
 it matches correctly) or write some build code to tweak the contents of
 this file. if this helps.

 Moreover it is not that the error is being shown foll all the files in
 the db

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-19 Thread John Ludlow

That's because of this:

  Directory Id='DesktopFolder'  Name='PFiles'

This will put files on the users desktop - are you sure that's what you
want? (Hint: it's probably not) Change this to ProgramFilesFolder (or
ProgramFiles64Folder). Remember how you were getting a similar error
previously?

If you make this change, you can also remove the following line:


Alternatively, use a script to modify each component so it contains a
registry entry.


On 19 November 2013 07:50, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John/All,

 I have used the below commands:


 heat dir D:\Project\ESI\Code\trunk\db -cg trunkdb -gg -sfrag -dr
 TORTDEMO -out trunkdb.wxs
 candle TortEngineDemo.wxs trunkdb.wxs
 light -b D:\Project\ESI\Code\trunk\db -out TrunkDBDemo.msi
 TortEngineDemo.wixobj trunkdb.wixobj

 This does create the TrunkDBDemo.msi and when i run it it also creates the
 Tort Demo folder on the desktop and the db directory in which i can find
 all the files that were there in the source directory. The required
 registry entry is also created.
 The change i have done is added the part *-b
 D:\Project\ESI\Code\trunk\db  *to the Light command
 *. *
 But the Light does throw up some many errors such as :

 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(921) : error
 LGHT0204 :
 ICE38: Component cmp159DEBB341761ACFD08D530D4AB638B2 installs to user
 profile. It must use a registry key under HKCU as its KeyPath, not a file.

 In the trunkdb.wxs file i have the like below(files are attached)
 Component Id=cmp159DEBB341761ACFD08D530D4AB638B2
 Guid={AA11F234-AF77-4F2C-B4A2-355A25C71234}

 File Id=fil13F4C3BF2526AB7CCACA852D90DAA880
 KeyPath=yes Source=SourceDir\alarm.db/
 Do i need to change this file to registry key when generating this file
 from heat? Please suggest as to what the error could be for?

 Regards,
 Suvra Jyoti


 On 18-11-2013 21:31, John Ludlow wrote:

  Yeah I didn't explain that path thing very well. I was referring to this
 path:

   C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs

 This probably shouldn't be here. Best to keep this out of the WiX install
 directory. If this is a file which is generated for every build, then
 either use an intermediates folder in your build tree, or put it into the
 %tmp% directory. This is probably because you're not specifying a full path
 for the -out parameter.

 I'm not entirely clear on why you're launching an installer from
 CruiseControl - that seems a little weird to me. It sounds like you're
 trying to use MSI to achieve a continuous deployment scenario, and it's not
 really designed for that - is that what you're trying to do?

 I've not actually used the heat -var argument, so the advice I can give
 you will be limited. However, I believe that if you add
 -var:TrunkDbRootDir to your heat command, it will generate something like
 this:

 File Source=$(var.TrunkDbRootDir)\file.ext/

 You will have to define that variable elsewhere, and it's up to you to
 make sure that it points to the correct place so that the path is correct
 when the variable is resolved. Someone with more experience of heat.exe
 might be able to help you further.

 Hope that helps


 On 18 November 2013 14:36, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 When I are created the  trunkdb.wxs file i had ditected it to
 D:\Project\ESI\Code\trunk\db. These files exist now also and are part of
 the SVN source control. I do not get what you mean by C:\Program Files
 (x86) and I'm not sure how it came up with that path . I am just
 executing Light from the path C:\Program Files (x86)\WiX Toolset v3.7\bin
 where in my two source files are also placed(tortenginedemo.wxs and
 trunkdb.wxs). By File/@Source i guess you mean that as of now in the
 fragment the path is only SourceDIr. Let me know how we can do that.

 I need this to be dynamic in the sense that a batch file would execute
 that would create the directory *db** (*D:\Project\ESI\Code\trunk\db*). *The 
 WIX installer that needs to be created should install the “db”
 directories that is created by the batch file. Basically i need to execute
 the installer when the scroipts for cruise control are fired. The firing of
 the cruisecontrol script fires the installer as well through a batch file.

 This is the approach that has been decided as of now. In case you other
 pointers do let me know specially the You will need to either specify the
 -var argument to heat.exe with a variable name (and tweak the value so that
 it matches correctly) or write some build code to tweak the contents of
 this file. if this helps.

 Moreover it is not that the error is being shown foll all the files in
 the db directory . It is showing for about 150 files in the db directory.
 There are a total of 379 files in the same.

 Regards,
 SuvraJyoti


 On 18-11-2013 19:00, John Ludlow wrote:

  Do those files exist at compilation time? They are C:\Program Files
 (x86) paths, and your code doesn't

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-19 Thread John Ludlow

In theory, just removing this line should do it:

Directory Id='DesktopFolder' Name='PFiles'
I haven't tried that though, so I'm not 100% sure. If not, you can also try
a custom action which sets the directory.

Generally, you should think twice before dropping files directly under c:\
- most people like to keep that as clean as possible.

On 19 November 2013 09:27, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

Hi John,

Thanks for the help...Just followed the steps...worked like a charm. The
folder got installed into the program files folder and there were no errors
thrown by Light.

But I want the db directory to be created into a folder in say
c:\[FolderName](c:\[FolderName]\Tort Demo). I have tried with like as
mentioned earlier DesktopFolder, LocalAppdatafolder etc just to see if
everything goes fine but i was getting the error mentioned in below mail.

For those errors i landed on to
http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-uninstall-shortcut-and-pass-all-the
where it is said that the registry key is created to make
ICE18http://msdn2.microsoft.com/en-us/library/aa368942.aspx,
ICE38 http://msdn2.microsoft.com/en-us/library/aa368961.aspx and
ICE48http://msdn2.microsoft.com/en-us/library/aa368977.aspxhappy. So can i
ignore those errors and move ahead?

How can i get my directory created to c:\[FolderName]\ ?

Regards,
SuvraJyoti

On 19-11-2013 14:05, John Ludlow wrote:

That should have read:

If you make this change, you can also remove the following line:

RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]'
Type='string' Value='' KeyPath='yes' /

On 19 November 2013 08:34, John Ludlow john.ludlow...@gmail.com wrote:

That's because of this:

Directory Id='DesktopFolder' Name='PFiles'

This will put files on the users desktop - are you sure that's what you
want? (Hint: it's probably not) Change this to ProgramFilesFolder (or
ProgramFiles64Folder). Remember how you were getting a similar error
previously?

If you make this change, you can also remove the following line:

Alternatively, use a script to modify each component so it contains a
registry entry.

On 19 November 2013 07:50, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

Hi John/All,

I have used the below commands:

heat dir D:\Project\ESI\Code\trunk\db -cg trunkdb -gg -sfrag -dr
TORTDEMO -out trunkdb.wxs
candle TortEngineDemo.wxs trunkdb.wxs
light -b D:\Project\ESI\Code\trunk\db -out TrunkDBDemo.msi
TortEngineDemo.wixobj trunkdb.wixobj

This does create the TrunkDBDemo.msi and when i run it it also creates
the Tort Demo folder on the desktop and the db directory in which i can
find all the files that were there in the source directory. The required
registry entry is also created.
The change i have done is added the part *-b
D:\Project\ESI\Code\trunk\db *to the Light command
*. *
But the Light does throw up some many errors such as :

C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(921) : error
LGHT0204 :
ICE38: Component cmp159DEBB341761ACFD08D530D4AB638B2 installs to user
profile. It must use a registry key under HKCU as its KeyPath, not a file.

In the trunkdb.wxs file i have the like below(files are attached)
Component Id=cmp159DEBB341761ACFD08D530D4AB638B2
Guid={AA11F234-AF77-4F2C-B4A2-355A25C71234}

File Id=fil13F4C3BF2526AB7CCACA852D90DAA880
KeyPath=yes Source=SourceDir\alarm.db/
Do i need to change this file to registry key when generating this file
from heat? Please suggest as to what the error could be for?

Regards,
Suvra Jyoti

On 18-11-2013 21:31, John Ludlow wrote:

Yeah I didn't explain that path thing very well. I was referring to
this path:

C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs

This probably shouldn't be here. Best to keep this out of the WiX
install directory. If this is a file which is generated for every build,
then either use an intermediates folder in your build tree, or put it into
the %tmp% directory. This is probably because you're not specifying a full
path for the -out parameter.

I'm not entirely clear on why you're launching an installer from
CruiseControl - that seems a little weird to me. It sounds like you're
trying to use MSI to achieve a continuous deployment scenario, and it's not
really designed for that - is that what you're trying to do?

I've not actually used the heat -var argument, so the advice I can give
you will be limited. However, I believe that if you add
-var:TrunkDbRootDir to your heat command, it will generate something like
this:

File Source=$(var.TrunkDbRootDir)\file.ext/

You will have to define that variable elsewhere, and it's up to you to
make sure that it points to the correct place so that the path is correct
when the variable is resolved. Someone with more experience of heat.exe
might be able to help you further.

Hope that helps

On 18 November 2013 14:36, Suvrajyoti

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-19 Thread John Ludlow

That looks like expected behaviour to me.

What's happening here is that the installer's created that directory
structure and deployed a bunch of resources. During uninstall, it
determines that those are the files it deployed and removes them. you can
specify Component/@Permanent=yes if you want to change that.

Once it's removed all the files, it finds that the directory is empty and
removes that as well.

Do you have a copy of this book? It's a great reference for understanding
WiX concepts.

http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book


On 19 November 2013 10:22, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Ok, I have made the following changes to the TortEngineDemo.wxs(also
 they are attached):

 Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='MyFolder' Name='EnergySolutionsInternational'
 FileSource='D:\'

 Directory Id='TORTDEMO' Name='Tort Demo'
   Component Id=TORTDEMO
 Guid=9D5FEECE-74FE-45A2-BD34-41562EC8ED16
 RemoveFolder Id='TORTDEMO' On='uninstall' /
 !--RegistryValue Root='HKCU'
 Key='Software\[Manufacturer]\[ProductName]' Type='string' Value=''
 KeyPath='yes' /--
   /Component
   !--Component Id=test
 Guid=A90AAE4F-CEB3-4958-A97D-458B25800D23
 File Id=test KeyPath=no
 Source=C:\Users\suvrajyotip\Desktop\test.txt /
 RegistryValue
 Key=Software\[Manufacturer]\[ProductName]_Dummy Root=HKCU KeyPath='yes'
 Type='string' Value=''/
   /Component--
 /Directory
   /Directory

 When i execute Candle and Light, the msi gets created and when i run the
 msi, the directory structure gets created in
 D:\EnergySolutionsInternational\Tort demo On uninstalling the
 EnergySolutionsInternational directory also gets removed. Do you think that
 should be the behaviour.?


 On 19-11-2013 15:44, John Ludlow wrote:

  In theory, just removing this line should do it:

Directory Id='DesktopFolder'  Name='PFiles'
  I haven't tried that though, so I'm not 100% sure. If not, you can also
 try a custom action which sets the directory.

 Generally, you should think twice before dropping files directly under c:\
 - most people like to keep that as clean as possible.


  On 19 November 2013 09:27, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 Thanks for the help...Just followed the steps...worked like a charm. The
 folder got installed into the program files folder and there were no errors
 thrown by Light.

 But I want the db directory to be created into a folder in say
 c:\[FolderName](c:\[FolderName]\Tort Demo). I have tried with like as
 mentioned earlier DesktopFolder, LocalAppdatafolder etc just to see if
 everything goes fine but i was getting the error mentioned in below mail.

 For those errors i landed on to
 http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-uninstall-shortcut-and-pass-all-the
 where it is said that the registry key is created to make 
 ICE18http://msdn2.microsoft.com/en-us/library/aa368942.aspx,
 ICE38 http://msdn2.microsoft.com/en-us/library/aa368961.aspx and 
 ICE48http://msdn2.microsoft.com/en-us/library/aa368977.aspxhappy. So can i 
 ignore those errors and move ahead?

 How can i get my directory created to c:\[FolderName]\  ?

 Regards,
 SuvraJyoti


 On 19-11-2013 14:05, John Ludlow wrote:

 That should have read:

  If you make this change, you can also remove the following line:

  RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]'
 Type='string' Value='' KeyPath='yes' /


 On 19 November 2013 08:34, John Ludlow john.ludlow...@gmail.com wrote:

 That's because of this:

Directory Id='DesktopFolder'  Name='PFiles'

  This will put files on the users desktop - are you sure that's what
 you want? (Hint: it's probably not) Change this to ProgramFilesFolder (or
 ProgramFiles64Folder). Remember how you were getting a similar error
 previously?

  If you make this change, you can also remove the following line:


  Alternatively, use a script to modify each component so it contains a
 registry entry.


 On 19 November 2013 07:50, Suvrajyoti Panda 
 suvrajyo...@contata.co.inwrote:

  Hi John/All,

 I have used the below commands:


 heat dir D:\Project\ESI\Code\trunk\db -cg trunkdb -gg -sfrag -dr
 TORTDEMO -out trunkdb.wxs
  candle TortEngineDemo.wxs trunkdb.wxs
 light -b D:\Project\ESI\Code\trunk\db -out TrunkDBDemo.msi
 TortEngineDemo.wixobj trunkdb.wixobj

 This does create the TrunkDBDemo.msi and when i run it it also creates
 the Tort Demo folder on the desktop and the db directory in which i can
 find all the files that were there in the source directory. The required
 registry entry is also created.
 The change i have done is added the part *-b
 D:\Project\ESI\Code\trunk\db  *to the Light command
 *. *
 But the Light does throw up some many errors such as :

 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(921) : error
 LGHT0204 :
 ICE38: Component

Re: [WiX-users] Referring to fragments

2013-11-18 Thread John Ludlow

 the fragment the right way. Please suggest
 how i need to refer to the fragment from my installer. I am really stuck
 and any help would be much appreciable. Let me know if you are on Skype,
 that would be helpful.

 Regards,
 SuvraJyoti






 Regards,
 SuvraJyoti

 On 15-11-2013 19:19, John Ludlow wrote:

 I think you're getting confused between two separate issues. If you're
 getting the ICE error, then that would stop the build from successfully
 completing. You may be using an out of date version of your installer.

 Because of that, I would suggest that you do the following

 1. Resolve the ICE issue. You suppress it so that it doesn't get run, but
 the better thing to do is usually to solve the error. In this case, that
 means add a registry entry to the component and mark it as KeyPath=yes.

 2. Determine whether your directory structure is getting added to your
 install. You can do this in a number of ways - using Orca.exe or performing
 an admin install are two of them. Based on your question, I can't see a
 reference to anything in the Fragment which contains the harvested
 directory structure, so I suspect that you need to add a reference to
 something in there.

 For example:

  Feature Id='Complete' Level='1'
ComponentRef Id='TORTDEMO' /
ComponentRef Id='cmpCB46AAB9A4F3EB62F8247A194B4BBB4B' /
  /Feature

 Once you've dealt with those issues, you may see WiX complain about other
 issues - for starters, your root DirectoryRef entry in that structure is
 missing an ID, so the structure won't have a valid parent which means MSI
 won't know where to put it.

 My advice would be to concentrate on getting a successful compilation, then
 work from there. Keep compiling regularly as you work. If you see a
 compilation failure, stop and deal with it. This makes it much easier to
 deal with issues as you discover them.

 Hope that helps


 On 15 November 2013 11:13, Suvrajyoti Panda suvrajyo...@contata.co.in 
 suvrajyo...@contata.co.inwrote:


  Hi,

 I have a fragment that i have created through Heat. Basically i want to
 create a db directory that has db files inside it through the installer.
 It has the structure as below:

 ?xml version=1.0 encoding=utf-8?
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
 http://schemas.microsoft.com/wix/2006/wi
  Fragment
  DirectoryRef Id=
  Directory Id= Name=db
  Component Id=cmpCB46AAB9A4F3EB62F8247A194B4BBB4B
 Guid={DE25A51B-AD43-4C74-8F84-9336AAC18BA0}
  File Id=fil8B6B2F5720D83AD50A3898087E4DADF1
 KeyPath=yes Source=SourceDir\alarm.db /
  /Component
   .. many components follow here
   
   
  .
  .
  .
  /Directory
  /DirectoryRef
  /Fragment
 /Wix

 My main WiX installer file is as below:

 ?xml version='1.0' encoding='windows-1252'?
 Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
Product Name='Tort Demo 1.0'
 Id='0A6A060C-20A5-4716-994D-BC728A904F27'
 UpgradeCode='3F665FE5-D9A9-4C9E-B260-7D54970C99F3'
  Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='Acme
 Ltd.'

  Package Id='*' Keywords='Installer' Description=Tort 1.0
 Installer Comments='Tort Ltd.' Manufacturer='ESI Ltd.'
InstallerVersion='300' Languages='1033' Compressed='yes'
 SummaryCodepage='1252' /

  Media Id='1' Cabinet='Tort.cab' EmbedCab='yes' DiskPrompt=CD-ROM
 #1 /
  Property Id='DiskPrompt' Value=Tort Demo Installation [1] /

  Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='PersonalFolder' Name='PFiles'
  Directory Id='TORTDEMO' Name='Tort Demo'
Component Id=TORTDEMO
 Guid=8D286AB1-8C00-4A88-A7EB-C83BB92C480A
  RemoveFolder Id='TORTDEMO' On='uninstall' /
/Component
  /Directory
/Directory
  /Directory

  Feature Id='Complete' Level='1'
ComponentRef Id='TORTDEMO' /
  /Feature

/Product
 *
 **  Fragment**
 **DirectoryRef Id=TORTDEMO**
 **/DirectoryRef**
 **  /Fragment*

 /Wix

 I have tried to reference as given in the bold, but the directory
 structure does not get created when i run the .msi installer an i am
 getting the error C:\Program Files (x86)\WiX Toolset
 v3.7\bin\TortEngineDemo.wxs(15) : error LGHT0
 204 : ICE38: Component TORTDEMO installs to user profile. It must use a
 registry
   key under HKCU as its KeyPath, not a file.

 Please help..

 Regards,
 Suvra Jyoti

 On 15-11-2013 16:28, uholeschak wrote:

  I have two burn bundles (with different UpgradeCodes)
 that contain the same MsiPackage, but with different versions (different
 ProductCode).
 When I install the first burn bundle all is working fine,
 but when installing the second bundle nothing is happening (the

  MsiPackage

  is not installed).
 Is there a way to force burn to update an existing MsiPackage?




 --
 View

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-18 Thread John Ludlow

Do those files exist at compilation time? They are C:\Program Files (x86)
paths, and your code doesn't specify a full path in File/@Source. I'm not
sure how it came up with that path, but it's probably wrong, since you are
likely building your application binaries in a build area.

You will need to either specify the -var argument to heat.exe with a
variable name (and tweak the value so that it matches correctly) or write
some build code to tweak the contents of this file.

Heat.exe can, with the correct arguments, give you some generated code you
can just plug into your project and go. Probably. In theory. If the planets
are all in the correct alignments and you've made the right sacrifices. In
practice, you should consider whether this kind of dynamic code generation
is really what you need.

Do the contents of that directory change without warning or beyond your
team's ability to keep up with the changes? If so, then this kind of code
generation is potentially a way around the issue, but ideally you should
reconsider the application design.

However, if this is more about generating code so you don't have to crank
it by hand, then I'd recommend taking the generated code and adding the
missing or incorrect attributes (possibly with PowerShell) and then take
that code as source. Further updates to this code can be done by hand.

Hope that helps


On 18 November 2013 11:18, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 Any updates on the below issue. I am still stuck there.

 Regards,
 Suvra Jyoti
  Original Message 
  Subject: Fwd: Re: [WiX-users] Referring to fragments  Date: Mon, 18 Nov
 2013 15:06:38 +0530  From: Suvrajyoti Panda 
 suvrajyo...@contata.co.insuvrajyo...@contata.co.in  To:
 John Ludlow john.ludlow...@gmail.com john.ludlow...@gmail.com



 Attaching the source files once again.

  Original Message   Subject: Re: [WiX-users] Referring to
 fragments  Date: Mon, 18 Nov 2013 15:04:31 +0530  From: Suvrajyoti Panda
 suvrajyo...@contata.co.in suvrajyo...@contata.co.in  To: John Ludlow
 john.ludlow...@gmail.com john.ludlow...@gmail.com  CC: General
 discussion about the WiX toolset. 
 wix-users@lists.sourceforge.netwix-users@lists.sourceforge.net

 Hi John,

 I did as you suggested. I was getting the error C:\Program Files (x86)\WiX
 Toolset v3.7\bin\TortEngineDemo.wxs(24) : error LGHT0
 094 : Unresolved reference to symbol 'Component:TORTDEMO' in section
 'Product:{5
 A1581BE-27C3-46A1-8699-4F1D642C97E0}'. So i changed the name to TORTDEMO
 instead of cmpTrunkDB earlier as below:

  Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='DesktopFolder' Name='PFiles'
 Directory Id='TORTDEMO' Name='Tort Demo'
   Component Id=*TORTDEMO*
 Guid=9D5FEECE-74FE-45A2-BD34-41562EC8ED16
 RemoveFolder Id='TORTDEMO' On='uninstall' /
 RegistryValue Root='HKCU'
 Key='Software\[Manufacturer]\[ProductName]' Type='string' Value=''
 KeyPath='yes' /
   /Component
 /Directory
   /Directory
 /Directory

 Now i am getting the below error.

 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(751) : error
 LGHT0103 :
 The system cannot find the file 'SourceDir\tortoptions.v2.db'.
 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(754) : error
 LGHT0103 :
 The system cannot find the file 'SourceDir\tortoptions.v3.db'.
 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(757) : error
 LGHT0103 :
 The system cannot find the file 'SourceDir\tortoptions.v4.db'.
 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(760) : error
 LGHT0103 :
 The system cannot find the file 'SourceDir\tortoptions.v5.db'.
 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(763) : error
 LGHT0103 :
 The system cannot find the file 'SourceDir\tortosedata.db'.
 C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs(766) : error
 LGHT0103 :

 Please suggest on the same.

 On 18-11-2013 14:24, John Ludlow wrote:

 Ah, I missed that.

  You need to create a reference in your feature to each component,
 because now you have components which aren't assigned to any feature, which
 means they would never be installed.

  Please try this:

  1. On your Heat.exe call, specify the -cg argument with a component name:

 heat dir D:\Project\ESI\Code\trunk\db -cg trunkdb -gg -sfrag -dr
 TORTDEMO -out trunkdb.wxs.

  This should add a component group with all the components in the output.
 The ID should be trunkdb, which you can reference in your Feature.

  2. Change your Feature element like so:

  Feature Id='Complete' Level='1'
   ComponentRef Id='TORTDEMO' /
ComponentGroupRef Id='trunkdb'/
  /Feature

  This should reference the component group created in Step #1, drawing
 all those components into that feature.

  At first glance, the registry entry you've created looks fine. I'd
 probably specify a value, but that's just me.


 On 18 November 2013 08:32, Suvrajyoti Panda suvrajyo

Re: [WiX-users] Fwd: Re: Referring to fragments

2013-11-18 Thread John Ludlow

Yeah I didn't explain that path thing very well. I was referring to this
path:

  C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs

This probably shouldn't be here. Best to keep this out of the WiX install
directory. If this is a file which is generated for every build, then
either use an intermediates folder in your build tree, or put it into the
%tmp% directory. This is probably because you're not specifying a full path
for the -out parameter.

I'm not entirely clear on why you're launching an installer from
CruiseControl - that seems a little weird to me. It sounds like you're
trying to use MSI to achieve a continuous deployment scenario, and it's not
really designed for that - is that what you're trying to do?

I've not actually used the heat -var argument, so the advice I can give you
will be limited. However, I believe that if you add -var:TrunkDbRootDir
to your heat command, it will generate something like this:

File Source=$(var.TrunkDbRootDir)\file.ext/

You will have to define that variable elsewhere, and it's up to you to make
sure that it points to the correct place so that the path is correct when
the variable is resolved. Someone with more experience of heat.exe might be
able to help you further.

Hope that helps


On 18 November 2013 14:36, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 When I are created the  trunkdb.wxs file i had ditected it to
 D:\Project\ESI\Code\trunk\db. These files exist now also and are part of
 the SVN source control. I do not get what you mean by C:\Program Files
 (x86) and I'm not sure how it came up with that path . I am just
 executing Light from the path C:\Program Files (x86)\WiX Toolset v3.7\bin
 where in my two source files are also placed(tortenginedemo.wxs and
 trunkdb.wxs). By File/@Source i guess you mean that as of now in the
 fragment the path is only SourceDIr. Let me know how we can do that.

 I need this to be dynamic in the sense that a batch file would execute
 that would create the directory *db** (*D:\Project\ESI\Code\trunk\db*). *The 
 WIX installer that needs to be created should install the “db”
 directories that is created by the batch file. Basically i need to execute
 the installer when the scroipts for cruise control are fired. The firing of
 the cruisecontrol script fires the installer as well through a batch file.

 This is the approach that has been decided as of now. In case you other
 pointers do let me know specially the You will need to either specify the
 -var argument to heat.exe with a variable name (and tweak the value so that
 it matches correctly) or write some build code to tweak the contents of
 this file. if this helps.

 Moreover it is not that the error is being shown foll all the files in the
 db directory . It is showing for about 150 files in the db directory. There
 are a total of 379 files in the same.

 Regards,
 SuvraJyoti


 On 18-11-2013 19:00, John Ludlow wrote:

  Do those files exist at compilation time? They are C:\Program Files
 (x86) paths, and your code doesn't specify a full path in File/@Source.
 I'm not sure how it came up with that path, but it's probably wrong, since
 you are likely building your application binaries in a build area.

 You will need to either specify the -var argument to heat.exe with a
 variable name (and tweak the value so that it matches correctly) or write
 some build code to tweak the contents of this file.

 Heat.exe can, with the correct arguments, give you some generated code you
 can just plug into your project and go. Probably. In theory. If the planets
 are all in the correct alignments and you've made the right sacrifices. In
 practice, you should consider whether this kind of dynamic code generation
 is really what you need.

  Do the contents of that directory change without warning or beyond your
 team's ability to keep up with the changes? If so, then this kind of code
 generation is potentially a way around the issue, but ideally you should
 reconsider the application design.

  However, if this is more about generating code so you don't have to
 crank it by hand, then I'd recommend taking the generated code and adding
 the missing or incorrect attributes (possibly with PowerShell) and then
 take that code as source. Further updates to this code can be done by hand.

  Hope that helps


 On 18 November 2013 11:18, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

  Hi John,

 Any updates on the below issue. I am still stuck there.

  Regards,
 Suvra Jyoti
  Original Message 
   Subject: Fwd: Re: [WiX-users] Referring to fragments  Date: Mon, 18
 Nov 2013 15:06:38 +0530  From: Suvrajyoti Panda
 suvrajyo...@contata.co.in suvrajyo...@contata.co.in  To: John Ludlow
 john.ludlow...@gmail.com john.ludlow...@gmail.com



 Attaching the source files once again.

  Original Message   Subject: Re: [WiX-users] Referring
 to fragments  Date: Mon, 18 Nov 2013 15:04:31 +0530  From: Suvrajyoti
 Panda suvrajyo

Re: [WiX-users] Referring to fragments

2013-11-15 Thread John Ludlow

I think you're getting confused between two separate issues. If you're
getting the ICE error, then that would stop the build from successfully
completing. You may be using an out of date version of your installer.

Because of that, I would suggest that you do the following

1. Resolve the ICE issue. You suppress it so that it doesn't get run, but
the better thing to do is usually to solve the error. In this case, that
means add a registry entry to the component and mark it as KeyPath=yes.

2. Determine whether your directory structure is getting added to your
install. You can do this in a number of ways - using Orca.exe or performing
an admin install are two of them. Based on your question, I can't see a
reference to anything in the Fragment which contains the harvested
directory structure, so I suspect that you need to add a reference to
something in there.

For example:

 Feature Id='Complete' Level='1'
   ComponentRef Id='TORTDEMO' /
   ComponentRef Id='cmpCB46AAB9A4F3EB62F8247A194B4BBB4B' /
 /Feature

Once you've dealt with those issues, you may see WiX complain about other
issues - for starters, your root DirectoryRef entry in that structure is
missing an ID, so the structure won't have a valid parent which means MSI
won't know where to put it.

My advice would be to concentrate on getting a successful compilation, then
work from there. Keep compiling regularly as you work. If you see a
compilation failure, stop and deal with it. This makes it much easier to
deal with issues as you discover them.

Hope that helps


On 15 November 2013 11:13, Suvrajyoti Panda suvrajyo...@contata.co.inwrote:

 Hi,

 I have a fragment that i have created through Heat. Basically i want to
 create a db directory that has db files inside it through the installer.
 It has the structure as below:

 ?xml version=1.0 encoding=utf-8?
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
  Fragment
  DirectoryRef Id=
  Directory Id= Name=db
  Component Id=cmpCB46AAB9A4F3EB62F8247A194B4BBB4B
 Guid={DE25A51B-AD43-4C74-8F84-9336AAC18BA0}
  File Id=fil8B6B2F5720D83AD50A3898087E4DADF1
 KeyPath=yes Source=SourceDir\alarm.db /
  /Component
   .. many components follow here
   
   
  .
  .
  .
  /Directory
  /DirectoryRef
  /Fragment
 /Wix

 My main WiX installer file is as below:

 ?xml version='1.0' encoding='windows-1252'?
 Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
Product Name='Tort Demo 1.0'
 Id='0A6A060C-20A5-4716-994D-BC728A904F27'
 UpgradeCode='3F665FE5-D9A9-4C9E-B260-7D54970C99F3'
  Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='Acme
 Ltd.'

  Package Id='*' Keywords='Installer' Description=Tort 1.0
 Installer Comments='Tort Ltd.' Manufacturer='ESI Ltd.'
InstallerVersion='300' Languages='1033' Compressed='yes'
 SummaryCodepage='1252' /

  Media Id='1' Cabinet='Tort.cab' EmbedCab='yes' DiskPrompt=CD-ROM
 #1 /
  Property Id='DiskPrompt' Value=Tort Demo Installation [1] /

  Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='PersonalFolder' Name='PFiles'
  Directory Id='TORTDEMO' Name='Tort Demo'
Component Id=TORTDEMO
 Guid=8D286AB1-8C00-4A88-A7EB-C83BB92C480A
  RemoveFolder Id='TORTDEMO' On='uninstall' /
/Component
  /Directory
/Directory
  /Directory

  Feature Id='Complete' Level='1'
ComponentRef Id='TORTDEMO' /
  /Feature

/Product
 *
 **  Fragment**
 **DirectoryRef Id=TORTDEMO**
 **/DirectoryRef**
 **  /Fragment*

 /Wix

 I have tried to reference as given in the bold, but the directory
 structure does not get created when i run the .msi installer an i am
 getting the error C:\Program Files (x86)\WiX Toolset
 v3.7\bin\TortEngineDemo.wxs(15) : error LGHT0
 204 : ICE38: Component TORTDEMO installs to user profile. It must use a
 registry
   key under HKCU as its KeyPath, not a file.

 Please help..

 Regards,
 Suvra Jyoti

 On 15-11-2013 16:28, uholeschak wrote:
  I have two burn bundles (with different UpgradeCodes)
  that contain the same MsiPackage, but with different versions (different
  ProductCode).
  When I install the first burn bundle all is working fine,
  but when installing the second bundle nothing is happening (the
 MsiPackage
  is not installed).
  Is there a way to force burn to update an existing MsiPackage?
 
 
 
 
  --
  View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-packages-in-different-burn-bundles-not-updated-tp7590668.html
  Sent from the wix-users mailing list archive at Nabble.com.
 
 
 --
  DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
  OAuth, Users, Roles, SQL,

Re: [WiX-users] Wix Newbie

2013-11-07 Thread John Ludlow

I'd recommend this book:

http://www.amazon.co.uk/WiX-3-6-Developers-Windows-Installer-ebook/dp/B009YW82A0/ref=sr_1_1?ie=UTF8qid=1383827565sr=8-1keywords=wix

It covers both Windows Installer using WiX, and bundles using burn and
custom bootstrapper applications.

On 6 November 2013 21:42, Nick Ramirez nickra...@hotmail.com wrote:

Are you just starting your journey with WiX? If you are, you might take a
step back from WPF user interfaces for a few days and dig into writing an
MSI file. Once you've got that, I'd read up on how to use Burn by itself,
using the UI that comes with the toolset. Here, I'm talking about just
writing a bundle file and chaining packages in it, etc. Then, once you've
got that down, move on to writing the WPF stuff, which may not even be
necessary for you once you've seen what a plain old MSI can do.

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

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models.
Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally disabling the Install Location control in a bundle

2013-10-29 Thread John Ludlow

Thanks Bob,

We'll continue to use the msistuff setup.exe bootstrapper for now, until we
find time to develop our own custom managed boostrapper application.

It'd probably be a useful feature to add in a future version of WiX.

Thanks again.

John


On 29 October 2013 01:32, Bob Arnson b...@joyofsetup.com wrote:

 On 26-Oct-13 05:15, John Ludlow wrote:
  I don't think the standard bootstapper application's theming is capable
 of
  that kind of customisation.
 That's correct. It would have to be a feature of WixStdBA.

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



 --
 Android is increasing in popularity, but the open development platform that
 developers love is also attractive to malware creators. Download this white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.
 http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally disabling the Install Location control in a bundle

2013-10-26 Thread John Ludlow

Thanks but that's not the behaviour I need. Perhaps my explanation wasn't
clear.

The behaviour that I need is that when a particular registry entry exists
the install location control is disabled so that the user cannot change the
install directory. If the registry entry is not present then they can
change the installation directory.

I don't think the standard bootstapper application's theming is capable of
that kind of customisation. I was hoping for a variable called
DisableInstallDirControl or something like that which we could set during
install depending on whether we found that registry entry or not.

Thanks anyway
On 26 Oct 2013 03:35, santhosh yalamuri santhu@gmail.com wrote:

 When the user selects another folder the variable is updated.
 On 25 Oct 2013 00:47, John Ludlow john.ludlow...@gmail.com wrote:

  Thanks for that
 
  Does that prevent the user from selecting another folder?
 
  Thanks again
 
 
  On 24 October 2013 17:10, santhosh yalamuri santhu@gmail.com
 wrote:
 
   We have to set InstallFolder variable in burn bootstrapper.
  
   Example:   Variable Name=InstallFolder
 Type=string
 Value=/
  
  
   On Thu, Oct 24, 2013 at 3:31 PM, John Ludlow john.ludlow...@gmail.com
   wrote:
  
Hi all,
   
We have an MSI for a client application which, if you have the server
installed on the same system, must be installed in the same directory
  as
the server.
   
During the MSI install wizard for the client application, we use
   AppSearch
to detect whether the server component is installed. If it is, we
 find
   out
where that is, and set INSTALLDIR to that, then set a property which
   causes
the Browse button on the Install Location page to be disabled, using
  the
Condition element under that control.
   
We've been evaluating burn as a bootstrapper, but we'd like to
  replicate
this behaviour and haven't been able to find a way. At this point, we
   don't
want to develop a full custom bootstrapper application for this
   particular
install. (We're happy tweaking the theme though)
   
Is there a way to replicate the above behavior using the standard
bootstrapper application?
   
We're on Wix 3.6
   
Thanks
   
   
  
 
 --
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
  most
from
the latest Intel processors and coprocessors. See abstracts and
  register
   
   
  
 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
   
  
  
  
   --
   Regards,
  
   Santhosh S Yalamuri
  
  
 
 --
   October Webinars: Code for Performance
   Free Intel webinars can help you accelerate application performance.
   Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
 most
   from
   the latest Intel processors and coprocessors. See abstracts and
 register
  
  
 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users
  
 
 
 --
  October Webinars: Code for Performance
  Free Intel webinars can help you accelerate application performance.
  Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
  from
  the latest Intel processors and coprocessors. See abstracts and register
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced

[WiX-users] Conditionally disabling the Install Location control in a bundle

2013-10-24 Thread John Ludlow

Hi all,

We have an MSI for a client application which, if you have the server
installed on the same system, must be installed in the same directory as
the server.

During the MSI install wizard for the client application, we use AppSearch
to detect whether the server component is installed. If it is, we find out
where that is, and set INSTALLDIR to that, then set a property which causes
the Browse button on the Install Location page to be disabled, using the
Condition element under that control.

We've been evaluating burn as a bootstrapper, but we'd like to replicate
this behaviour and haven't been able to find a way. At this point, we don't
want to develop a full custom bootstrapper application for this particular
install. (We're happy tweaking the theme though)

Is there a way to replicate the above behavior using the standard
bootstrapper application?

We're on Wix 3.6

Thanks
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally disabling the Install Location control in a bundle

2013-10-24 Thread John Ludlow

Thanks for that

Does that prevent the user from selecting another folder?

Thanks again


On 24 October 2013 17:10, santhosh yalamuri santhu@gmail.com wrote:

 We have to set InstallFolder variable in burn bootstrapper.

 Example:   Variable Name=InstallFolder
   Type=string
   Value=/


 On Thu, Oct 24, 2013 at 3:31 PM, John Ludlow john.ludlow...@gmail.com
 wrote:

  Hi all,
 
  We have an MSI for a client application which, if you have the server
  installed on the same system, must be installed in the same directory as
  the server.
 
  During the MSI install wizard for the client application, we use
 AppSearch
  to detect whether the server component is installed. If it is, we find
 out
  where that is, and set INSTALLDIR to that, then set a property which
 causes
  the Browse button on the Install Location page to be disabled, using the
  Condition element under that control.
 
  We've been evaluating burn as a bootstrapper, but we'd like to replicate
  this behaviour and haven't been able to find a way. At this point, we
 don't
  want to develop a full custom bootstrapper application for this
 particular
  install. (We're happy tweaking the theme though)
 
  Is there a way to replicate the above behavior using the standard
  bootstrapper application?
 
  We're on Wix 3.6
 
  Thanks
 
 
 --
  October Webinars: Code for Performance
  Free Intel webinars can help you accelerate application performance.
  Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
  from
  the latest Intel processors and coprocessors. See abstracts and register
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 



 --
 Regards,

 Santhosh S Yalamuri

 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Set WixToolPath from another .Proj file

2013-10-22 Thread John Ludlow

Through a mixture of trial and error we identified 6 properties that we
needed to provide. We actually do this on the msbuild command line which
calls our solution build rather than a .proj file but the concept is the
same.

  WixToolPath=g:\BuildSoftware\Wixv3.6.3303.0\
  WixTasksPath=g:\BuildSoftware\Wixv3.6.3303.0\\WixTasks.dll
  ReferencePath=g:\BuildSoftware\Wixv3.6.3303.0\
  WixTargetsPath=g:\BuildSoftware\Wixv3.6.3303.0\wix.targets
  WixCATargetsPath=g:\BuildSoftware\Wixv3.6.3303.0\sdk\wix.ca.targets
  WixSdkPath=g:\BuildSoftware\Wixv3.6.3303.0\sdk\

Simply add these into your Properties list (semicolon delimited)

Depending on what you're doing and how you have wix organised you might not
need all of the properties. Our experience suggests the following (though
if someone knows better, feel free to correct me!):

Always required:
  WixToolPath
  WixTasksPath
  WixTargetsPath

Required when using C# DTF Custom Actions:
  ReferencePath
  WixCATargetsPath
  WixSdkPath

Hope that helps

John




On 22 October 2013 11:45, Ilir Bekteshi ilir...@gmail.com wrote:

 How would i set WixToolPath, WixTargetsPath and WiXTasks path from another
 proj file (not wixproj)?

 Right know i have another project.proj with
 Target Name=AfterBuild
  Message Text=$(Version)/
 MSBuild Projects=$(WixMsiDir)Desktop.wixproj
 Properties=Version=$(Version) Targets=Rebuild /
  /Target

 But would like to set paths to Wix binaries from this proj so that when
 it's build from cmd (build server) it uses Wix that i have checked in, and
 when i build from studio i use the installed Wix.

 Thanks

 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Installer using WPF

2013-09-19 Thread John Ludlow

Wix's own bootstrapper is done this way, so you can use that as a sample.

There's also a tutorial with code samples here:
http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/
(uses
the MVVM-light framework).


On 19 September 2013 10:23, Ravishankar 
ravishankar.krishnasw...@idsnext.com wrote:

 Hi,
 I need to create a WiX installer, but dont need to use the WiX
 UI(Installdir/FeatureTree/Mondo)
 Is it possible to create UI dialog using WPF(vb.net)

 If anyone has code samples, please share it.

 Thanks and Regards
 Ravi



 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX Installer using WPF

2013-09-19 Thread John Ludlow

Here's the the link to the publisher's page for that book

http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book


On 19 September 2013 11:09, Ravishankar 
ravishankar.krishnasw...@idsnext.com wrote:

 Hi Kobus,
 Please send me the Link.

 Thanks and Regards
 Ravi
 On 9/19/2013 3:30 PM, Kobus Botha wrote:
  Hi Ravi,
 
  It is indeed possible to create custom WPF UI by using Wix's Burn engine.
 
  The code samples are in C#, but Chapter 16 of WiX 3.6: A Developer's
  Guide to Windows Installer XML by Nick Ramirez will tell you
  everything you need to know.
 
  Hope that helps.
  Kobus
 
  On 19 September 2013 11:23, Ravishankar
  ravishankar.krishnasw...@idsnext.com wrote:
  Hi,
  I need to create a WiX installer, but dont need to use the WiX
  UI(Installdir/FeatureTree/Mondo)
  Is it possible to create UI dialog using WPF(vb.net)
 
  If anyone has code samples, please share it.
 
  Thanks and Regards
  Ravi
 
 
 
 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
  1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
  2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
  Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
  1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
  2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
  Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users




 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Execution order issue

2013-09-18 Thread John Ludlow

Be aware that if your custom action gets any properties, then you'll need
to push those through by using CustomActionData.


On 18 September 2013 19:07, Phil Wilson phildgwil...@gmail.com wrote:

 Your copy custom action is immediate - that means it will always happen
 before any files are actually copied. If you need it to run after
 InstallFiles has physically copied files it should be marked deferred.

 Phil Wilson


 On Tue, Sep 17, 2013 at 10:45 PM, Kai Peters kpet...@otaksoft.com wrote:

  Hi all,
 
  hopefully my last newbie issue for some time (all previous issues have
  been resolved thanks to the
  great help from this list - thanks again!):
 
  I deploy a CA CA_CopyMasterIni to copy a configuration file template
  from location A to location B
  if my customer's IT dept. has dropped one in location A prior to
  installing my MSI.
 
  This works as expected.
 
  However, as this process is optional I always need to install a default
  template file (as shown
  below).
 
  The issue is that InstallFiles happens after my CA and thus the customer
  provided template gets
  overwritten if it was supplied. I had added NeverOverwrite=yes to the
  template component in hopes
  that this would prevent this overwriting but it does not...
 
  If I change sequences in the InstallExecute table and push my CA after
  InstallFiles, the CA does not
  run.
 
  How can I achieve my goal?
 
  As always, thanks for any pointers,
 
  K.
 
 
 
 
 
   DirectoryRef Id=AppDataProductLineFolder
Component Id=COMP_IniTemplate Guid=* NeverOverwrite=yes 
   File  Id=FILE_IniTemplate
   Name=Quadra.ini
  KeyPath=yes
  Vital=no
   Source=$(var.MiscDir)\Quadra.ini /
/Component
   /DirectoryRef
 
 
 
 
  !-- this CA copies an inifile template provided by customer's IT
 from
  COMMON_APPDATA to final
  destination --
  CustomAction
  Id=CA_CopyMasterIni
  BinaryKey=BIN_InstallHelperDLL
  DllEntry=CopyTestMasterInifile
  Execute=immediate
  Return=check
  HideTarget=no
  Impersonate=yes /
 
 
  !-- schedule custom actions --
  InstallExecuteSequence
  !-- back up  Quadra.ini before old version is
  uninstalled  --
  Custom Action=CA_BackupGlobalIni
   After=InstallValidate /
 
  !-- restore Quadra.ini after the old version has
  been uninstalled --
  Custom Action=CA_RestoreGlobalIni
  After=RemoveExistingProducts /
 
  !-- ... --
  Custom Action=CA_CopyMasterIniAfter=CA_RestoreGlobalIni
 /
  /InstallExecuteSequence
 
 
 
 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
  1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
  SharePoint
  2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
  includes
  Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to remove custom application with malformed uninstall package

2013-08-29 Thread John Ludlow

Actually there's not much difference as you get to the same place anyway. A
version of the MSI in your cache that doesn't have the error and can be
upgraded.

The issue you might run into with modifying your package and doing a minor
upgrade is that if you sign your MSIs you won't just be able to edit it
directly. The cached MSI is less likely to be signed although that does
depend a lot on how your package is put together.

From my own experience, our packages are signed by the build (so can't just
be edited using orca) but the cached ones have the file payload stripped
and so are not signed. Your mileage may vary.

If this made it into the wild then you would need to issue either a patch.
Going the minor upgrade route is probably not going to scale very well if
you have multiple versions with this error in the wild as major upgrades as
you would need to make sure each customer got the correct fixed package
for their version. A patch gives you that validation very cheaply and can
target multiple versions as well, not to mention the fact that it's a lot
smaller so it can be downloaded easier.

However it doesn't sound as if any instance of the error made it into the
wild so it's all OK.
On Aug 29, 2013 12:24 AM, Hoover, Jacob jacob.hoo...@greenheck.com
wrote:

 +1 for fixing your source msi an recaching the msi. I wouldn't recommend
 modifying the cached version, especially if this bug made it into the wild.


 On Aug 28, 2013, at 11:18 AM, Simon Gerhold simon.gerh...@cetis.si
 wrote:

  Thanks, good to know :)
 
  Simon Gerhold, razvojni inženir / Development Engineer
  Cetis d.d., Čopova 24, 3000 Celje, Slovenia - EU, T: +386 3 4278 785,
 F: +386 3 4278 651, www.cetis.si
 
 
  -Original Message-
  From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
  Sent: Wednesday, August 28, 2013 5:21 PM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] How to remove custom application with malformed
 uninstall package
 
  Coincidentally I just read this section of Robert Dickau's tips page
 http://www.robertdickau.com/msi_tips.html#unfix
 
 
  -Original Message-
  From: Simon Gerhold [mailto:simon.gerh...@cetis.si]
  Sent: Wednesday, August 28, 2013 2:14 AM
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] How to remove custom application with malformed
 uninstall package
 
  I created a setup project with Wix Toolset, which does something like
 this:
 
   *   install (into ProgramFiles/MyApp, Desktop shortcut, StartMenu,...)
   *   create a folder ProgramFiles/MyApp/InstallFolder
   *   create some files in the folder ProgramFiles/MyApp/InstallFolder
   *   run a powershell script, which installs some COM+ components
  In the ProgramFiles/MyApp/InstallFolder is also a powershell script,
 which removes my COM+ applications (regsvcs /u). This script is executed as
 a custom action on uninstall. But here I made a mistake - the custom action
 had the attribute After=RemoveFiles (it should of course be
 Before=RemoveFiles). Now when I try to uninstall on my application, the
 uninstall process terminates with the exception There is a problem with
 this Windows installer package. A program run as part of the setup did not
 finish as expected. Contact your support personnel or package vendor.. The
 same exception occurs if I try to install/repair/change my application...
  Is there any possibility to uninstall my application without the last
 (faulty) custom action? Or to 'overinstall' it somehow?
  Simon
 
 
  Simon Gerhold, razvojni inženir / Development Engineer
  Cetis d.d., Čopova 24, 3000 Celje, Slovenia - EU, T: +386 3 4278 785,
 F: +386 3 4278 651, www.cetis.sihttp://www.cetis.si/
 
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
  Discover the easy way to master current and previous Microsoft
 technologies
  and advance your career. Get an incredible 1,500+ hours of step-by-step
  tutorial videos with LearnDevNow. Subscribe today and save!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
  Discover the easy way to master current and previous Microsoft
 technologies
  and advance your career. Get an incredible 1,500+ hours of step-by-step
  tutorial videos with LearnDevNow. Subscribe today and save!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix]: Copy the INI file to local temp folder before Install Files action (MSI action)

2013-08-29 Thread John Ludlow

If the file is packaged inside the MSI, how would anything copy it before
the InstallFiles action?

The only scenario that makes sense here (as far as I can see) is that
you're in an upgrade situation, and you want to copy the version of the
file you're upgrading from to the temp folder and read some information
from it.

Is that the case or are you in some other scenario? You're going to have to
help us understand your situation if we're going to be able to help you.


On 29 August 2013 08:22, ak m wixak...@gmail.com wrote:

 Could anyone help me on this?


 On Mon, Aug 26, 2013 at 10:45 AM, ak m wixak...@gmail.com wrote:

  File is packaged in MSI. INI file contains not only Model information but
  also about the port information etc...
 
  Basically this INI file is used for silent installation
 
  Anil
 
 
  On Sat, Aug 24, 2013 at 12:24 AM, Phil Wilson phildgwil...@gmail.com
 wrote:
 
  Exactly where is this ini file? It doesn't sound like it's actually
  packaged in the MSI file. Do you actually need the ini file or just the
  model number out of it?
 
  There's the  DiFX framework for installing drivers - that might be
 useful.
 
 
 
 http://msdn.microsoft.com/en-us/library/windows/hardware/ff537782(v=vs.85).aspx
 
  Phil Wilson
 
 
  On Fri, Aug 23, 2013 at 7:23 AM, ak m wixak...@gmail.com wrote:
 
   Dear All,
  
   when user clicks MSI,
   1. Copy the INI file to local temp folder before Install Files action
  (MSI
   action)
   2. Get the model information from INI
   3. Install the printer driver
  
   Could any one help me on this?
  
   Thanks in Advance...
  
   Anil
  
  
 
 --
   Introducing Performance Central, a new site from SourceForge and
   AppDynamics. Performance Central is your source for news, insights,
   analysis and resources for efficient Application Performance
 Management.
   Visit us today!
  
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users
  
 
 
 --
  Introducing Performance Central, a new site from SourceForge and
  AppDynamics. Performance Central is your source for news, insights,
  analysis and resources for efficient Application Performance Management.
  Visit us today!
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] stop a service before uninstall

2013-08-29 Thread John Ludlow

Is the issue that the FilesInUse dialog is popping up before your service
is stopped and declaring files in use when those files will be unlocked
when the service stops?

It's unfortunate but all the information related to whether you are doing a
removal or not is discovered at that point. In theory you could have an
unconditioned (or conditioned as NOT UPGRADINGPRODUCTCODE) immediate custom
action which tries to shut down the service before InstallValidate in the
exec sequence (and either does nothing or fails silently if the service
isn't there, because it will be run on install, uninstall, repair, modify,
you name it).

The problem you have here, however is that this is before you get UAC
elevation and stopping a service is an elevated action. You'd need to
provide a bootstrapper, and have it elevate your entire install process. It
gets a little messy.


On 29 August 2013 13:26, Alain Forget afor...@cmu.edu wrote:

 Why aren't you using the ServiceInstall element to install your service?
 If there is any way at all to use it, instead of a CA, I think most of us
 would strongly recommend it. At the very leat, you'll eaily be able to stop
 your service before uninstall.

 -Original Message-
 From: nkshirsagar [mailto:nkshirsa...@gmail.com]
 Sent: Thursday, August 29, 2013 08:19
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] stop a service before uninstall

 I install a windows service as a custom action during the install. During
 uninstall, I want to remove this service before the filesinUse dialogbox
 pops up.

 My condition is REMOVE=ALL for the uninstallation script to run, and I
 read on

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa371626(v=vs.85).aspx
 that any custom action that depends on REMOVE=ALL must be sequenced after
 the InstallValidate action

 Can anyone help me stop the process cleanly through WIX through a custom
 action before the filesInUse pops up?





 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/stop-a-service-before-uninstall-tp7588564.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component Rules

2013-08-29 Thread John Ludlow

Well, it probably won't do what you're expecting. By the time RemoveFiles
runs, the install has already decided it won't install those files, so what
will most likely happen is it will remove the file but not install the new
version.

A trick (well, a horrible hack, really) I've used is called version lying.
See this SO post:
http://stackoverflow.com/questions/5542841/how-to-force-file-replacement-on-msi-upgrade.
This does cause issues with patching, however.


On 29 August 2013 14:00, tyler.w.r...@accenture.com wrote:

 If I add a RemoveFile/ to an existing component for a minor upgrade will
 that violate the component rules? As in one of our minor upgrades a
 customer ran into a problem of some .js and .xsl files not getting upgraded
 because they were modified by the version control system they put them in
 after they install it. So I wanted to add the RemoveFile/ to force the
 installer to upgrade them everytime.

 Tyler Reid | Operations and Infrastructure | Accenture Software | PC
 Insurance
 1807 Jones Street | Bolivar, MO 65613| USA
 Office: +cc.xxx.xxx. | Fax: 417.777.3792
 E-Mail: tyler.w.r...@accenture.commailto:tyler.w.r...@accenture.com |
 www.accenture.com/pcsoftwarehttp://www.accenture.com/pcsoftware



 
 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise confidential information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the e-mail by you is prohibited.

 Where allowed by local law, electronic communications with Accenture and
 its affiliates, including e-mail and instant messaging (including content),
 may be scanned by our systems for the purposes of information security and
 assessment of internal compliance with Accenture policy.


 __

 www.accenture.com

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] stop a service before uninstall

2013-08-29 Thread John Ludlow

Well, it wouldn't because the REINSTALL property is set during repair and
you're conditioning on NOT REINSTALL.


On 29 August 2013 14:19, nkshirsagar nkshirsa...@gmail.com wrote:

 Hi John,

 I'm doing it this way as of now ..

 InstallExecuteSequence
   Custom Action=RunInstallScript After=InstallFiles NOT
 Installed/Custom
 /InstallExecuteSequence
 InstallExecuteSequence
   Custom Action='BeforeUninstall' Before='InstallValidate'Installed
 AND (NOT REINSTALL)/Custom
 /InstallExecuteSequence
 CustomAction Id=RunInstallScript ExeCommand=cmd /c
 install-solidfireprovider.cmd Directory=INSTALLFOLDER Execute=deferred
 Return=check/
 CustomAction Id=BeforeUninstall ExeCommand=cmd /c
 uninstall-solidfireprovider.cmd Directory=INSTALLFOLDER
 Execute=immediate Return=check/

 The only problem is repair doesnt execute the uninstall script, so the
 filesinUse pops up during repair. Otherwise, I dont see it during uninstall
 because I guess my uninstall CA gets called before Install Validate, which
 is what I want.



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/stop-a-service-before-uninstall-tp7588564p7588570.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component Rules

2013-08-29 Thread John Ludlow

As long as there is an appropriate file to use, I agree, although really it
has the same result. It wouldn't be appropriate to make them a companion of
a file they're unrelated to as that would introduce a bogus dependency and
if that other file ever disappeared, then you could introduce some nasty
issues.


On 29 August 2013 14:26, John Cooper jocoo...@jackhenry.com wrote:

 A better way to do that would be to make them CompanionFile's with a
 versioned assembly.

 --
 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: tyler.w.r...@accenture.com [mailto:tyler.w.r...@accenture.com]
 Sent: Thursday, August 29, 2013 8:01 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Component Rules

 If I add a RemoveFile/ to an existing component for a minor upgrade will
 that violate the component rules? As in one of our minor upgrades a
 customer ran into a problem of some .js and .xsl files not getting upgraded
 because they were modified by the version control system they put them in
 after they install it. So I wanted to add the RemoveFile/ to force the
 installer to upgrade them everytime.

 Tyler Reid | Operations and Infrastructure | Accenture Software | PC
 Insurance
 1807 Jones Street | Bolivar, MO 65613| USA
 Office: +cc.xxx.xxx. | Fax: 417.777.3792
 E-Mail: tyler.w.r...@accenture.commailto:tyler.w.r...@accenture.com |
 www.accenture.com/pcsoftwarehttp://www.accenture.com/pcsoftware



 
 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise confidential information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the e-mail by you is prohibited.

 Where allowed by local law, electronic communications with Accenture and
 its affiliates, including e-mail and instant messaging (including content),
 may be scanned by our systems for the purposes of information security and
 assessment of internal compliance with Accenture policy.


 __

 www.accenture.com

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft
 technologies and advance your career. Get an incredible 1,500+ hours of
 step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 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.



 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] stop a service before uninstall

2013-08-29 Thread John Ludlow

Check the logs. That should tell you what REMOVE and REINSTALL are being
set to, and when they are being set. Look for lines like this:

MSI (s) (04:4C) [05:39:56:736]: Command Line: REMOVE=ALL
CURRENTDIRECTORY=C:\Windows\system32 CLIENTUILEVEL=2 CLIENTPROCESSID=1768

or this:

MSI (s) (64:48) [06:52:15:113]: Command Line: REINSTALL=ALL
REINSTALLMODE=pecms CURRENTDIRECTORY=Z:\Tools\11.0\out\en CLIENTUILEVEL=2
CLIENTPROCESSID=2752

or this:

MSI (s) (64:48) [06:52:15:113]: PROPERTY CHANGE: Adding REMOVE property.
Its value is 'ALL'.

or this:

MSI (s) (64:48) [06:52:15:113]: PROPERTY CHANGE: Adding REINSTALL property.
Its value is 'ALL'.


On 29 August 2013 14:39, nkshirsagar nkshirsa...@gmail.com wrote:

 I guess its OK for the message to POPup during repair because it restarts
 the
 service automatically.

 just wondering why I could do it this way, but not with REMOVE=ALL
 condition



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/stop-a-service-before-uninstall-tp7588564p7588576.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component Rules

2013-08-29 Thread John Ludlow

Of course it's all just nasty hacks. Really, we want away to advise Windows
Installer on a per-file basis how we want particular files to be compared.

@Microsoft: Hint, hint! :)


On 29 August 2013 14:50, John Cooper jocoo...@jackhenry.com wrote:

 Agreed.  When I need to do this, I make the non-versioned file a
 CompanionFile of the assembly which has the API which consumes those files.
  At least for WCF web services, that works pretty well.

 --
 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: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Thursday, August 29, 2013 8:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Component Rules

 As long as there is an appropriate file to use, I agree, although really
 it has the same result. It wouldn't be appropriate to make them a companion
 of a file they're unrelated to as that would introduce a bogus dependency
 and if that other file ever disappeared, then you could introduce some
 nasty issues.


 On 29 August 2013 14:26, John Cooper jocoo...@jackhenry.com wrote:

  A better way to do that would be to make them CompanionFile's with a
  versioned assembly.
 
  --
  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: tyler.w.r...@accenture.com [mailto:tyler.w.r...@accenture.com]
  Sent: Thursday, August 29, 2013 8:01 AM
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Component Rules
 
  If I add a RemoveFile/ to an existing component for a minor upgrade
  will that violate the component rules? As in one of our minor upgrades
  a customer ran into a problem of some .js and .xsl files not getting
  upgraded because they were modified by the version control system they
  put them in after they install it. So I wanted to add the
  RemoveFile/ to force the installer to upgrade them everytime.
 
  Tyler Reid | Operations and Infrastructure | Accenture Software | PC
  Insurance
  1807 Jones Street | Bolivar, MO 65613| USA
  Office: +cc.xxx.xxx. | Fax: 417.777.3792
  E-Mail: tyler.w.r...@accenture.commailto:tyler.w.r...@accenture.com
  | www.accenture.com/pcsoftwarehttp://www.accenture.com/pcsoftware
 
 
 
  
  This message is for the designated recipient only and may contain
  privileged, proprietary, or otherwise confidential information. If you
  have received it in error, please notify the sender immediately and
  delete the original. Any other use of the e-mail by you is prohibited.
 
  Where allowed by local law, electronic communications with Accenture
  and its affiliates, including e-mail and instant messaging (including
  content), may be scanned by our systems for the purposes of
  information security and assessment of internal compliance with
 Accenture policy.
 
 
  __
  
 
  www.accenture.com
 
  --
   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
  2012, more!
  Discover the easy way to master current and previous Microsoft
  technologies and advance your career. Get an incredible 1,500+ hours
  of step-by-step tutorial videos with LearnDevNow. Subscribe today and
 save!
  http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.c
  lktrk ___
  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.
 
 
 
  --
   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
  2012, more!
  Discover the easy way to master current and previous Microsoft
  technologies and advance your career. Get an incredible 1,500+ hours
  of step-by-step tutorial videos with LearnDevNow. Subscribe today and
 save!
  http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.c
  lktrk ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component Rules

2013-08-29 Thread John Ludlow

Interesting. My experience with that in the past (I tried to use it to
solve a similar problem) was that it didn't work because the decision about
whether to install a particular file was made in the script generation
phase (where immediate actions run) but RemoveFile runs after that. But
that was quite a long time ago (before 2011 I think) so it's possible it
was fixed in later version of Windows Installer.

If it works for you and you test it on all supported platforms then I can't
see why you can't use that method.

Also, thinking about it now, putting the InstallExecute action after
RemoveFiles may also get around that issue.

On 29 August 2013 15:28, tyler.w.r...@accenture.com wrote:

@John Ludlow: Ok I was following what I found in a wix email chain by Chad
Peterson from 2011. The post is below as well as the url to the entire
email chain.
Another option is to use the RemoveFile/ element tied to the same
Component as your File/ element. This will always clear out the
existing file prior to the current install writing the new one. Works
for rollback and uninstall.

Component Id=Filetxt DiskId=1 Guid=someguid
RemoveFile Id=Remove_Filetxt Name=File.txt On=install /
File Id=Filetxt Name=File.txt Source=.\data\File.txt /
/Component

The RemoveFiles action is always scheduled before the InstallFiles
action by default, so as long as you don't change that sequence in
InstallExecuteSequence then it should work fine. I consider this the
functional equivalent of the InstallShield Always Overwrite setting.

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html

@John Cooper: I am thinking we had some troubles with multi instance and
companion files in the past and have since removed them all from any of our
installs, but I wasn't around for that conversation and nobody seems to
remember why so I will give that a try thank you. Speaking of that though
would that violate the Component rules for a minor upgrade?

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidential information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and
its affiliates, including e-mail and instant messaging (including content),
may be scanned by our systems for the purposes of information security and
assessment of internal compliance with Accenture policy.

www.accenture.com

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component Rules

2013-08-29 Thread John Ludlow

Yeah actually that's quite nice.


On 29 August 2013 18:50, John Cooper jocoo...@jackhenry.com wrote:

 I like that.  A little table-driven touch custom action.

 --
 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: Phil Wilson [mailto:phildgwil...@gmail.com]
 Sent: Thursday, August 29, 2013 12:30 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Component Rules

 If they're not being replaced because of the file modification rules, then
 you could write a custom action to make the creationdate and modifydate
 identical, and run it early before InstallValidate.

 Phil Wilson


 On Thu, Aug 29, 2013 at 7:00 AM, John Ludlow john.ludlow...@gmail.com
 wrote:

  Of course it's all just nasty hacks. Really, we want away to advise
  Windows Installer on a per-file basis how we want particular files to be
 compared.
 
  @Microsoft: Hint, hint! :)
 
 
  On 29 August 2013 14:50, John Cooper jocoo...@jackhenry.com wrote:
 
   Agreed.  When I need to do this, I make the non-versioned file a
   CompanionFile of the assembly which has the API which consumes those
  files.
At least for WCF web services, that works pretty well.
  
   --
   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: John Ludlow [mailto:john.ludlow...@gmail.com]
   Sent: Thursday, August 29, 2013 8:35 AM
   To: General discussion for Windows Installer XML toolset.
   Subject: Re: [WiX-users] Component Rules
  
   As long as there is an appropriate file to use, I agree, although
   really it has the same result. It wouldn't be appropriate to make
   them a
  companion
   of a file they're unrelated to as that would introduce a bogus
   dependency and if that other file ever disappeared, then you could
   introduce some nasty issues.
  
  
   On 29 August 2013 14:26, John Cooper jocoo...@jackhenry.com wrote:
  
A better way to do that would be to make them CompanionFile's with
a versioned assembly.
   
--
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: tyler.w.r...@accenture.com
[mailto:tyler.w.r...@accenture.com]
Sent: Thursday, August 29, 2013 8:01 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Component Rules
   
If I add a RemoveFile/ to an existing component for a minor
upgrade will that violate the component rules? As in one of our
minor upgrades a customer ran into a problem of some .js and .xsl
files not getting upgraded because they were modified by the
version control system they put them in after they install it. So
I wanted to add the RemoveFile/ to force the installer to upgrade
 them everytime.
   
Tyler Reid | Operations and Infrastructure | Accenture Software |
PC Insurance
1807 Jones Street | Bolivar, MO 65613| USA
Office: +cc.xxx.xxx. | Fax: 417.777.3792
E-Mail:
tyler.w.r...@accenture.commailto:tyler.w.r...@accenture.com
| www.accenture.com/pcsoftwarehttp://www.accenture.com/pcsoftware
| 
   
   
   

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidential information. If
you have received it in error, please notify the sender
immediately and delete the original. Any other use of the e-mail by
 you is prohibited.
   
Where allowed by local law, electronic communications with
Accenture and its affiliates, including e-mail and instant
messaging (including content), may be scanned by our systems for
the purposes of information security and assessment of internal
compliance with
   Accenture policy.
   
   
__


   
www.accenture.com
   
--

 Learn the latest--Visual Studio 2012, SharePoint 2013,
SQL 2012, more!
Discover the easy way to master current and previous Microsoft
technologies and advance your career. Get an incredible 1,500+
hours of step-by-step tutorial videos with LearnDevNow. Subscribe
today and
   save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/os
tg.c lktrk ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix

Re: [WiX-users] How to remove custom application with malformed uninstall package

2013-08-28 Thread John Ludlow

You have a couple of options:

Firstly, there's the MSI Cleanup Utility

http://gallery.technet.microsoft.com/MSI-cleanup-utility-3889c8db

This is an old tool which I thought had been retired, but it's come in very
handy. Note that this will not perform any uninstall operations or any MSI
logic at all. It basically hunts round the MSI registry for evidence of
your install and removes it. Any of your own registry entries or files will
not be removed.

But it's good for cleaning up a broken install.

Secondly, there's it's younger sibling, in the form of a FixIt
troubleshooter:

http://support.microsoft.com/mats/Program_Install_and_Uninstall

This will scan for installs it thinks have problems, ask you a few
questions, then do pretty much the same as the cleanup utility above,
though it's supposed to do a more intelligent job.

Thirdly, you can find the appropriate MSI in the c:\windows\installer
cache, remove the offending action from the sequence using orca.exe and
then try to uninstall it again.

Lastly, I know some people who swear by CCleaner for this kind of thing:
http://www.piriform.com/ccleaner

Hope one of those suggestions helps.

John


On 28 August 2013 10:13, Simon Gerhold simon.gerh...@cetis.si wrote:

 I created a setup project with Wix Toolset, which does something like this:

   *   install (into ProgramFiles/MyApp, Desktop shortcut, StartMenu,...)
   *   create a folder ProgramFiles/MyApp/InstallFolder
   *   create some files in the folder ProgramFiles/MyApp/InstallFolder
   *   run a powershell script, which installs some COM+ components
 In the ProgramFiles/MyApp/InstallFolder is also a powershell script, which
 removes my COM+ applications (regsvcs /u). This script is executed as a
 custom action on uninstall. But here I made a mistake - the custom action
 had the attribute After=RemoveFiles (it should of course be
 Before=RemoveFiles). Now when I try to uninstall on my application, the
 uninstall process terminates with the exception There is a problem with
 this Windows installer package. A program run as part of the setup did not
 finish as expected. Contact your support personnel or package vendor.. The
 same exception occurs if I try to install/repair/change my application...
 Is there any possibility to uninstall my application without the last
 (faulty) custom action? Or to 'overinstall' it somehow?
 Simon


 Simon Gerhold, razvojni inženir / Development Engineer
 Cetis d.d., Čopova 24, 3000 Celje, Slovenia - EU, T: +386 3 4278 785, F: +386
 3 4278 651, www.cetis.sihttp://www.cetis.si/


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to remove custom application with malformed uninstall package

2013-08-28 Thread John Ludlow

If this MSI is in the field then David's suggestion is the best option. I
was assuming it was a development version on a test system, and you just
wanted to clean that system down.


On 28 August 2013 11:10, David Watson dwat...@sdl.com wrote:


 Make a minor update msi that fixes the issue and get your users (or write a
 stub that) runs it from the command line with the repair and recache msi
 options.

 msiexec /fv your.msi /l*v log.txt



 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: 28 August 2013 10:34
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] How to remove custom application with malformed
 uninstall package

 You have a couple of options:

 Firstly, there's the MSI Cleanup Utility

 http://gallery.technet.microsoft.com/MSI-cleanup-utility-3889c8db

 This is an old tool which I thought had been retired, but it's come in very
 handy. Note that this will not perform any uninstall operations or any MSI
 logic at all. It basically hunts round the MSI registry for evidence of
 your
 install and removes it. Any of your own registry entries or files will not
 be
 removed.

 But it's good for cleaning up a broken install.

 Secondly, there's it's younger sibling, in the form of a FixIt
 troubleshooter:

 http://support.microsoft.com/mats/Program_Install_and_Uninstall

 This will scan for installs it thinks have problems, ask you a few
 questions,
 then do pretty much the same as the cleanup utility above, though it's
 supposed to do a more intelligent job.

 Thirdly, you can find the appropriate MSI in the c:\windows\installer
 cache,
 remove the offending action from the sequence using orca.exe and then try
 to
 uninstall it again.

 Lastly, I know some people who swear by CCleaner for this kind of thing:
 http://www.piriform.com/ccleaner

 Hope one of those suggestions helps.

 John


 On 28 August 2013 10:13, Simon Gerhold simon.gerh...@cetis.si wrote:

  I created a setup project with Wix Toolset, which does something like
 this:
 
*   install (into ProgramFiles/MyApp, Desktop shortcut, StartMenu,...)
*   create a folder ProgramFiles/MyApp/InstallFolder
*   create some files in the folder ProgramFiles/MyApp/InstallFolder
*   run a powershell script, which installs some COM+ components
  In the ProgramFiles/MyApp/InstallFolder is also a powershell script,
  which removes my COM+ applications (regsvcs /u). This script is
  executed as a custom action on uninstall. But here I made a mistake -
  the custom action had the attribute After=RemoveFiles (it should of
  course be Before=RemoveFiles). Now when I try to uninstall on my
  application, the uninstall process terminates with the exception
  There is a problem with this Windows installer package. A program run
  as part of the setup did not finish as expected. Contact your support
  personnel or package vendor.. The same exception occurs if I try to
 install/repair/change my application...
  Is there any possibility to uninstall my application without the last
  (faulty) custom action? Or to 'overinstall' it somehow?
  Simon
 
 
  Simon Gerhold, razvojni inženir / Development Engineer Cetis d.d.,
  Čopova 24, 3000 Celje, Slovenia - EU, T: +386 3 4278 785, F: +386
  3 4278 651, www.cetis.sihttp://www.cetis.si/
 
 
  --
   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
  2012, more!
  Discover the easy way to master current and previous Microsoft
  technologies and advance your career. Get an incredible 1,500+ hours
  of step-by-step tutorial videos with LearnDevNow. Subscribe today and
 save!
  http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.c
  lktrk ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 -
 -
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 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

Re: [WiX-users] How to remove custom application with malformed uninstall package

2013-08-28 Thread John Ludlow

Glad I could help


On 28 August 2013 14:13, Simon Gerhold simon.gerh...@cetis.si wrote:

 Thanks John  David, I used John's third option with orca.exe (I just
 deleted the problematic custom action and all is good).

 Thanks :)

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Wednesday, August 28, 2013 12:30 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] How to remove custom application with malformed
 uninstall package

 If this MSI is in the field then David's suggestion is the best option. I
 was assuming it was a development version on a test system, and you just
 wanted to clean that system down.


 On 28 August 2013 11:10, David Watson dwat...@sdl.com wrote:

 
  Make a minor update msi that fixes the issue and get your users (or
  write a stub that) runs it from the command line with the repair and
  recache msi options.
 
  msiexec /fv your.msi /l*v log.txt
 
 
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: 28 August 2013 10:34
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] How to remove custom application with
  malformed uninstall package
 
  You have a couple of options:
 
  Firstly, there's the MSI Cleanup Utility
 
  http://gallery.technet.microsoft.com/MSI-cleanup-utility-3889c8db
 
  This is an old tool which I thought had been retired, but it's come in
  very handy. Note that this will not perform any uninstall operations
  or any MSI logic at all. It basically hunts round the MSI registry for
  evidence of your install and removes it. Any of your own registry
  entries or files will not be removed.
 
  But it's good for cleaning up a broken install.
 
  Secondly, there's it's younger sibling, in the form of a FixIt
  troubleshooter:
 
  http://support.microsoft.com/mats/Program_Install_and_Uninstall
 
  This will scan for installs it thinks have problems, ask you a few
  questions, then do pretty much the same as the cleanup utility above,
  though it's supposed to do a more intelligent job.
 
  Thirdly, you can find the appropriate MSI in the c:\windows\installer
  cache, remove the offending action from the sequence using orca.exe
  and then try to uninstall it again.
 
  Lastly, I know some people who swear by CCleaner for this kind of thing:
  http://www.piriform.com/ccleaner
 
  Hope one of those suggestions helps.
 
  John
 
 
  On 28 August 2013 10:13, Simon Gerhold simon.gerh...@cetis.si wrote:
 
   I created a setup project with Wix Toolset, which does something
   like
  this:
  
 *   install (into ProgramFiles/MyApp, Desktop shortcut,
 StartMenu,...)
 *   create a folder ProgramFiles/MyApp/InstallFolder
 *   create some files in the folder ProgramFiles/MyApp/InstallFolder
 *   run a powershell script, which installs some COM+ components
   In the ProgramFiles/MyApp/InstallFolder is also a powershell script,
   which removes my COM+ applications (regsvcs /u). This script is
   executed as a custom action on uninstall. But here I made a mistake
   - the custom action had the attribute After=RemoveFiles (it should
   of course be Before=RemoveFiles). Now when I try to uninstall on
   my application, the uninstall process terminates with the exception
   There is a problem with this Windows installer package. A program
   run as part of the setup did not finish as expected. Contact your
   support personnel or package vendor.. The same exception occurs if
   I try to
  install/repair/change my application...
   Is there any possibility to uninstall my application without the
   last
   (faulty) custom action? Or to 'overinstall' it somehow?
   Simon
  
  
   Simon Gerhold, razvojni inženir / Development Engineer Cetis d.d.,
   Čopova 24, 3000 Celje, Slovenia - EU, T: +386 3 4278 785, F: +386
   3 4278 651, www.cetis.sihttp://www.cetis.si/
  
  
   
   --
    Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
   2012, more!
   Discover the easy way to master current and previous Microsoft
   technologies and advance your career. Get an incredible 1,500+ hours
   of step-by-step tutorial videos with LearnDevNow. Subscribe today
   and
  save!
   http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg
   .c lktrk ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users
  
 
  --
  ---
  -
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
  Discover the easy way to master current and previous Microsoft
  technologies and advance your career. Get an incredible 1,500+ hours
  of step-by-step tutorial videos with LearnDevNow. Subscribe today and
 save!
  http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu

Re: [WiX-users] Reading xml file

2013-08-27 Thread John Ludlow

You would need an immediate custom action to read the .config file, find
the appropriate connection string, and set its value to a property.

CustomAction Id=MyAction

  ExeCommand=cmd.exe /C MyDatabaseInstaller [CONNSTR] 
  Execute=deferred
  Return=check /

If you're using WiX from Visual Studio, you can go to File  New Project,
and choose Windows Installer XML  C# Custom Action Project. (Or C++ if you
prefer).

The C# version will generate a method for you which represents your custom
action entry point, with a Session object which represents the MSI session.
You can treat it like a dictionary when it comes to properties:

 // Get a property
 string cfgFile = session[ConfigurationFilePath];

// Whatever code you need to find the right connection string

 // Set a property
 session[CONNSTR] = connstr;



The C++ version uses a bunch of functions all beginning with Wca. I can't
remember the syntax right now but the set and get functions for properties
aren't too difficult IIRC.


On 27 August 2013 19:32, Carl Enander c_enan...@hotmail.com wrote:

 Hello,
 I am new to Wix and have a question regarding wix and reading settings
 from an xml file when running the installer. I have an xml file with
 database connectionstrings that are different for my test and production
 environment:
 configurationprodservernameconnectionstringconnstr1/connectionstring/prodservernametestservernameconnectionstringconnstr2/connectionstring/testservername/configuration
   When running installer I want to use the [COMPUTERNAME] variable to find
 the correct connectionstring value from the xml file and use this in a
 Custom Action (e.g. conntr1 to be used when installing on prod server and
 connstr2 on test server):CustomAction Id=MyAction

   ExeCommand=cmd.exe /C MyDatabaseInstaller Connstr 
   Execute=deferred
   Return=check /
 Please guide me to the best way to do this simple task.

 BR, Carl




 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix: Create OS specific installer using Wix?

2013-08-23 Thread John Ludlow

Also,

http://msdn.microsoft.com/en-us/library/aa370905(v=vs.85).aspx#operating_system_properties

For example, to tell the difference between server and workstation editions
of Windows, you can use MsiNTProductType.


On 23 August 2013 13:58, Pally Sandher pally.sand...@iesve.com wrote:

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012.aspx
 http://msdn.microsoft.com/en-us/library/aa372495.aspx
 http://msdn.microsoft.com/en-us/library/aa372497.aspx

 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


 -Original Message-
 From: ak m [mailto:wixak...@gmail.com]
 Sent: 23 August 2013 13:05
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Wix: Create OS specific installer using Wix?

 Dear All,

 How to create OS specific installer using Wix?

 For Example,

 Installer created for Windows XP 32-bit, should install on Windows XP
 32-bit only.
 Installer created for Windows Vista 32-bit, should install on Windows
 Vista only 32-bit.


 OS: XP, Server2003, Vista, Server2008 7, 8, Server2012(32bit/64bit).


 Could you please let me know the solution for this?

 Thanks in Advance...


 Anil

 --
 Introducing Performance Central, a new site from SourceForge and
 AppDynamics. Performance Central is your source for news, insights,
 analysis and resources for efficient Application Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Introducing Performance Central, a new site from SourceForge and
 AppDynamics. Performance Central is your source for news, insights,
 analysis and resources for efficient Application Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] LGHT0103 error where path is shorter than 255 characters and file is present.

2013-08-23 Thread John Ludlow

Does this ever work or is it failing consistently? If it's intermittent
then unreliable access to that location could still be the cause.

One other question is what does D: map to? You mention network, which makes
me wonder if this is a mapped drive. Does this work if you use an entirely
local path? Some MSI operations cause errors if with mapped network drives
On Aug 23, 2013 10:05 PM, Alain Forget afor...@cmu.edu wrote:

 Never mind, it clearly does, given the LGHT error.

 Maybe the extra backslash is confusing it? i.e., maybe
 $(var.KMI.IntelliDrive.ServicesHost.TargetDir)\KMI.IntelliDrive.ServicesHost.vshost.exe.config

 Should be


 $(var.KMI.IntelliDrive.ServicesHost.TargetDir)KMI.IntelliDrive.ServicesHost.vshost.exe.config

 ?

 -Original Message-
 From: Alain Forget [mailto:afor...@cmu.edu]
 Sent: Friday, August 23, 2013 16:56
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] LGHT0103 error where path is shorter than 255
 characters and file is present.

 You may already have verified this, but are you sure
 $(var.KMI.IntelliDrive.ServicesHost.TargetDir) is defined and points to the
 location you think it's supposed to point to?

 Alain

 -Original Message-
 From: Bodden, Doug (KMWCR) [mailto:doug.bod...@kantarmedia.com]
 Sent: Friday, August 23, 2013 16:21
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] LGHT0103 error where path is shorter than 255
 characters and file is present.

 I'm seeing a LGHT0103 error. The files are simply reported as not found;
 but they're there. If you look at the light.exe command I ran below - I
 grabbed the command text from a Visual Studio build log, and then ran
 the ls command in powershell immediately after to demonstrate that the
 file is there.



 Does not seem to be related to the path length or have the cannot find
 file with type message in a similar behavior I saw reported.



 Powershell session w/ light.exe reproducing the error, and ls
 demonstrating the file is there:





 PS
 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup light.exe -out
 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup\bin\Release\en-US\IntelliDriv
 eServiceHostWixSetup.msi -pdbout
 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup\bin\Release\en-US\IntelliDriv
 eServiceHostWixSetup.wixpdb -cultures:en-US -ext C:\Program Files
 (x86)\WiX Toolset v3.7\bin\\WixNetFxExtension.dll -loc
 UI\WixUI_en-us.wxl -contentsfile
 obj\Release\IntelliDriveServiceHostWixSetup.wixproj.BindContentsFileList
 en-US.txt -outputsfile
 obj\Release\IntelliDriveServiceHostWixSetup.wixproj.BindOutputsFileListe
 n-US.txt -builtoutputsfile
 obj\Release\IntelliDriveServiceHostWixSetup.wixproj.BindBuiltOutputsFile
 Listen-US.txt -wixprojectfile
 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup\IntelliDriveServiceHostWixSet
 up.wixproj obj\Release\CommonConfigContent.wixobj
 obj\Release\Product.wixobj obj\Release\ServiceHostContent.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\CancelDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\Common.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\EnvironmentSelectionDial
 og.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\ErrorDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\ExitDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\FatalErrorDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\FilesInUseDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\PrimarySecondarySelectio
 nDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\ProgressDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\ServiceInstallerUI.wixob
 j obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\UserExitDialog.wixobj
 obj\Release\pth0E8FFB1A374BA65CFAE4D2CDD0154539\WelcomeDialog.wixobj
 obj\Release\WindowsService.wixobj obj\Release\Product.Generated.wixobj

 Windows Installer Xml Linker version 3.7.1224.0

 Copyright (C) Outercurve Foundation. All rights reserved.



 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup\ServiceHostContent.wxs(67) :
 error LGHT0103 : The system cannot find the file
 'D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\I
 ntelliDrive\Services
 Domain\KMI.IntelliDrive.ServicesHost\bin\Release\\KMI.IntelliDrive.Servi
 cesHost.vshost.exe.config'.



 PS
 D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\In
 telliDrive\IntelliDriveServiceHostWixSetup ls
 'D:\Subversion\pdev\branches\Intellidrive\DirectHEAT_NPMarx\TNSMI.Net2\I
 ntelliDrive\Services
 Domain\KMI.IntelliDrive.ServicesHost\bin\Release\\KMI.IntelliDrive.Servi
 cesHost.exe.config'

Re: [WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-22 Thread John Ludlow

Ok, minor facepalm moment here.

It turned out that my component library project had a reference to my
action library from when I was testing the action out before turning it
into an extension. When this was combined with the reference created from
the code, this created two references to the same thing in the same code,
which gave me the error.

I removed that and it worked just fine. The lesson to learn from this is to
double-check those references if you get into these issues.

I'm considering raising a bug because a) this error was kind of bogus in
that the second reference could have been safely ignored, and b) the error
message didn't really point to the reference on the component library
project. It was only when I was ready to give up and abandon the
'wixlib-in-the-dll' idea as a bad job that I spotted this extra reference.

Thanks for the help



On 11 July 2013 17:44, John Ludlow john.ludlow...@gmail.com wrote:

 @Nick:

 Yes, I'm trying to use the extension in a library which is then used in a
 setup project. The resulting project relationships would be something like
 this:
 https://docs.google.com/file/d/0BzqWyEdx-NBBeDM5ZlJGejRoNE0/edit?usp=sharing

 The reason for this is that the setup project is just metadata related to
 the MSI itself. This makes it easy to include those components in some
 other setup, or even a merge module, just by adding the correct references
 to the correct projects. Is this not common practice?

 The other reason is that our body of setup code is sufficiently large that
 we need to split it up somehow.

 @Blair:

The original error appears to be due to missing code in the extension.

 I'm not sure what missing code you were referring to here.


 On 11 July 2013 02:50, Blair Murri os...@live.com wrote:

 There are several ways to make the *Ref. One way is to author a *Ref/
 element. Another is to use CompilerCore.CreateWixSimpleReferenceRow().
 Either works the same as the other.

 The original error appears to be due to missing code in the extension.
 The second error (caused by trying to workaround that first error) appears
 to be caused by making an explicit reference to the wixlib that the
 extension contains along with the extension (causing double references).

  Date: Wed, 10 Jul 2013 13:57:00 -0700
  From: nickra...@hotmail.com
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Duplicate symbol when using
 CompilerCore.CreateWixSimpleReferenceRow
 
  Okay, I maybe wasn't fully understanding the problem. :) So, you're
 saying
  that you want to use your extension in another WIXLIB (unrelated to the
  WIXLIB you used to build your extension)...but when you try that, but
 don't
  reference the extension in your Setup project too, you get the error
 Cannot
  find the table definitions for
 
  As far as I can tell, you need to have the project reference for the
  extension in both the WIXLIB and the Setup project.
 
  To make your WIXLIB work, i.e. to pull the contents of the WIXLIB into
 your
  MSI (this may be the part you're missing?), you need to put a Property
 in
  the WIXLIB and then use a PropertyRef that points to that Property in
 your
  Setup file. This creates the link between the library and the MSI,
 pulling
  in all of the contents (your components, your new extension elements,
 etc.)
  that are in the library's Fragment into the MSI.
 
 
 
  --
  View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Duplicate-symbol-when-using-CompilerCore-CreateWixSimpleReferenceRow-tp7587243p7587281.html
  Sent from the wix-users mailing list archive at Nabble.com.
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!

 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics

Re: [WiX-users] Starting a complex project

2013-07-22 Thread John Ludlow

Agreed, that's really the only complete reference source for WiX 3.6, and
there's quite a lot that you can only really learn via the book. Be careful
though as I saw a bogus addition flying around on Amazon UK (it's gone now
so maybe it was just a mistake).

In the book, your requirements above mean you'll probably be getting to
know Burn quite well, and chapters 15 and 16 cover that in some detail.


On 22 July 2013 12:02, Gregg Swanson gregg.swan...@microsoft.com wrote:

 I would encourage you to purchase this book -
 http://www.amazon.com/WiX-3-6-Developers-Windows-Installer/dp/1782160426/ref=sr_1_1?ie=UTF8qid=1374490843sr=8-1keywords=wix

 WiX 3.6: A Developer's Guide to Windows Installer XML [Paperback]
 Nick Ramirez

 Be sure to get the latest edition.

 Thanks,
 Gregg


 -Original Message-
 From: Walter Gray [mailto:chrysal...@gmail.com]
 Sent: Monday, July 22, 2013 1:58 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Starting a complex project

 Hey List!
I've just begun the exciting journey of migrating our company's
 installer from a large, slow NSIS script to a shiny new WiX project, and I
 was hoping the list could point me towards a few more or let me know about
 any pitfalls I may encounter.  I've done some research  found a few
 resources, but much of the documentation seems to be a bit out of date or
 scattered between stackoverflow posts  blog entries, so I was hoping
 people here might have some suggestions on where to look for the most up to
 date resources.  The scope of this project is pretty large, and will need
 support for at minimum:
 -Slight UI customization (we'd prefer a relatively standard UI, but need
 1-2 custom checkboxes for launching the readme,  a few other minor things
 like that. ) -An OEM preinstaller with slightly different behavior -A mixed
 x86/x64 package - I'm aware I'll have to make separate .msi packages 
 bundle them with burn.
 -chaining the VS2010 redistributable packages -chaining a 2nd driver
 installer

 Some stretch goals would be building a web installer  adding a totally
 custom UI experience, perhaps akin to the VS2012 one (is there a tutorial
 on how they built that or an example? I'm presently downloading the source
 for wix to look at their installer files)

 So far I've found these:
 http://wix.tramontana.co.hu/tutorial - helpful, but somewhat out of date
 http://wix.sourceforge.net/manual-wix3/schema_index.htm - helpful, but
 only if you have some idea what you're looking for
 http://stackoverflow.com/questions/471424/wix-tricks-and-tips - The only
 best practices list I've seen, with some conflicting advice  sadly locked





 --
 See everything from the browser to the database with AppDynamics Get
 end-to-end visibility with application monitoring from AppDynamics Isolate
 bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-11 Thread John Ludlow

@Nick:

Yes, I'm trying to use the extension in a library which is then used in a
setup project. The resulting project relationships would be something like
this:
https://docs.google.com/file/d/0BzqWyEdx-NBBeDM5ZlJGejRoNE0/edit?usp=sharing

The reason for this is that the setup project is just metadata related to
the MSI itself. This makes it easy to include those components in some
other setup, or even a merge module, just by adding the correct references
to the correct projects. Is this not common practice?

The other reason is that our body of setup code is sufficiently large that
we need to split it up somehow.

@Blair:

   The original error appears to be due to missing code in the extension.

I'm not sure what missing code you were referring to here.


On 11 July 2013 02:50, Blair Murri os...@live.com wrote:

 There are several ways to make the *Ref. One way is to author a *Ref/
 element. Another is to use CompilerCore.CreateWixSimpleReferenceRow().
 Either works the same as the other.

 The original error appears to be due to missing code in the extension. The
 second error (caused by trying to workaround that first error) appears to
 be caused by making an explicit reference to the wixlib that the extension
 contains along with the extension (causing double references).

  Date: Wed, 10 Jul 2013 13:57:00 -0700
  From: nickra...@hotmail.com
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Duplicate symbol when using
 CompilerCore.CreateWixSimpleReferenceRow
 
  Okay, I maybe wasn't fully understanding the problem. :) So, you're
 saying
  that you want to use your extension in another WIXLIB (unrelated to the
  WIXLIB you used to build your extension)...but when you try that, but
 don't
  reference the extension in your Setup project too, you get the error
 Cannot
  find the table definitions for
 
  As far as I can tell, you need to have the project reference for the
  extension in both the WIXLIB and the Setup project.
 
  To make your WIXLIB work, i.e. to pull the contents of the WIXLIB into
 your
  MSI (this may be the part you're missing?), you need to put a Property in
  the WIXLIB and then use a PropertyRef that points to that Property in
 your
  Setup file. This creates the link between the library and the MSI,
 pulling
  in all of the contents (your components, your new extension elements,
 etc.)
  that are in the library's Fragment into the MSI.
 
 
 
  --
  View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Duplicate-symbol-when-using-CompilerCore-CreateWixSimpleReferenceRow-tp7587243p7587281.html
  Sent from the wix-users mailing list archive at Nabble.com.
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-10 Thread John Ludlow

Hi,

My installer has two projects - a Setup Project which emits an .MSI and
contains install metadata, and a Setup Library Project which emits a
.wixlib which contains install components. The latter makes use of a
compiler extension which generates an MSI table based on some child
elements of the File element. In other words, it looks like this:

File
   myext:MyFunkyExtension/
/File

(attributes omitted for brevity)

The extension consists of three projects: a C# class library for the actual
extension, a C++ Custom Action Library for the custom actions that will use
the data in the table, and a wixlib to hold the custom action definition.
The CA DLL is bound into the wixlib, and the wixlib is included in the
extension dll project as an embedded resource.

Now here comes the issue...

When I reference the extension DLL from just the wixlib which has the
components in, I get this error:

Error 1 Cannot find the table definitions for the 'MyTable' table.  This is
likely due to a typing error or missing extension.  Please ensure all the
necessary extensions are supplied on the command line with the -ext
parameter. light.exe 0 1 MyInstall

I wondered if the setup project needed the reference as well, but when I
add that I get this:
Error 1 Duplicate symbol 'CustomAction:MyCA' found. This typically means
that an Id is duplicated. Check to make sure all your identifiers of a
given type (File, Component, Feature) are unique.
MyComponentSetupLibrary.wixlib 0 1 MyInstall

I reckon this is down to this code at the end of the ParseElement methjod
in the extension:

   Core.CreateWixSimpleReferenceRow(ln, CustomAction, MyCA);
I did this on the suggestion of the Wix 3.6 Development Guide (Chapter 14)
in order to create a reference to the action in order to pull the fragment
into the installation.

I also noticed that my ParseElement method seems to get called twice. Is
this because I have 2 references from my projects (one from my setup
project and one from my setup library project)? This is odd - I thought you
could reference things as many times as you liked in this manner, and if it
was already there then it would just ignore it.

Any hints would be greatly appreciated.

Thanks

John
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-10 Thread John Ludlow

Hi Blair,

Ok, does that mean I've encountered an error in the book, then? The book
suggests adding the wixlib to the extension, and I've done that (means I
should only have to reference the extension, not the wixlib, right?).

However, the sample code in the book does not come with a test install
which shows how to reference it, nor is this discussed in the book in any
detail. I was going to create one but have not had the time yet, so I'm not
sure if the code in the book works or not. (Wouldn't be the first time I've
come across sample code in a book that doesn't compile).

I got that the extension needs to be supplied to both (though, honestly,
it's a bit annoying having to propagate the references). That's obviously
why the first error appeared.

It made sense that this was because I was referencing it twice, but I
figured the book was probably correct and I was missing something (and I
didn't want to just remove the line so it worked temporarily). It would
probably be a good improvement to have this behave like I described above -
you can only declare something once, but you can create as many references
as you like to it, even if those references are technically duplicates of
each other.

In  the meantime, I'll remove that line.

Thanks

PS: I'm still planning to write this up as a tutorial, but I just want to
get stuff like this sorted first


On 10 July 2013 14:46, Blair Murri os...@live.com wrote:

 A WixExtension used in the way you describe usually supplies three things:
 a CompilerExtension (to parse your new elements and attributes), a Table
 definition (comes from a tables.xml-style file with the definitions of the
 tables unique to your extension), and a binary-wixlib (containing your CAs
 and related authoring).

 Usually your CompilerExtension will supply two things: references to items
 in your wixlib, and rows into your tables (from the authoring you parse).
 Those rows are not part of your wixlib.

 CreateWixSimpleReferenceRow creates a reference to a row that needs to be
 supplied from elsewhere, usually the wixlib supplied by the extension.

 If the WixExtension supplies the wixlib, you don't need to supply it.
 Also, if the WixExtension supplies the table definitions (via the
 tables.xml-style file), you don't need to duplicate the table definitions
 in your wixlib (using CustomTable elements).

 Also, make sure that your extension is supplied to both candle and light
 in your build script.

 I would guess that you are missing the tables.xml-style reference in your
 WixExtension (which I suspect is the source of your missing error), and
 that you are supplying the wixlib used in your extension directly to your
 setup project (which I suspect is the source of your duplicate symbol).

  From: john.ludlow...@gmail.com
  Date: Wed, 10 Jul 2013 12:25:38 +0100
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Duplicate symbol when using
  CompilerCore.CreateWixSimpleReferenceRow
 
  Hi,
 
  My installer has two projects - a Setup Project which emits an .MSI and
  contains install metadata, and a Setup Library Project which emits a
  .wixlib which contains install components. The latter makes use of a
  compiler extension which generates an MSI table based on some child
  elements of the File element. In other words, it looks like this:
 
  File
 myext:MyFunkyExtension/
  /File
 
  (attributes omitted for brevity)
 
  The extension consists of three projects: a C# class library for the
 actual
  extension, a C++ Custom Action Library for the custom actions that will
 use
  the data in the table, and a wixlib to hold the custom action definition.
  The CA DLL is bound into the wixlib, and the wixlib is included in the
  extension dll project as an embedded resource.
 
  Now here comes the issue...
 
  When I reference the extension DLL from just the wixlib which has the
  components in, I get this error:
 
  Error 1 Cannot find the table definitions for the 'MyTable' table.  This
 is
  likely due to a typing error or missing extension.  Please ensure all the
  necessary extensions are supplied on the command line with the -ext
  parameter. light.exe 0 1 MyInstall
 
  I wondered if the setup project needed the reference as well, but when I
  add that I get this:
  Error 1 Duplicate symbol 'CustomAction:MyCA' found. This typically means
  that an Id is duplicated. Check to make sure all your identifiers of a
  given type (File, Component, Feature) are unique.
  MyComponentSetupLibrary.wixlib 0 1 MyInstall
 
  I reckon this is down to this code at the end of the ParseElement methjod
  in the extension:
 
 Core.CreateWixSimpleReferenceRow(ln, CustomAction, MyCA);
  I did this on the suggestion of the Wix 3.6 Development Guide (Chapter
 14)
  in order to create a reference to the action in order to pull the
 fragment
  into the installation.
 
  I also noticed that my ParseElement method seems to get called twice. Is
  this because I have 2 references from my projects (one

Re: [WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-10 Thread John Ludlow

Blair,

Yes I have the tables.xml correctly referenced as described above.  The
error has disappeared.  If this pattern is idiomatic for this type of
extension, I'm happy.

My points above were

  *  The only widely available documentation for this appears to have an
error
  *  It would have been better if WiX had not thrown this error and instead
simply thrown the second reference away (I can't see any way this might be
dangerous, since a reference is just a reference).

If I'm missing anything with either of those points, please let me know.

If I have any further questions, I'll be back in touch :)

Thanks for your help

John


On 10 July 2013 15:51, Blair Murri os...@live.com wrote:

 John,

 Yes, you put the wixlib only into the extension, and that allows you to
 have your setup project only reference the extension and not the wixlib
 directly.

 The setup project references the extension in a similar fashion to the
 toolset-supplied extensions, except that the path (including the .dll at
 the end of the filename) need to be supplied (done for you by Votive).

 I haven't looked that the example in the book (yet).

 You supply the table definitions by overriding the TableDefinitions
 property similar to this:

 private TableDefinitionCollection tableDefinitions;
 public override TableDefinitionCollection TableDefinitions
 {
 get
 {
 if (null == this.tableDefinitions)
 {
 this.tableDefinitions =
 LoadTableDefinitionsHelper(Assembly.GetExecutingAssembly(),
 assembly-resource-prefix.tables.xml);
 }
 return this.tableDefinitions;
 }
 }

 (looks very similar to the code used to supply the wixlib -- the
 GetLibrary() override you had to use to have the extension supply your
 wixlib)

 You place the tables.xml file into your managed resources a similar way as
 you do your wixlib.

 The tables.xml file uses the tableDefinitions schema (
 http://schemas.microsoft.com/wix/2006/tables), the xsd of which is only
 in the sources (src\wix\Xsd\tables.xsd). Only supply attributes that are
 not required if you need to override the default value. The TablesYesNoType
 type defaults to no, and most of the attributes come from MSDN and end up
 in the table validation
 metadata.

 Blair

  From: john.ludlow...@gmail.com
  Date: Wed, 10 Jul 2013 15:20:56 +0100
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Duplicate symbol when using
  CompilerCore.CreateWixSimpleReferenceRow
 
  Hi Blair,
 
  Ok, does that mean I've encountered an error in the book, then? The book
  suggests adding the wixlib to the extension, and I've done that (means I
  should only have to reference the extension, not the wixlib, right?).
 
  However, the sample code in the book does not come with a test install
  which shows how to reference it, nor is this discussed in the book in any
  detail. I was going to create one but have not had the time yet, so I'm
 not
  sure if the code in the book works or not. (Wouldn't be the first time
 I've
  come across sample code in a book that doesn't compile).
 
  I got that the extension needs to be supplied to both (though, honestly,
  it's a bit annoying having to propagate the references). That's obviously
  why the first error appeared.
 
  It made sense that this was because I was referencing it twice, but I
  figured the book was probably correct and I was missing something (and I
  didn't want to just remove the line so it worked temporarily). It would
  probably be a good improvement to have this behave like I described
 above -
  you can only declare something once, but you can create as many
 references
  as you like to it, even if those references are technically duplicates of
  each other.
 
  In  the meantime, I'll remove that line.
 
  Thanks
 
  PS: I'm still planning to write this up as a tutorial, but I just want to
  get stuff like this sorted first
 
 
  On 10 July 2013 14:46, Blair Murri os...@live.com wrote:
 
   A WixExtension used in the way you describe usually supplies three
 things:
   a CompilerExtension (to parse your new elements and attributes), a
 Table
   definition (comes from a tables.xml-style file with the definitions of
 the
   tables unique to your extension), and a binary-wixlib (containing your
 CAs
   and related authoring).
  
   Usually your CompilerExtension will supply two things: references to
 items
   in your wixlib, and rows into your tables (from the authoring you
 parse).
   Those rows are not part of your wixlib.
  
   CreateWixSimpleReferenceRow creates a reference to a row that needs to
 be
   supplied from elsewhere, usually the wixlib supplied by the extension.
  
   If the WixExtension supplies the wixlib, you don't need to supply it.
   Also, if the WixExtension supplies the table definitions (via the
   tables.xml-style file), you don't need to duplicate the table
 definitions
   in your wixlib (using CustomTable elements).
  
   Also, make sure that your extension is supplied to

Re: [WiX-users] Duplicate symbol when using CompilerCore.CreateWixSimpleReferenceRow

2013-07-10 Thread John Ludlow

Yup, did that - that's how I know there's no test installer for it.

When I removed that line, the install compiled but without the action.
 I'll add a test install to the sample, and see what I get. I just haven't
had time to do that today, unfortunately.


On 10 July 2013 17:47, Nick Ramirez nickra...@hotmail.com wrote:

 You should be able to download the example for that chapter at the Packt
 publishers (packtpub.com) site. On the page that shows the details about
 the
 book, click the tab that says Support and there ought to be a Code
 Downloads link.



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Duplicate-symbol-when-using-CompilerCore-CreateWixSimpleReferenceRow-tp7587243p7587260.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 1308 (Source File not found) emitted as Info on upgrade

2013-06-03 Thread John Ludlow

Hi again, just so you know, I tried setting Vital=yes and removing the
MsiFileHash table entry for that file, and I'm still getting the same
behaviour.

It's curious that it would translate the error like this (points to a bug
in MSI, I think) but other than that this isn't really a big deal.


Thanks for your help


On 30 May 2013 20:43, John Ludlow john.ludlow...@gmail.com wrote:

 Thanks Phil, I'll take a look when I get a chance. I have a feeling it's
 still in the hash table.

 Thanks again.


 On 30 May 2013 19:28, Phil Wilson phil.wil...@mvps.org wrote:

 Have a look at the vital setting for the file. You may find it's not
 vital
 in the Info message case.

 MSI File table:


 http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).as
 px

 If the file is external and you are replscing it at the last moment make
 sure you don't make a file hash mistake. You don't want the hash in the
 MSI
 file to not match the actual file, so turn it off for that file unless you
 are fixing the MsiFileHash table when you replace the file.

 Phil

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Thursday, May 30, 2013 6:08 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] Error 1308 (Source File not found) emitted as Info on
 upgrade

 Hi,

 I have one MSI, with a bunch of compressed files in an embedded cab, and
 one
 readme next to the install as an uncompressed file. This file is still in
 the installer, it's just got the nonCompressed bit set. This is so we can
 update the readme right up until release with late-breaking information.

 This all works fine for fresh installs and upgrades, as long as that file
 is
 present. I that file is not present, we get this:

 Error 1308. Source file not found:
 C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
 file exists and that you can access it.
 That makes perfect sense.

 The issue is that this is not happening on upgrade. What's happening on
 upgrade if the readme file is missing is that the same error is being
 published as an Info message, and the install carries on merrily:

 Info 1308. Source file not found:
 C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
 file exists and that you can access it.
 There's a few ways we can work around this (either not having the file
 uncompressed like this or by having an action which checks for the
 presence
 of the file). However, what I'd like to understand is why MSI is turning
 this Error message into an Info message on upgrade.

 Any ideas?

 Thanks

 
 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get
 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

2013-05-30 Thread John Ludlow

We're looking at simply making WiX part of the toolkit you need to build
our solutions.  We've tried this with some smaller projects and it's worked
really well. Developers can follow up on their own impacts, and they can
tell when they've broken the install. This increases build quality and
frees up install developers from the add a file, remove a file
monkey-work we seem to spend 80% of our time doing.

Some of the developers grumbled a bit, but it's also been taken positively
by others, and everyone gets a bit more respect for their poor, abused
install developers. :)

In fact, the main issues are related to integrating it into our build
system (which is more down to the fact that we don't want to install stuff
onto our build system - we want the build to be able to xcopy install
whatever it needs).





On 29 May 2013 18:46, keith.doug...@statcan.gc.ca wrote:

 I don't know if our approach will work well long term since we are still
 developing all of this, but we decided we'd build front end utilities for
 developers to use with presets implicitly written out to wxs for them (like
 Manufacturer and expected directories to install to, etc.). This way in
 principle we could also have developers (or in your case, a build server)
 drop off their files and an installer build person / process can then pick
 them up with the front end to WIX.



 Keith Douglas
 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
 keith.doug...@statcan.gc.ca
 Telephone | Téléphone 613-951-4405
 Facsimile | Télécopieur 613-951-1966
 Government of Canada | Gouvernement du Canada


 -Original Message-
 From: Drake, David [mailto:david.dr...@wizards.com]
 Sent: May-29-13 1:41 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] Wix dev and regular dev best practices

 I am attempting to bring an extra layer of automation to my area of
 concern and have chosen to start packaging up each of our services into
 .msi files for easier deployment and configuration.  Part of getting
 started is figuring out the best way to implement WIX installers into our
 build system without causing impact on the developers.  My initial thought
 was to add wix projects to the various solutions we have in source control,
 check in all of the WIX binaries as mentioned in the WIX manual so the
 CruiseControl powered build system can see them.  I have set a post-build
 step in one of their C# Projects to run Heat.exe and spit out a files.wxs
 file that contains all of their output, and filter it through a
 transform.xsl to add in the ServiceControl elements and strip out all of
 the useless garbage that should not be installed.

 The problem with this is that it's going to cause the devs to have an
 issue with opening the solution and having that one .wixproj project fail
 to open, throwing up a pop-up and somewhat disrupting their flow.

 Is there a way to give them just the VS2012 plugin so the .wixproj type is
 recognized, or should I just stay out of their solution files and find some
 other way to run heat to harvest their output and go on to build the .msi
 file?

 Is there some other approach that has been proven to work well when the
 person creating and maintaining the installer creation and deployment
 processes is not a direct member of the development team?

 Thank you,

 ~David Drake
 CES Build Engineer
 david.dr...@wizards.commailto:david.dr...@wizards.com


 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.

[WiX-users] Error 1308 (Source File not found) emitted as Info on upgrade

2013-05-30 Thread John Ludlow

Hi,

I have one MSI, with a bunch of compressed files in an embedded cab, and
one readme next to the install as an uncompressed file. This file is still
in the installer, it's just got the nonCompressed bit set. This is so we
can update the readme right up until release with late-breaking information.

This all works fine for fresh installs and upgrades, as long as that file
is present. I that file is not present, we get this:

Error 1308. Source file not found:
C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
file exists and that you can access it.
That makes perfect sense.

The issue is that this is not happening on upgrade. What's happening on
upgrade if the readme file is missing is that the same error is being
published as an Info message, and the install carries on merrily:

Info 1308. Source file not found:
C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
file exists and that you can access it.
There's a few ways we can work around this (either not having the file
uncompressed like this or by having an action which checks for the presence
of the file). However, what I'd like to understand is why MSI is turning
this Error message into an Info message on upgrade.

Any ideas?

Thanks
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix dev and regular dev best practices

2013-05-30 Thread John Ludlow

@Mark:

Yep, that's what we've gone with, but we had issues getting the right set
of properties to set up the paths properly because there's a number of
cascading properties. Also, we had issues in that we have to do this with
every .wixproj. (I guess we might create a customized .wixproj which has
those changes already)

Thanks


On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote:

 I've recently added WiX to my continuous integration server, Team City.
 They key is to not have to install stuff on the build machines. WiX
 includes the install binaries that can be put right in your source tree.
 However the binaries do not include the files necessary for Custom Actions
 (CAs), so I had to include some extra files that come with the standard WiX
 developer install.

 http://wix.codeplex.com/releases/view/99514

 Then, update your .wixproj projects to point to the relative path to your
 wix binaries. See the Wix tags in PropertyGroup.

   PropertyGroup
 Configuration Condition= '$(Configuration)' == ''
 Debug/Configuration
 Platform Condition= '$(Platform)' == '' x86/Platform
 ProductVersion3.7/ProductVersion
 ProjectGuidz/ProjectGuid
 SchemaVersion2.0/SchemaVersion
 OutputNameMy  Installer/OutputName
 OutputTypePackage/OutputType
 WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath
 WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath
 WixTasksPathwixtasks.dll/WixTasksPath
   /PropertyGroup


 If you're doing bootstrappers prerequisites with the GenerateBootstrapper
 command, you can do something similar in your project's bootstrapper to
 redirect them to a  relative path so that the build machine doesn't need to
 have Visual Studio installed, or whatever puts them in the default
 Microsoft SDK package.

 GenerateBootstrapper ApplicationFile=MyInstaller.msi
 ApplicationName=My App  BootstrapperItems=@(BootstrapperFile)
 ComponentsLocation=Relative CopyComponents=True
 OutputPath=$(OutputPath) Path=..\..\Bootstrapper /

 Mark Freedman


 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Thursday, May 30, 2013 5:53 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Wix dev and regular dev best practices

 We're looking at simply making WiX part of the toolkit you need to build
 our solutions.  We've tried this with some smaller projects and it's worked
 really well. Developers can follow up on their own impacts, and they can
 tell when they've broken the install. This increases build quality and
 frees up install developers from the add a file, remove a file
 monkey-work we seem to spend 80% of our time doing.

 Some of the developers grumbled a bit, but it's also been taken positively
 by others, and everyone gets a bit more respect for their poor, abused
 install developers. :)

 In fact, the main issues are related to integrating it into our build
 system (which is more down to the fact that we don't want to install stuff
 onto our build system - we want the build to be able to xcopy install
 whatever it needs).





 On 29 May 2013 18:46, keith.doug...@statcan.gc.ca wrote:

  I don't know if our approach will work well long term since we are
  still developing all of this, but we decided we'd build front end
  utilities for developers to use with presets implicitly written out to
  wxs for them (like Manufacturer and expected directories to install
  to, etc.). This way in principle we could also have developers (or in
  your case, a build server) drop off their files and an installer build
  person / process can then pick them up with the front end to WIX.
 
 
 
  Keith Douglas
  Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
  Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
  0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405
  Facsimile | Télécopieur 613-951-1966 Government of Canada |
  Gouvernement du Canada
 
 
  -Original Message-
  From: Drake, David [mailto:david.dr...@wizards.com]
  Sent: May-29-13 1:41 PM
  To: General discussion for Windows Installer XML toolset.
  Subject: [WiX-users] Wix dev and regular dev best practices
 
  I am attempting to bring an extra layer of automation to my area of
  concern and have chosen to start packaging up each of our services
  into .msi files for easier deployment and configuration.  Part of
  getting started is figuring out the best way to implement WIX
  installers into our build system without causing impact on the
  developers.  My initial thought was to add wix projects to the various
  solutions we have in source control, check in all of the WIX binaries
  as mentioned in the WIX manual so the CruiseControl powered build
  system can see them.  I have set a post-build step in one of their C#
  Projects to run Heat.exe and spit out a files.wxs file that contains
  all of their output, and filter it through a transform.xsl to add

[WiX-users] Recommended way of defining custom actions across multiple wxs files?

2013-05-30 Thread John Ludlow

Hi,

While I was looking at refactoring our wxs code, I noticed something odd.

I have a structure like this

File\File.wixproj
 File.wxs

Install\Install.wixproj
 Product.wxs
 CustomAction1.wxs
 CustomAction2.wxs
 InstallExecuteSequence.wxs

(Note that I'm using an over-simplified example here, I'm not actually
limiting myself to 1 CA per file - that would be ludicrous. Instead, I'm
grouping related CAs together.  The point is that I've been defining
actions in a wxs, and the sequence in another wxs).

The Install.wixproj (which emits an MSI) references File.wixproj (which
emits a .wixlib) and includes the componentgroup it contains in a feature -
all good. However, the custom actions and sequence definition in
CustomActionxxx.wxs and InstallExecuteSequence.wxs do not get imported - I
just get the default InstallExecuteSequence and no CustomAction table to
speak of.

I know this is expected behaviour, as described in Bob's comment:

http://sourceforge.net/p/wix/bugs/1457/#5b62

*For a fragment to be linked requires that something higher in the chain,
 starting with your Product/Merge/Patch, to refer to a
 **symbol in the fragment. If nothing does, the fragment is excluded at
 link time. The way most WiX CAs are authored, there's one  fragment that
 contains the custom action and its InstallExecuteSequence scheduling, so a
 CustomActionRef will cause both to be linked in. If that's what you're
 doing, please re-open the bug and attach a sample so we can help.*

* *
Clearly I should be doing something like this instead:
*
*
Install\Install.wixproj
 Product.wxs
 CustomAction1AndSequence.wxs
 CustomAction2AndSequence.wxs

So this raises a couple of other questions related to best practices. How
do we handle sequencing? This structure suggests that the two custom
actions don't know about each other, so how we specify which comes first.
If there's no dependencies between the two actions, should they both simply
declare that they need to come after an action that they do depend on, say
InstallFiles? What would the sequence be? Would the sequence be
inconsistent? Would it give me duplicate sequence numbers (and the ICE
warnings that go with them)?

And if one of them does require the other, how do we handle that? Can I
just reference the name in the sequencing? (I think I can - we have
sequencing and CA definitions spread across multiple files now, and it
works fine, so referencing CA1 from the sequence definition for CA2 would
probably work as well) Also, in this case the answer might be to simply
include them in the same file anyway.

Finally, since the sequence is spread out over multiple wxs files, how do
you get a view of the actual sequence? Is this just a case of opening orca
and seeing what's in the table?

Any advice would be appreciated!

Thanks
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 1308 (Source File not found) emitted as Info on upgrade

2013-05-30 Thread John Ludlow

Thanks Phil, I'll take a look when I get a chance. I have a feeling it's
still in the hash table.

Thanks again.


On 30 May 2013 19:28, Phil Wilson phil.wil...@mvps.org wrote:

 Have a look at the vital setting for the file. You may find it's not
 vital
 in the Info message case.

 MSI File table:


 http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).as
 px

 If the file is external and you are replscing it at the last moment make
 sure you don't make a file hash mistake. You don't want the hash in the MSI
 file to not match the actual file, so turn it off for that file unless you
 are fixing the MsiFileHash table when you replace the file.

 Phil

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Thursday, May 30, 2013 6:08 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] Error 1308 (Source File not found) emitted as Info on
 upgrade

 Hi,

 I have one MSI, with a bunch of compressed files in an embedded cab, and
 one
 readme next to the install as an uncompressed file. This file is still in
 the installer, it's just got the nonCompressed bit set. This is so we can
 update the readme right up until release with late-breaking information.

 This all works fine for fresh installs and upgrades, as long as that file
 is
 present. I that file is not present, we get this:

 Error 1308. Source file not found:
 C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
 file exists and that you can access it.
 That makes perfect sense.

 The issue is that this is not happening on upgrade. What's happening on
 upgrade if the readme file is missing is that the same error is being
 published as an Info message, and the install carries on merrily:

 Info 1308. Source file not found:
 C:\Users\Neil.Owen\Desktop\10.0.4.1157\ReadMeFirst_EN.htm. Verify that the
 file exists and that you can access it.
 There's a few ways we can work around this (either not having the file
 uncompressed like this or by having an action which checks for the presence
 of the file). However, what I'd like to understand is why MSI is turning
 this Error message into an Info message on upgrade.

 Any ideas?

 Thanks

 
 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get
 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Including UtilExtension a Fragment

2013-05-30 Thread John Ludlow

I think probably using burn to chain both the JRE installer and the MSI is
the best idea.

I'm pretty sure the JRE installer is just a bootstrapped MSI, so including
it in your MSI won't work (the nested MSI transaction issue).


On 30 May 2013 21:06, Alain Forget afor...@cmu.edu wrote:

 Now I'm really confused. :-)

 So to explain a bit more, the EXE is the Java Runtime Environment
 installer, and the MSI is my installer.

 So I want to include the EXE in my MSI, and (silently) run the JRE EXE if
 it isn't already installed (determined by util:RegistrySearch elements),
 before the stuff in my installer starts getting unpacked and run.

 So...if you're suggesting I put my MSI in the EXE, that's not possible,
 because I can't (or at least don't think) I can or should put my MSI in the
 JRE EXE.

 Did you have something else in mind?

 Alain

 -Original Message-
 From: Wesley Manning [mailto:wmann...@dynagen.ca]
 Sent: May 30, 2013 16:01
 To: afor...@cmu.edu; General discussion for Windows Installer XML
 toolset.; 'John Cooper'
 Subject: RE: [WiX-users] Including UtilExtension  a Fragment

 Not if you are embedding exe in msi.  The other way around maybe.

 -Original Message-
 From: Alain Forget [mailto:afor...@cmu.edu]
 Sent: May-30-13 4:55 PM
 To: 'John Cooper'; 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Including UtilExtension  a Fragment

 Hm, I've just been using Candle and Light thus far. Since I'm now
 including an EXE in my MSI, I take it I now need to use Burn? If so, is
 there a Burn tutorial somewhere? I've been unable to find one.

 Alain

 -Original Message-
 From: John Cooper [mailto:jocoo...@jackhenry.com]
 Sent: May 30, 2013 15:39
 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
 Subject: RE: [WiX-users] Including UtilExtension  a Fragment

 Do you have the Util extension added as a reference to your Burn project?

 --
 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: Alain Forget [mailto:afor...@cmu.edu]
 Sent: Thursday, May 30, 2013 2:27 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Including UtilExtension  a Fragment

 I can't figure out why Candle doesn't seem to find the RegistrySearch
 element in the util namespace, as it throws this error:

 Fragment element contains an unhandled extension element
 'util:RegistrySearch'.
  Please ensure that the extension for elements in the '
 http://schemas.microsoft.
 com/wix/UtilExtension' namespace has been provided.

 Maybe I'm not using the Fragment as it is intended? Any advice would be
 appreciated.

 This is what my source looks like:

 Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' xmlns:util=
 http://schemas.microsoft.com/wix/UtilExtension;

 Fragment
 util:RegistrySearch
 Id=Java7FamilyVersion
 Root=HKLM
 Key=SOFTWARE\JavaSoft\Java Runtime Environment
 Value=Java7FamilyVersion
 Variable=Java7FamilyVersion
 /
 util:RegistrySearch
 Root=HKLM
 Key=SOFTWARE\JavaSoft\Java Runtime
 Environment\[Java7FamilyVersion]\MSI Value=PRODUCTVERSION
 Variable=JavaProductVersion
 After=Java7FamilyVersion
 Condition=Java7FamilyVersion
 /

 PackageGroup Id=Java7Runtime
 ExePackage
 Id=Java7Runtime
 DisplayName=Java Runtime Version 7
 Cache=no
 Compressed=yes
 PerMachine=yes
 Permanent=yes
 Vital=yes
 Name=lib\jre-7u21-windows-i586.exe
 SourceFile=\lib\jre-7u21-windows-i586.exe
 InstallCommand=/s ADDLOCAL=jrecore IEXPLORER=1
 MOZILLA=1 JAVAUPDATE=0 JU=0 SYSTRAY=0 AUTOUPDATECHECK=0 REBOOT=Suppress
 /L*v quot;[WixBundleLog_Java7Runtime]quot;
 DetectCondition=Java7FamilyVersion AND
 (JavaProductVersion gt;= v7.0.210)
 /ExePackage
 /PackageGroup
 /Fragment

 Product...

 Alain

 -Original Message-
 From: Alain Forget [mailto:afor...@cmu.edu]
 Sent: May 30, 2013 14:17
 To: 'Neil Sleightholm'
 Subject: RE: [WiX-users] Download and install Java

 Oh interesting, so I don't even need to define WixBundleLog_Java7Runtime?

 Another issue: candle couldn't recognise the util prefix for the
 util:RegistrySearch elements, so I added xmlns:util=
 http://schemas.microsoft.com/wix/UtilExtension; to my top-level Wix
 element, but I'm now getting the following candle error:

 Fragment element contains an unhandled extension element
 'util:RegistrySearch'.
  Please ensure that the extension

Re: [WiX-users] newbie: how to reference variables ? (the doc is confusing)

2013-05-29 Thread John Ludlow

I think where you're getting confused is that there are more than one type
of variable in WiX. Firstly, there are preprocessor variables and
condition, which are referenced like this:

  $(var.VariableName)
  !(var.LateBoundVariableName)
  $(env.EnvironmentVariableName)
  !(loc.StringID)

These are available at build time and are used in things like string paths
and to conditionally include fragments of code based on your build
configurations. (Check out this link:
http://wix.sourceforge.net/manual-wix3/preprocessor.htm)

Then there are the MSI properties and conditions, which use a different
syntax, because it's defined by MSI and not WiX.  These are avaiable at
runtime and are used to perform logic in your install - conditionally
performing an action based on the environment or feature selection, getting
information, controlling your installation directories and stuff like that.
(Check out this link:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx
)

What you have there is an MSI condition, which looks like it's based on
MainFeature being installed. To break this down:

  (MainFeature = 3)

FeatureName gets the requested state of the feature. MainFeature = 3
means if MainFeature is selected for installation, return true.

  AND NOT

Pretty standard boolean logic - if the left hand side is true, but the
right hand side is false, this will return true.

 (!MainFeature = 3)]

!FeatureName gets the *current state* of the feature, rather than the
requested state. This means if MainFeature is *currently installed* for
installation, return true.

Put it all together, and what you get is this: If MainFeature is selected
for installation, and it's NOT currently installed, return true.

Hope that helps


On 29 May 2013 09:46, Benjamin Mayrargue benja...@vapolia.fr wrote:

 Hi all,
 i have a noob question.

 In this snippet there is a  and a ! before the variable MainFeature.
 what does that mean ?

 Condition![CDATA[(MainFeature = 3) AND NOT (!MainFeature =
 3)]]/Condition

 In the wix chm, i found the list of Wix built-in variables.
 But i'm unable to reference them, either in the bundle, or in my managed
 bootstrapper. What is the correct way to make them available ? (i'm using
 only a bundle).

 thks :)

 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] newbie: how to reference variables ? (the doc is confusing)

2013-05-29 Thread John Ludlow

Well, the bundle will *take any MSIs or other packages specified in your
Chain element** *and bootstrap them. It doesn't exactly create an MSI
itself.

It might be best if you give more details about what you're trying to
achieve, and where you're trying to use the above Condition element?


On 29 May 2013 11:36, Benjamin Mayrargue benja...@vapolia.fr wrote:

 100% understood !

 This means a 'bundle' creates a msi bootstrapped in an exe.

 B.



 2013/5/29 John Ludlow john.ludlow...@gmail.com

  I think where you're getting confused is that there are more than one
 type
  of variable in WiX. Firstly, there are preprocessor variables and
  condition, which are referenced like this:
 
$(var.VariableName)
!(var.LateBoundVariableName)
$(env.EnvironmentVariableName)
!(loc.StringID)
 
  These are available at build time and are used in things like string
 paths
  and to conditionally include fragments of code based on your build
  configurations. (Check out this link:
  http://wix.sourceforge.net/manual-wix3/preprocessor.htm)
 
  Then there are the MSI properties and conditions, which use a different
  syntax, because it's defined by MSI and not WiX.  These are avaiable at
  runtime and are used to perform logic in your install - conditionally
  performing an action based on the environment or feature selection,
 getting
  information, controlling your installation directories and stuff like
 that.
  (Check out this link:
 
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx
  )
 
  What you have there is an MSI condition, which looks like it's based on
  MainFeature being installed. To break this down:
 
(MainFeature = 3)
 
  FeatureName gets the requested state of the feature. MainFeature = 3
  means if MainFeature is selected for installation, return true.
 
AND NOT
 
  Pretty standard boolean logic - if the left hand side is true, but the
  right hand side is false, this will return true.
 
   (!MainFeature = 3)]
 
  !FeatureName gets the *current state* of the feature, rather than the
  requested state. This means if MainFeature is *currently installed* for
  installation, return true.
 
  Put it all together, and what you get is this: If MainFeature is
 selected
  for installation, and it's NOT currently installed, return true.
 
  Hope that helps
 
 
  On 29 May 2013 09:46, Benjamin Mayrargue benja...@vapolia.fr wrote:
 
   Hi all,
   i have a noob question.
  
   In this snippet there is a  and a ! before the variable MainFeature.
   what does that mean ?
  
   Condition![CDATA[(MainFeature = 3) AND NOT (!MainFeature =
   3)]]/Condition
  
   In the wix chm, i found the list of Wix built-in variables.
   But i'm unable to reference them, either in the bundle, or in my
 managed
   bootstrapper. What is the correct way to make them available ? (i'm
 using
   only a bundle).
  
   thks :)
  
  
 
 --
   Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
   Get 100% visibility into your production application - at no cost.
   Code-level diagnostics for performance bottlenecks with 2% overhead
   Download for free and get started troubleshooting in minutes.
   http://p.sf.net/sfu/appdyn_d2d_ap1
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users
  
 
 
 --
  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
  Get 100% visibility into your production application - at no cost.
  Code-level diagnostics for performance bottlenecks with 2% overhead
  Download for free and get started troubleshooting in minutes.
  http://p.sf.net/sfu/appdyn_d2d_ap1
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu

Re: [WiX-users] (no subject)

2013-05-23 Thread John Ludlow

Your question isn't entirely clear - do you want to have a text box for
an IP address in your install UI (which would depend on whether it's
Wix/MSI-based or Burn-based), or do you just want to include a
configuration file in your install to be installed along with your app?

Or something else...?


On 23 May 2013 08:51, Chaitanya Sanapala [PC-BLR-DEV] 
chaita...@pointcross.com wrote:

 Hi,



 I want to insert an IP address or some type of information from my client
 when my installation starts.

 the client has to insert the information in the UI or xml\txt file.that
 should be able to insert in the Wix file.



 How to do that



 Thanks in advance,

 sandeep.

 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] (no subject)

2013-05-23 Thread John Ludlow

The simplest method is to use a text edit control:

Control Id=myEdit Type=Edit Property=IP_ADDRESS Height=17 Width=
100 X=50 Y=50 Indirect=yes Text=[IP_ADDRESS]/

You can also use the MaskedEdit control, with PIDTemplate set to the format
for an IP address. This will allow you to have a formatted control that
will only accept IP addresses. See the doc for that type of control:
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa369797(v=vs.85).aspx.
However, this can cause issues if you have a product key dialog in your
install. This also has the downside that the user wouldn't be able to enter
a URL or DNS alias, even where those would resolve to the same IP address.

Once you have the value in a property (I'm using the IP_ADDRESS property
above)

Generally speaking, though, think about whether your install should be
handling this. If this is a UI application, a better user experience can
usually be achieved by the application asking for this information at
start-time, rather than the install trying to do it. You may also find that
you have to duplicate more stuff because your application still needs that
UI because the address might change.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!

2013-05-23 Thread John Ludlow

Do you have any duplicate GUIDs in your installer? Also, is the
installation path changing when you do the upgrade? (by which I mean, do
those files end up in a different folder on the target machine?)


On 23 May 2013 15:37, Dave Moss davidm...@omprompt.com wrote:

 Just for a bit of extra information if I run the bootstrapper install and
 then run just the application msi for the upgrade it works fine so it seems
 to be an issue from running the upgrade through the bootstrapper.

 Jacob, the keypaths and component id's remain the same.


 Dave Moss
 Tactical Team Lead
 OmPrompt
 +44 (0)1235 436014 Direct
 davidm...@omprompt.com
 www.omprompt.com

 OmPrompt Limited is registered in England  Wales, registration No.
 4452522, with registered offices at 67 Innovation Drive, Milton Park,
 Abingdon, Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.

 -Original Message-
 From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
 Sent: 23 May 2013 15:32
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!

 Is your key path and/or component ids changing with each new installer?
 Open up two versions of your installer in Orca, and for any given file that
 isn't there after the major upgrade compare the component ID's.

 -Original Message-
 From: Dave Moss [mailto:davidm...@omprompt.com]
 Sent: Thursday, May 23, 2013 4:21 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Major upgrade using bootstrapper issue -HELP!!

 Hi,

 I am pretty new to the world of WiX but have found it to be a very useful
 tool. I am having the following issue however and after 2 days of googling
 it is driving me nuts.

 I have a bootstrapper that install .net 4.0 if required and then installs
 my msipackage.

 I opted for the major upgrade everytime when making changes to the files
 installed.  Each of my executable files have their version number updated
 to the current revision number in SVN.  When I install my application the
 first time it installs fine and all the services are started and installed
 and all the required files are there.  When I run the next version of the
 installer (so a major upgrade) it seems to be installing the new msi and
 then uninstalling the old one. At this point all that is left on my machine
 is the service executables and nothing else, all the other files have been
 removed including the .exe.config files rendering the application useless.
  Any ideas what I am doing wrong, its driving me crazy!!!

 Here is my bundle.wxs
 ?xml version=1.0 encoding=UTF-8?
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
   Bundle Name=Document Converters Version=$(var.Version)
 Manufacturer=company name UpgradeCode=UPGRADE-GUID
 Condition=((VersionNT = v5.1) AND (ServicePackLevel = 3)) OR ((VersionNT
 = v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = v6.0)


 BootstrapperApplicationRef
 Id=WixStandardBootstrapperApplication.HyperlinkLicense /
 WixVariable Id=WixStdbaLogo Value=Resource\logo.png /
 WixVariable Id=WixStdbaLicenseUrl Value= /
 Variable Name=InstallFolder Type=string
 Value=[WindowsVolume]company name\application /
 Variable Name=LaunchTarget Value=[InstallFolder]\application.exe/

 Chain
   PackageGroupRef Id=NetFx40Redist /

   RollbackBoundary /

   MsiPackage
 Id=WIXConverterInstaller
 Compressed=yes
 SourceFile=$(var.WIXConverterInstaller.TargetPath)
 Vital=yes
 MsiProperty Name=INSTALLFOLDER Value=[InstallFolder] /
   /MsiPackage
 /Chain
   /Bundle
 /Wix

 Here is my bootstrapper project file.

 ?xml version=1.0 encoding=utf-8?
 Project ToolsVersion=4.0 DefaultTargets=Build xmlns=
 http://schemas.microsoft.com/developer/msbuild/2003;
   PropertyGroup
 Configuration Condition= '$(Configuration)' == ''
 Debug/Configuration
 Platform Condition= '$(Platform)' == '' x86/Platform
 ProductVersion3.7/ProductVersion
 ProjectGuid{7ae67f4b-d014-4008-9373-35cb5aeffb36}/ProjectGuid
 SchemaVersion2.0/SchemaVersion
 OutputNameDocumentConverterInstallerV2.8-B$(BuildNo)/OutputName
 OutputTypeBundle/OutputType
 WixTargetsPath Condition= '$(WixTargetsPath)' == '' AND
 '$(MSBuildExtensionsPath32)' != ''
 $(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets/WixTargetsPath
 WixTargetsPath Condition= '$(WixTargetsPath)' == ''
 $(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets/WixTargetsPath
 NameDocumentConverterInstaller/Name
 Version
 /Version
 BuildNo Condition= '$(BuildNo)' == ''1/BuildNo
   /PropertyGroup
   PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Debug|x86'
 
 OutputPathbin\$(Configuration)\/OutputPath
 IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath
 DefineConstantsDebug/DefineConstants
   /PropertyGroup
   PropertyGroup Condition= '$(Configuration)|$(Platform)' ==
 'Release|x86'

Re: [WiX-users] Writing a WiX tutorial

2013-05-20 Thread John Ludlow

Hi Natalie,

Have you seen the tutorial at http://wix.tramontana.co.hu/? You may want to
emulate this, since it's a good tutorial for general use, but you may want
one tailored to your team and your product. You should include topics on
things that you use (for example, Burn, patching and early REPs), as well
as WiX/MSI conventions and best practices. Also describe how your code is
organised and how you'd build it.

On 20 May 2013 09:30, Natalie Carr natalie.c...@measuresoft.com wrote:

 Hi,



 I have been asked to write a WiX tutorial for my colleagues to take over my
 role when I leave. Has anyone written anything like this that they would be
 willing to help me out with? I am using the WiX tutorial online but would
 like your opinions on what I should include.



 Thanks

 Natalie


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Getting install path from Wix Custom Action

2013-05-20 Thread John Ludlow

This is probably because your CA is scheduled as immediate, rather than
deferred. You need to set Execute=deferred, and Impersonate=no on your
CustomAction element.

However, this presents a problem - deferred CAs do not get access to
properties. Instead, you need to use the CustomActionData special property.
You set a property with the same name as your action (in this case,
SetEfxZlibLibraryAction) to the data that you want to make available to the
custom action. The DTF method (session.CustomActionData) for this in C# has
some special parsing rules which can be used to pass in multiple elements
of data.


On 20 May 2013 17:55, Freedman, Mark P. mark.freed...@jhuapl.edu wrote:

 Turns out the attribute I was trying to use was INSTALLFOLDER, not
 INSTALLDIR, as specified in my Product.wxs. So now, that resolves to the
 path I expect.

 However, I'm having a new issue. The custom action is trying to work on a
 file that's expeted to be present in my INSTALLFOLDER. I put some
 MessageBoxes in the CA for debugging purposes. When the CA is firing, the
 files havne't been copied over to the install directory yet. I'd think that
 my files would be there at the time since the action isn't firing until
 after InstallFiles. What other options do I have?

 Also, my custom action appears to be firing when I uninstall the program.
 Again, this is confusing to me given that the action isn't firing until
 after InstallFiles.

 Thanks.

 Mark Freedman


 -Original Message-
 From: John Cooper [mailto:jocoo...@jackhenry.com]
 Sent: Monday, May 20, 2013 12:49 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Getting install path from Wix Custom Action

 First off, scheduling.  The values of Directory properties (including one
 like INSTALLDIR), aren't going to be meaningful until after CostFinalize.
  Since you're running in the InstallExecSequence after InstallFiles, that's
 not it.

 However, you should be able to resolve INSTALLDIR like any other public
 property.  If session[INSTALLDIR] resolves to nothing, I'm thinking you
 haven't saved/restored this property.  Is this running in a Repair or
 Upgrade?

 --
 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: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
 Sent: Monday, May 20, 2013 11:30 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Getting install path from Wix Custom Action

 I have a custom action and am trying to access the Install Directory, or
 Target path (the base folder that the user chooses to install to).

 Within my Action, I tried pulling it from Session. TARGETDIR maps to
 C:\, despite installing it to program files, and INSTALLDIR yields empty
 stirng. What am I missing? I also tried passing the INSTALLDIR in the
 CustomAction tag with the Directory attribute, but it comes back saying
 that it can't be something in brackets.


 [CustomAction]
 public static ActionResult SetEfxZlibLibrary(Session session) {
 session.Log(Begin CA);

 string installDirectory = session[INSTALLDIR];

 // 
 }


 ?xml version=1.0 encoding=UTF-8?
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
   ?include Includes.wxi ?
 Fragment
 CustomAction Id='SetEfxZlibLibraryAction'
 BinaryKey='CustomActionBinary' DllEntry='SetEfxZlibLibrary'
 Execute='immediate'
   Return='check'/

 Binary Id=CustomActionBinary
 SourceFile=$(var.CustomInstallActionsFile)/
 /Fragment
 /Wix



 Thanks,

 Mark Freedman


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_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.



 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential

Re: [WiX-users] Getting install path from Wix Custom Action

2013-05-20 Thread John Ludlow

You should be able to do something along these lines:

  foreach (var k in session.CustomActionData.Keys)
  {
session.Log(k +  =  + session.CustomActionData[k]);
  }

But you would have to have set the CA data property for that custom action,
I think.




On 20 May 2013 18:26, Freedman, Mark P. mark.freed...@jhuapl.edu wrote:

 The execute attribute on Custom action lets you choose immediate,
 deferred, etc. An issue I'm seeing in the installer is that accessing a
 Session attribute is only allowed if it's immediate execution. So this
 makes me think it has to be immediate, but must be after a step that's
 after InstallFiles, since the files aren't actually installed. Is there a
 set list of the action steps?

 Exception thrown by custom action:
 System.Reflection.TargetInvocationException: Exception has been thrown by
 the target of an invocation. ---
 Microsoft.Deployment.WindowsInstaller.InstallerException: Cannot access
 session details from a non-immediate custom action
at Microsoft.Deployment.WindowsInstaller.Session.ValidateSessionAccess()
at Microsoft.Deployment.WindowsInstaller.Session.get_Item(String
 property)
at CustomInstallActions.CustomActions.SetEfxZlibLibrary(Session session)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
 method, Object target, Object arguments, SignatureStruct sig,
 MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
 method, Object target, Object arguments, Signature sig, MethodAttributes
 methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
 invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean
 skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
 invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at
 Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32
 sessionHandle, String entryPoint, IntPtr remotingDelegatePtr)

 When I changed the Action to execute After=InstallFinalize, I was able
 to access the session details and the files were in the install directory.
 However, my action is failing to do what it's trying to do because of
 permissions. The action is attempting to make a copy of a file with a new
 name based on if the system is 32/64. I'm guessing the step I'm in in the
 installer isn't a step where it has permissions. I'm not sure where I
 should be doing these actions, I was able to get these to function in a
 Visual Studio deployment project custom action without much grief.


 Mark Freedman


 -Original Message-
 From: Phil Wilson [mailto:phil.wil...@mvps.org]
 Sent: Monday, May 20, 2013 1:18 PM
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Getting install path from Wix Custom Action

 The execute sequence runs twice, in custom action terminology the first is
 immediate, when Windows is writing a script to do the install; the second
 time it's deferred when applied to custom actions, when the system
 actually gets changed. That means you can be after InstallFiles in an
 immediate custom action and the files haven't been copied yet. You need
 immediate=no, I think that's the syntax.

 Custom actions have conditions. A typical condition to cause a CA to run
 only at install time is (case sensitive) Not Installed

 Phil

 -Original Message-
 From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
 Sent: Monday, May 20, 2013 9:55 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Getting install path from Wix Custom Action

 Turns out the attribute I was trying to use was INSTALLFOLDER, not
 INSTALLDIR, as specified in my Product.wxs. So now, that resolves to the
 path I expect.

 However, I'm having a new issue. The custom action is trying to work on a
 file that's expeted to be present in my INSTALLFOLDER. I put some
 MessageBoxes in the CA for debugging purposes. When the CA is firing, the
 files havne't been copied over to the install directory yet. I'd think that
 my files would be there at the time since the action isn't firing until
 after InstallFiles. What other options do I have?

 Also, my custom action appears to be firing when I uninstall the program.
 Again, this is confusing to me given that the action isn't firing until
 after InstallFiles.

 Thanks.

 Mark Freedman


 -Original Message-
 From: John Cooper [mailto:jocoo...@jackhenry.com]
 Sent: Monday, May 20, 2013 12:49 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Getting install path from Wix Custom Action

 First off, scheduling.  The values of Directory properties (including one
 like INSTALLDIR), aren't going to be meaningful until after CostFinalize.
 Since you're running in the InstallExecSequence after

Re: [WiX-users] Creating patches

2013-05-02 Thread John Ludlow

I don't think the version number of a binary is taken into account when
analysing differences for byte-level patches.  Try setting
WholeFilesOnly=yes (
http://wix.sourceforge.net/manual-wix3/wix_xsd_patchcreation.htm).


On 2 May 2013 10:31, Thomas Due t...@scanvaegt.dk wrote:

 Hello,

 I am trying to grasp the concept of minor and small upgrades, but I am
 having some trouble with getting it to work.

 First of all, it doesn't seem to work at all with 3.7.
 I have downgraded my WiX to 3.5, and there something happens at least, but
 my msp seems to be empty when I examine it with instead (
 http://www.instedit.com/).

 A bit about what I do:
 I have a fairly complex installer with a couple of hundred files total,
 divided among 4 features. I build this with TeamCity, and I have two
 separate installers (no real changes, except for the version nummer -
 1.2.0.22679 and 1.2.5.22754). I imagine that this should be enough to
 generate something.

 I have a build script, a simple batch file, which executes the four steps
 described in both the WiX doc and Nick Ramirez' book.

 My patch.wxs then includes a couple of file components, as I want these
 replaces (mind you, I am still in the testing phase, trying to understand
 the concept).

 First my build script:
 ===
 %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out diff.wixmst
 %wixdir%bin\candle.exe -v Patch.wxs
 %wixdir%bin\Light.exe -v Patch.wixobj -out patch.wixmsp
 %wixdir%bin\pyro.exe -v patch.wixmsp -out patch.msp -t Patch diff.wixmst

 %oldmsi% and %newmsi are complete paths to the wixpdb files for
 respectively old and new installer.
 Then my Patch.wsx:
 ===
 ?xml version=1.0 encoding=utf-8?
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
 ?include BuildVariables.wxi ?
 Patch AllowRemoval=yes
Classification=Update
Manufacturer=$(var.Manufacturer)
Description=Patch
DisplayName=Patch $(var.CurVersion)
 Media Id=1000 Cabinet=´Patch.cab EmbedCab=yes
 PatchBaseline Id=Patch /
 /Media
 PatchFamily Id=ScanXNETPatchFamily
  Version=$(var.CurVersion)
  Supersede=yes
 ComponentRef Id=ComponentCommonExtensions /
 ComponentRef Id=ComponentMainClient/
 /PatchFamily
 /Patch
 /Wix

 BuildVariables.wxi is simply a number of preprocessor variables, which is
 shared with the installer project.

 Now, as I said, with 3.7 I get this result:
 Updating file information.
 Creating cabinet files.
 There will be '8' threads used to produce CAB files.
 Patch.wxs(20) : warning PYRO1079 : The cabinet 'ïPatch.cab' does not
 contain any files.  If this patch contains no files, this warning can
 likely be safely ignored.  Otherwise, try passing -p to torch.exe when
 first building the transforms, or add a ComponentRef to your PatchFamily
 authoring to pull changed files into the cabinet.
 Creating cabinet '\Local\Temp\kvov1bbk\#ïPatch.cab'.
 Generating database.
 diff.wixmst : error PYRO0227 : The transform being built did not contain
 any differences so it could not be created.

 Which is probably an indication of what is actually wrong. With 3.5 I get
 an empty msp.

 What am I doing wrong?









 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall Order [P]

2013-05-02 Thread John Ludlow

It would be interesting, but I'm struggling to imagine out how the syntax
would work in your .wxs code if you were able to override this
behaviour. You could have two integer attributes on each package (one for
install order and one for uninstall order) but I bet that would be hard to
maintain if you, say, inject a new install into the sequence, and what
would be the behaviour if you specify one and not the other?

In the stated use case, I would say that adding a ServiceControl record to
the SQL MSI (to stop the service when this MSI is removed) is the easiest
way to handle this.


On 2 May 2013 16:30, Rob Mensching r...@robmensching.com wrote:

 Definitely is, yes.  Tons of people would be complaining if it wasn't in
 that order. You'd essentially remove perquisites then try to remove
 application. Not likely to work out well in many cases. smile/


 On Thu, May 2, 2013 at 8:25 AM, Nick Miller nmil...@livetechnology.com
 wrote:

  Seems to be, yes.
 
 
  -Original Message-
  From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
  Sent: Thursday, May 02, 2013 11:21 AM
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] Uninstall Order [P]
 
  Classification: Public
  If I am not mistaken it is FILO (first in, last out) order?
 
  -Original Message-
  From: Nick Miller [mailto:nmil...@livetechnology.com]
  Sent: May-02-13 11:11 AM
  To: General discussion for Windows Installer XML toolset. (
  wix-users@lists.sourceforge.net)
  Subject: [WiX-users] Uninstall Order
 
  Hi All,
 
  I have another question for you guys.  Is there any way to specify the
  uninstall order in my bootstrappers chain?  The reason I ask, is because
 I
  have two MSI's, the first one installs the application, and the second
  installs the sql data.  There is a service that runs which accesses the
 SQL
  databases created by the second MSI.  The problem:  when I uninstall, it
  tries to remove the SQL MSI first, and fails because the databases are in
  use by the service.  I would like bundle to uninstall in the same order
  that it installed.  Is this possible?
 
  Thanks,
  Nick
 
 
 
 
 --
  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
  Get 100% visibility into your production application - at no cost.
  Code-level diagnostics for performance bottlenecks with 2% overhead
  Download for free and get started troubleshooting in minutes.
  http://p.sf.net/sfu/appdyn_d2d_ap1
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
  This message has been marked as Public by Steven Ogilvie on May-02-13
  11:21:11 AM.
 
  The above classification labels were added to the message by TITUS
 Message
  Classification. For more information visit www.titus.com.
 
 
 
 --
  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
  Get 100% visibility into your production application - at no cost.
  Code-level diagnostics for performance bottlenecks with 2% overhead
  Download for free and get started troubleshooting in minutes.
  http://p.sf.net/sfu/appdyn_d2d_ap1
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 
 
 --
  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
  Get 100% visibility into your production application - at no cost.
  Code-level diagnostics for performance bottlenecks with 2% overhead
  Download for free and get started troubleshooting in minutes.
  http://p.sf.net/sfu/appdyn_d2d_ap1
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 

 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.

Re: [WiX-users] Set Directory @ Runtime

2013-04-23 Thread John Ludlow

You probably have the action sequenced incorrectly. Make sure it comes
after CostFinalize, because it's only at this point that the install
understands the parent-child relationship between the directories.

Also, read this to see whether the issues described apply to you:
http://blogs.msdn.com/b/heaths/archive/2006/06/14/be-careful-or-even-avoid-using-type-35-custom-actions.aspx


On 23 April 2013 06:00, yogesh bandiwadekar
yogesh.bandiwade...@gmail.comwrote:

 Hi All
 Below shown is my directory structre.

 Directory Id=TARGETDIR Name=SourceDir 
Directory Id =DIRVMSOS Name=VMSOS
 Directory Id=DIR_VMSOS_CONFIG Name=Config /
 Directory Id=DIR_VMSOS_CONFIG2 Name=Config2/
 Directory Id=DIR_VMSOS_LICENCE Name=License/
 Directory Id=DIR_VMSOS_USERRIGHTS Name=UserRights
   Directory Id=DIR_SHARED Name=Shared /
 /Directory
   /Directory
   Directory Id=ProgramFilesFolder
 Directory Id=DIR_PRODUCT_SYSLOGD Name=Syslogd
   Directory Id=DIR_PRODUCT_SYS_CUSTOM Name=Customize/
 /Directory
   /Directory
  /Directory

 I am changing DIRVMSOS Dynamically with type 35 custom action.
 This custom action only changes DIRVMSOS value not the child directory
 value.

 for example

 I set DIRVMSOS =d:\temp
 it get set to d:\temp but child directory points to defalut location that
 is c:\VMSOS\Config, c:\VMSOS\Config2, c:\VMSOS\License

 Can anybody tell me what is wrong  in it?
 What do i need to do for this?

 Thanks
 Yogesh

 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why in Preprocessor the Not Equal To is != while in conditional string is .

2013-04-18 Thread John Ludlow

 is also the syntax in Visual Basic, and VB / VBA has always had strong
ties to Office, which is where MSI originated from IIRC.


On 18 April 2013 13:35, Hans ter Horst hoshis...@gmail.com wrote:

 Thanks, I think I have it working!



 On Thu, Apr 18, 2013 at 2:13 PM, Alain Forget afor...@cmu.edu wrote:

   is the MySQL (and SQL in general?) not equal to, so maybe that's
  where it came from?
 
  -Original Message-
  From: Pally Sandher [mailto:pally.sand...@iesve.com]
  Sent: April 18, 2013 06:42
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] Why in Preprocessor the Not Equal To is !=
  while in conditional string is .
 
  Because the WiX team wrote the WiX pre-processor syntax  kept it to
  regularly accepted coding standards (hence != for 'not equal to' as per
  every other modern programming language) while the Conditional Statement
  syntax was written by the Windows Installer team back in the mists of
 time?
 
  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
 
 
  -Original Message-
  From: uni [mailto:unigauld...@gmail.com]
  Sent: 18 April 2013 06:08
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Why in Preprocessor the Not Equal To is != while
  in conditional string is .
 
  It is not very intuitive.
  I first write:
  ?if $(var.CurrentVersion)$(var.MinimumVersion)?
  and it says:
  error CNDL0162: An illegal number was found in the expression
  '$(var.CurrentVersion)$(var.MinimumVersion)'.
 
 
 
 --
  Precog is a next-generation analytics platform capable of advanced
  analytics on semi-structured data. The platform includes APIs for
 building
  apps and a phenomenal toolset for data science. Developers can use our
  toolset for easy data analysis  visualization. Get a free account!
  http://www2.precog.com/precogplatform/slashdotnewsletter
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 
 
 --
  Precog is a next-generation analytics platform capable of advanced
  analytics on semi-structured data. The platform includes APIs for
 building
  apps and a phenomenal toolset for data science. Developers can use
  our toolset for easy data analysis  visualization. Get a free account!
  http://www2.precog.com/precogplatform/slashdotnewsletter
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 
 --
  Precog is a next-generation analytics platform capable of advanced
  analytics on semi-structured data. The platform includes APIs for
 building
  apps and a phenomenal toolset for data science. Developers can use
  our toolset for easy data analysis  visualization. Get a free account!
  http://www2.precog.com/precogplatform/slashdotnewsletter
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 



 --
 http://monochrome.me.uk/blog/

 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Custom Managed Bootstrapper Application Host behaviour

2013-04-02 Thread John Ludlow

Hi,

I've been looking at developing a custom managed bootstrapper application,
based on the examples in the following articles:

http://wrightthisblog.blogspot.co.uk/2013/01/part-1-of-writing-your-own-net-based.html

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx

These seem to use the ManagedBootstrapperApplicationHost, which does a few
things around checking for and installing .NET. I'd like to know if I can
customize this behaviour (or perhaps even remove it).

My understanding of how this works is that there are actually two
bootstrappers - an unmanaged one which checks for .NET, and installs it if
necessary (but is generally hidden from the developer), and a managed one
which is the actual install. This has caused some concerns amongst our
team.

One of these concerns was the slightly more painful debugging experience,
because the process which would get launched is not the 'real' process
which we want to debug. There are tricks you can use (Heath Stewart
described a way of setting up Global Flags to first break into the first
one, F5 to continue, then break into the managed code) but it seemed like
it would be simpler if the bootstrapper project could just kick out the
managed bootstrapper output on its own without the unmanaged bootstrapper
getting in the way (at least for debugging purposes).

The second concern was whether we can customize the unmanaged bootstrapper
at all, changing the logo, descriptive text, and perhaps also changing the
action to show an error rather than installing .NET automatically.

Are these things possible? I was thinking that we could build a WixStdBA
bootstrapper which calls our managed bootstrapper.

Thanks

John
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Managed Bootstrapper Application Host behaviour

2013-04-02 Thread John Ludlow

Forgot to mention - I'm using WiX 3.6

On 2 April 2013 11:59, John Ludlow john.ludlow...@gmail.com wrote:

Hi,

I've been looking at developing a custom managed bootstrapper application,
based on the examples in the following articles:

http://wrightthisblog.blogspot.co.uk/2013/01/part-1-of-writing-your-own-net-based.html

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx

Are these things possible? I was thinking that we could build a WixStdBA
bootstrapper which calls our managed bootstrapper.

Thanks

John

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Managed Bootstrapper Application Host behaviour

2013-04-02 Thread John Ludlow

Hi Rob,

Thanks for clearing up my confusion - I think I have a better understanding
of how it works now, but I do have a couple of follow-up questions:

Re debugging, when you say that there are two processes if elevation is
required, is this affected by whether UAC is enabled (it's not enabled on
my box) or is it affected by whether the embedded packages are specified as
PerMachine / ALLUSERS=2? Also, does bitness affect this at all, such as
debugging a bootstrapper that contains x86 MSIs?

2. I thought it was probably the same mechanism, but all the examples I
found basically used the same code. If setting the usual properties works
in the same way as for the standard BA, then I think that would serve our
needs.

Thanks!

John
On 2 April 2013 14:30, Rob Mensching r...@robmensching.com wrote:

1. Debugging - there are two *Bootstrapper Applications* (the .dlls that
get loaded by the engine to drive the user experience) but there is still
only one executable (one engine). If the managed BA cannot be loaded the
host tells the engine to fallback and load the mbapreq BA instead to get
NETFX installed. If that happens without a restart then the mbapreq says
to go load the managed BA. That all happens in the same process.

2. Debugging - you will see two executables running when elevation is
required. If you start the process elevated, you'll immediately see the
user mode process executable get created. *That* makes debugging harder but
if you debug from an unelevated process debugging is very straight forward.

3. Customize - the mbapreq is just the wixstdba with a tiny bit of
different internal logic (like reload mba host when complete instead of
close when complete). That means all the customizations you can do to
wixstdba, you can do to the mbapreq.

On Tue, Apr 2, 2013 at 4:08 AM, John Ludlow john.ludlow...@gmail.com
wrote:

Forgot to mention - I'm using WiX 3.6

On 2 April 2013 11:59, John Ludlow john.ludlow...@gmail.com wrote:

Hi,

I've been looking at developing a custom managed bootstrapper
application,
based on the examples in the following articles:

http://wrightthisblog.blogspot.co.uk/2013/01/part-1-of-writing-your-own-net-based.html

http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/

http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx

These seem to use the ManagedBootstrapperApplicationHost, which does a
few
things around checking for and installing .NET. I'd like to know if I
can
customize this behaviour (or perhaps even remove it).

My understanding of how this works is that there are actually two
bootstrappers - an unmanaged one which checks for .NET, and installs it
if
necessary (but is generally hidden from the developer), and a managed
one
which is the actual install. This has caused some concerns amongst our
team.

One of these concerns was the slightly more painful debugging
experience,
because the process which would get launched is not the 'real' process
which we want to debug. There are tricks you can use (Heath Stewart
described a way of setting up Global Flags to first break into the
first
one, F5 to continue, then break into the managed code) but it seemed
like
it would be simpler if the bootstrapper project could just kick out the
managed bootstrapper output on its own without the unmanaged
bootstrapper
getting in the way (at least for debugging purposes).

The second concern was whether we can customize the unmanaged
bootstrapper
at all, changing the logo, descriptive text, and perhaps also changing
the
action to show an error rather than installing .NET automatically.

Are these things possible? I was thinking that we could build a
WixStdBA
bootstrapper which calls our managed bootstrapper.

Thanks

John

Re: [WiX-users] Custom Managed Bootstrapper Application Host behaviour

2013-04-02 Thread John Ludlow

Nice, I'll play with that tomorrow.

Thanks


On 2 April 2013 19:02, tom tomer.d...@intergraph.com wrote:


 Also search in this forum for /AutoDebugAttacher/ class
 This is a utility class created by one of the forum members which
 automatically attach the active debugger
 To the bootstarpper




 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Managed-Bootstrapper-Application-Host-behaviour-tp7584814p7584822.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Minimize network downtime and maximize team effectiveness.
 Reduce network management and security costs.Learn how to hire
 the most talented Cisco Certified professionals. Visit the
 Employer Resources Portal
 http://www.cisco.com/web/learning/employer_resources/index.html
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Question about conditional statements in elements

2013-03-23 Thread John Ludlow

That's true in theory but in practice it's often better to change it
every build. This simplifies the upgrade semantics (upgrade is an
upgrade is an upgrade, rather than worrying about whether it's a small
update, minor upgrade or major upgrade) and makes it much easier to
test that your product can be upgraded by later versions before
release.

I think there are probably upgrade scenarios where a major upgrade
isn't advisable, but I've never seen such a scenario and I can't think
what they might be off the top of my head.

On 23 March 2013 13:28, Bruce Cran br...@cran.org.uk wrote:
 On 22/03/2013 17:24, Daniel Madill wrote:
 Hi Alain,

 In general, Product ID=* is a good thing. Each new build should generate a 
 new product code because it typically means you've made changes to the 
 product (i.e. made a new version). If you want to test the Maintenance 
 dialog then run the same MSI (without rebuilding it!) twice.

 When you use the MajorUpgrade element in WiX it handles removing the old 
 version and installing the new version when you upgrade. Hence, in many 
 cases the Welcome dialog is entirely appropriate because the user experience 
 on upgrade or new installation from a UI perspective is similar. The 
 MajorUpgrade element has options for displaying messages if the user tries 
 to upgrade or downgrade and should not be allowed, etc. if that's what you 
 need. If you want something more complicated on upgrade then you will have 
 to do a little more work.

 Microsoft says the Product Code should identify a particular release
 (http://msdn.microsoft.com/en-gb/library/windows/desktop/aa370854(v=vs.85).aspx):

 The ProductCode property is a unique identifier for the particular
 product release, represented as a string GUID, for example
 {12345678-1234-1234-1234-123456789012}.

 That seems to imply it shouldn't be changed from one build to the next
 but only when the major, minor or revision fields are changed.

 --
 Bruce Cran

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Question about conditional statements in elements

2013-03-22 Thread John Ludlow

Dangit Chris, beat me to it :)

Switch on verbose logging (http://support.microsoft.com/kb/314852),
and look for something like this:

MSI (c) (14:28) [11:56:32:469]: Doing action: FindRelatedProducts
Action 11:56:32: FindRelatedProducts. Searching for related applications
Action start 11:56:32: FindRelatedProducts.
FindRelatedProducts: Found application: {XX----X}

Immediately following this you should get some PROPERTY CHANGE events,
which will be the property defined in the upgrade table as what should
be set when it finds an upgrade.

On 22 March 2013 15:49, Christopher Painter chr...@iswix.com wrote:

 It means an MSI sharing this ProductCode  ( either this PackageCode which
 would indicate a maintenance transaction or another PackageCode which would
 indicate a small or minor update ) is already installed.  In the case of a
 Major Upgrade the ProductCode has been changed and therefore from this new
 MSI's perspective it is not yet installed.

   is a special operator regarding features.  See the links I sent in my
 other email.

 Regards,
 Chris

 
  From: Alain Forget afor...@cmu.edu
 Sent: Friday, March 22, 2013 10:47 AM
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Question about conditional statements in elements

 As far as I understand it, Installed means, Before this installer was
 run, a version of this program was already installed on
 this machine. Someone please correct me if that isn't quite true.

 As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax
 yet.

 Alain

 -Original Message-
 From: Ackerman, Buddy [mailto:backer...@tnsi.com]
 Sent: March 22, 2013 11:39
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Question about conditional statements in elements

 I'm very new to WiX and have inherited an existing project.  I've been
 deciphering it fine except for a few things.  In this project
 I have the following element:

 Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show

 The question with this is the NOT Installed condition.  What exactly does
 Installed mean?  When I run this to upgrade and
 already installed application this dialog still shows up. SO, I'm not sure
 what Installed really means (there is also an Upgrade
 element in the project with a property assigned to it that is used in other
 controls throughout the project).

 Next is the following syntax that I have in several control conditional
 statements:

 ftDatabase=3

 The ftDatabase is the ID of one of the Features.  However, I don't know
 what value it would have.  Is this an install level value or
 install type value?

 Thanks for some newbie help.

 
 This e-mail message is for the sole use of the intended recipient(s)and may
 contain confidential and privileged information of
 Transaction Network Services.
 Any unauthorised review, use, disclosure or distribution is prohibited. If
 you are not the intended recipient, please contact the
 sender by reply e-mail and destroy all copies of the original message.

 
 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics Download AppDynamics Lite for
 free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 
 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Question about conditional statements in elements

2013-03-22 Thread John Ludlow

That would probably explain it as well.

By default, I believe WiX will use a property called
WIX_UPGRADE_DETECTED. Again, remember that WiX is just a way of
creating MSI files, so that MajorUpgrade element creates entries in
the Upgrade table in the install. One of the columns in this table
defines the property to set if a matching upgrade code is found. You
can examine the contents of that table using a tool called Orca
(http://msdn.microsoft.com/en-gb/library/windows/desktop/aa370557(v=vs.85).aspx)

The other way to find out what property it's *actually* using is by
examine the log for PROPERTY CHANGE events emitted by
FindRelatedProducts.

Hope that helps

On 22 March 2013 16:52, Phil Wilson phil.wil...@mvps.org wrote:
 Ah, the other explanation is that you installed that MSI in a per User
 context, and now you're installing it a different user context (another user
 or per System).

 Phil

 -Original Message-
 From: Phil Wilson [mailto:phil.wil...@mvps.org]
 Sent: Friday, March 22, 2013 9:51 AM
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: RE: [WiX-users] Question about conditional statements in elements

 Yes, the Installed property means this ProductCode is installed. If you
 see that Welcome dialog again the most obvious thing to check is whether the
 ProductCode has changed. The idea is that you only see the Welcome dialog on
 fresh first time install. Later actions based on the same ProductCode are
 maintenance options, feature add/remove etc.

 It's got to be the ProductCode changing. This stuff works all the time and
 has done for years. This is a Windows Installer property used in every
 MSI-based install, whether WiX or not. It's not likely that such a basic
 thing doesn't work.

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as
 px

 Phil

 -Original Message-
 From: Ackerman, Buddy [mailto:backer...@tnsi.com]
 Sent: Friday, March 22, 2013 9:32 AM
 To: chr...@iswix.com; General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Question about conditional statements in elements

 So what property is it actually checking to see if it's installed?  On my
 product element there is a Version attribute and there is an UpgradeCode
 attribute, are these what are being used?

 Again I have already installed the product and when I run the installer
 again (with the Version attribute change to a higher minor version) this
 dialog still shows.  I actually want the dialog to show but I am just
 curious as to why it is still showing given this criteria.

 Thanks.


 -Original Message-
 From: Christopher Painter [mailto:chr...@iswix.com]
 Sent: Friday, March 22, 2013 11:50 AM
 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.;
 General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Question about conditional statements in elements


 It means an MSI sharing this ProductCode  ( either this PackageCode which
 would indicate a maintenance transaction or another PackageCode which would
 indicate a small or minor update ) is already installed.  In the case of a
 Major Upgrade the ProductCode has been changed and therefore from this new
 MSI's perspective it is not yet installed.

   is a special operator regarding features.  See the links I sent in my
 other email.

 Regards,
 Chris

 
  From: Alain Forget afor...@cmu.edu
 Sent: Friday, March 22, 2013 10:47 AM
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Question about conditional statements in elements

 As far as I understand it, Installed means, Before this installer was
 run, a version of this program was already installed on this machine.
 Someone please correct me if that isn't quite true.

 As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet.

 Alain

 -Original Message-
 From: Ackerman, Buddy [mailto:backer...@tnsi.com]
 Sent: March 22, 2013 11:39
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Question about conditional statements in elements

 I'm very new to WiX and have inherited an existing project.  I've been
 deciphering it fine except for a few things.  In this project I have the
 following element:

 Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show

 The question with this is the NOT Installed condition.  What exactly does
 Installed mean?  When I run this to upgrade and already installed
 application this dialog still shows up. SO, I'm not sure what Installed
 really means (there is also an Upgrade element in the project with a
 property assigned to it that is used in other controls throughout the
 project).

 Next is the following syntax that I have in several control conditional
 statements:

 ftDatabase=3

 The ftDatabase is the ID of one of the Features.  However, I don't know what
 value it would have.  Is this an install level

1 2 >

1 - 100 of 158 matches

Mail list logo