date:20140124

Thanks for the responses guys, that helps a lot.

John: do you have any blog posts or anything that speaks to how you're
deploying databases and such with WiX with SqlPackage.exe? My other post
talks about some of the pain I'm having with a very large SQL script (144k
lines) and wondering if SqlPackage.exe would alleviate some of that.

Thanks,

Levi


On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

 If they are not in DTF then the WiX toolset doesn’t provide them. It’s
 assumed that most of what drove you to managed code would already be in the
 Framework so there isn’t the same level of need to invent the wheel.


 Having said that, I like John’s reply. Cool system. I’ll have to remember
 that next time I’m faced with installers populating databases.






 Blair





 From: Levi Wilson
 Sent: Thursday, January 23, 2014 6:37 AM
 To: General discussion for Windows Installer XML toolset.





 Being out of the WiX installer world for a handful of years, I was used to
 writing all of my custom actions in C++. Getting back into this I noticed
 that it is now acceptable to write them in C# and the DTF.

 That being said, I have a custom action that is currently written in C++
 that checks for the existence of a database as well as to verify if a
 particular table exists. For that, I am using the sqlutil.lib to make that
 easier. In C# custom actions, is there an equivalent or do most people just
 use SqlConnection / SqlCommand out of the .NET framework?

 Apologies if this is an obvious question, I just didn't want to re-invent
 the wheel if WiX had a helper library to assist with this. I didn't see any
 SQL related classes in DTF.

 Thanks in advance,

 Levi

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Custom Actions / SQL

2014-01-24 Thread John Cooper

Well, I'll see if I can throw something together.  I can't expose the code, but 
I can describe the component custom actions and the table in enough detail to 
make it easy enough to re-implement.

The one big gotcha is early releases of the SSDT had versions of SqlPackage.exe 
that lacked a provision to extend the timeout.  This doesn't matter much on a 
remote deploy if you're only deploying one database, but if you're deploying 
several, you'll need to extend the timeout by setting a registry entry.  We 
generally set it a 5 minutes (300 seconds) which may be overkill, but works for 
us.  I recommend only use the October 2013 (or later) SSDT package.

My technique deploys up to seven databases in this manner.  I'm using it in 
production on eight products currently (and converting an additional product 
over to it that currently uses SqlScript/SqlString).

I'll try to have something up on my blog by Monday.

--
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: Levi Wilson [mailto:l...@leviwilson.com] 
Sent: Friday, January 24, 2014 8:21 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks for the responses guys, that helps a lot.

John: do you have any blog posts or anything that speaks to how you're 
deploying databases and such with WiX with SqlPackage.exe? My other post talks 
about some of the pain I'm having with a very large SQL script (144k
lines) and wondering if SqlPackage.exe would alleviate some of that.

Thanks,

Levi


On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

 If they are not in DTF then the WiX toolset doesn't provide them. It's 
 assumed that most of what drove you to managed code would already be 
 in the Framework so there isn't the same level of need to invent the wheel.


 Having said that, I like John's reply. Cool system. I'll have to 
 remember that next time I'm faced with installers populating databases.






 Blair





 From: Levi Wilson
 Sent: Thursday, January 23, 2014 6:37 AM
 To: General discussion for Windows Installer XML toolset.





 Being out of the WiX installer world for a handful of years, I was 
 used to writing all of my custom actions in C++. Getting back into 
 this I noticed that it is now acceptable to write them in C# and the DTF.

 That being said, I have a custom action that is currently written in 
 C++ that checks for the existence of a database as well as to verify 
 if a particular table exists. For that, I am using the sqlutil.lib to 
 make that easier. In C# custom actions, is there an equivalent or do 
 most people just use SqlConnection / SqlCommand out of the .NET framework?

 Apologies if this is an obvious question, I just didn't want to 
 re-invent the wheel if WiX had a helper library to assist with this. I 
 didn't see any SQL related classes in DTF.

 Thanks in advance,

 Levi

 --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

 --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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,

Re: [WiX-users] C# Custom Actions / SQL

Thanks! I was planning on only using it to do my initial schema setup, and
have SqlScript do everything else. My current RedGate schema export is 144k
and it takes 6 minutes for the C++ CA to parse it :( Just trying to figure
out my options.


On Fri, Jan 24, 2014 at 9:33 AM, John Cooper jocoo...@jackhenry.com wrote:

 Well, I'll see if I can throw something together.  I can't expose the
 code, but I can describe the component custom actions and the table in
 enough detail to make it easy enough to re-implement.

 The one big gotcha is early releases of the SSDT had versions of
 SqlPackage.exe that lacked a provision to extend the timeout.  This doesn't
 matter much on a remote deploy if you're only deploying one database, but
 if you're deploying several, you'll need to extend the timeout by setting a
 registry entry.  We generally set it a 5 minutes (300 seconds) which may be
 overkill, but works for us.  I recommend only use the October 2013 (or
 later) SSDT package.

 My technique deploys up to seven databases in this manner.  I'm using it
 in production on eight products currently (and converting an additional
 product over to it that currently uses SqlScript/SqlString).

 I'll try to have something up on my blog by Monday.

 --
 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: Levi Wilson [mailto:l...@leviwilson.com]
 Sent: Friday, January 24, 2014 8:21 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] C# Custom Actions / SQL

 Thanks for the responses guys, that helps a lot.

 John: do you have any blog posts or anything that speaks to how you're
 deploying databases and such with WiX with SqlPackage.exe? My other post
 talks about some of the pain I'm having with a very large SQL script (144k
 lines) and wondering if SqlPackage.exe would alleviate some of that.

 Thanks,

 Levi


 On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

  If they are not in DTF then the WiX toolset doesn't provide them. It's
  assumed that most of what drove you to managed code would already be
  in the Framework so there isn't the same level of need to invent the
 wheel.
 
 
  Having said that, I like John's reply. Cool system. I'll have to
  remember that next time I'm faced with installers populating databases.
 
 
 
 
 
 
  Blair
 
 
 
 
 
  From: Levi Wilson
  Sent: Thursday, January 23, 2014 6:37 AM
  To: General discussion for Windows Installer XML toolset.
 
 
 
 
 
  Being out of the WiX installer world for a handful of years, I was
  used to writing all of my custom actions in C++. Getting back into
  this I noticed that it is now acceptable to write them in C# and the DTF.
 
  That being said, I have a custom action that is currently written in
  C++ that checks for the existence of a database as well as to verify
  if a particular table exists. For that, I am using the sqlutil.lib to
  make that easier. In C# custom actions, is there an equivalent or do
  most people just use SqlConnection / SqlCommand out of the .NET
 framework?
 
  Apologies if this is an obvious question, I just didn't want to
  re-invent the wheel if WiX had a helper library to assist with this. I
  didn't see any SQL related classes in DTF.
 
  Thanks in advance,
 
  Levi
 
  --
   CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
  Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
  http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.
  clktrk ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
  --
   CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
  Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
  http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.
  clktrk ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk

Re: [WiX-users] C# Custom Actions / SQL

2014-01-24 Thread John Cooper

There are disadvantages to using this mixed approach.  Chief among them is that 
you inherit SqlScript/SqlString's limitations on default instances if SQL 
browsing is disabled.  I've tested and SqlPackage does not have this 
limitation.  That being said, we do have a mix (particularly to implement ALTER 
RECOVERY SIMPLE), but we're always moving to merge them back into the main 
package.

Whenever possible, I recommend doing both the schema and data deploy with one 
method.  If you're going to use SqlPackage to deploy the schema, it's not that 
much harder to have it deploy the default data too.  In fact, the schema code 
runs for us only if:  1) the database doesn't exist; or 2) the schema has 
changed and can be safely updated.  The default data runs only if the data is 
missing or the scripts decide it is corrupt.  We also hae a bunch of scripts 
run during the package deploy to set roles, logins,  and grant permissions.

In fact, a lot of these scripts are common to are databases and are shared 
among.

--
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: Levi Wilson [mailto:l...@leviwilson.com] 
Sent: Friday, January 24, 2014 8:40 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks! I was planning on only using it to do my initial schema setup, and have 
SqlScript do everything else. My current RedGate schema export is 144k and it 
takes 6 minutes for the C++ CA to parse it :( Just trying to figure out my 
options.


On Fri, Jan 24, 2014 at 9:33 AM, John Cooper jocoo...@jackhenry.com wrote:

 Well, I'll see if I can throw something together.  I can't expose the 
 code, but I can describe the component custom actions and the table in 
 enough detail to make it easy enough to re-implement.

 The one big gotcha is early releases of the SSDT had versions of 
 SqlPackage.exe that lacked a provision to extend the timeout.  This 
 doesn't matter much on a remote deploy if you're only deploying one 
 database, but if you're deploying several, you'll need to extend the 
 timeout by setting a registry entry.  We generally set it a 5 minutes 
 (300 seconds) which may be overkill, but works for us.  I recommend 
 only use the October 2013 (or
 later) SSDT package.

 My technique deploys up to seven databases in this manner.  I'm using 
 it in production on eight products currently (and converting an 
 additional product over to it that currently uses SqlScript/SqlString).

 I'll try to have something up on my blog by Monday.

 --
 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: Levi Wilson [mailto:l...@leviwilson.com]
 Sent: Friday, January 24, 2014 8:21 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] C# Custom Actions / SQL

 Thanks for the responses guys, that helps a lot.

 John: do you have any blog posts or anything that speaks to how you're 
 deploying databases and such with WiX with SqlPackage.exe? My other 
 post talks about some of the pain I'm having with a very large SQL 
 script (144k
 lines) and wondering if SqlPackage.exe would alleviate some of that.

 Thanks,

 Levi


 On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

  If they are not in DTF then the WiX toolset doesn't provide them. 
  It's assumed that most of what drove you to managed code would 
  already be in the Framework so there isn't the same level of need to 
  invent the
 wheel.
 
 
  Having said that, I like John's reply. Cool system. I'll have to 
  remember that next time I'm faced with installers populating databases.
 
 
 
 
 
 
  Blair
 
 
 
 
 
  From: Levi Wilson
  Sent: Thursday, January 23, 2014 6:37 AM
  To: General discussion for Windows Installer XML toolset.
 
 
 
 
 
  Being out of the WiX installer world for a handful of years, I was 
  used to writing all of my custom actions in C++. Getting back into 
  this I noticed that it is now acceptable to write them in C# and the DTF.
 
  That being said, I have a custom action that is currently written in
  C++ that checks for the existence of a database as well as to verify
  if a particular table exists. For that, I am using the sqlutil.lib 
  to make that easier. In C# custom actions, is there an equivalent or 
  do most people just use SqlConnection / SqlCommand out of the .NET
 framework?
 
  Apologies if this is an obvious question, I just didn't want to 
  re-invent the wheel if WiX had a helper library to assist with this. 
  I didn't see any SQL related classes in DTF.
 
  Thanks in advance,
 
  Levi
 
  
  --
   CenturyLink Cloud: The Leader in

[WiX-users] caSuffix.wxi and PrinEULA?

2014-01-24 Thread Martin Clarke

Hi all,

I'm using Wix 3.8 and I'm trying to customise the WixUI_Advanced.wxs wizard
for my project. Unforunately, Common_Platform.wxi is making reference to a
file called caSuffix.wxi - which seems to be missing?

Apologies if I'm missing something terribly obvious, I've done similar
customisations for previous versions of WiX and it's been fine. Could
anyone point me in the direction of the file, or the substitute value for
(var.suffix) which I assume caSuffix.wxi contains?

Kind regards,
Martin
PS I also looked at building the uica.vcxproj (to see if it output
caSuffix.wxi) and it complains about c:\tools\WixBuild.props being missing.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Setup.exe cygwin question

2014-01-24 Thread BGINFO4X

Dear Sirs.

Attending your experience, do you think that is possible to build an
installer like the traditional setup.exe installer from cygwin.com?

In the following url you can see the main screens.
http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html

I ask basically for the screens number 11, 13, 15, 16.  Do you think
that this is possible with WIX?

Does anyone would like to be the project leader of  such project?
cygwin community should agree with this.

I must admit that I can't build such project, I don't have the
necessary experience and knowledge.

Any recommendation is welcome.

Thanks for your time and regards.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Custom Actions / SQL

I'm fine with using that to do both the schema and initial data deploy with
the one method. What I'm unclear/fuzzy are the incremental
changes/migrations that we do from release to release. Originally, this was
my plan:

http://nicholas.piasecki.name/blog/2009/09/running-update-sql-scripts-during-minor-upgrades-with-wix/

I still like the idea of that as it seems easier for me to grok.

Thank you so much for your thoughts; you clearly have done this before ;-)

On Fri, Jan 24, 2014 at 9:57 AM, John Cooper jocoo...@jackhenry.com wrote:

There are disadvantages to using this mixed approach. Chief among them is
that you inherit SqlScript/SqlString's limitations on default instances if
SQL browsing is disabled. I've tested and SqlPackage does not have this
limitation. That being said, we do have a mix (particularly to implement
ALTER RECOVERY SIMPLE), but we're always moving to merge them back into the
main package.

Whenever possible, I recommend doing both the schema and data deploy with
one method. If you're going to use SqlPackage to deploy the schema, it's
not that much harder to have it deploy the default data too. In fact, the
schema code runs for us only if: 1) the database doesn't exist; or 2) the
schema has changed and can be safely updated. The default data runs only
if the data is missing or the scripts decide it is corrupt. We also hae a
bunch of scripts run during the package deploy to set roles, logins, and
grant permissions.

In fact, a lot of these scripts are common to are databases and are shared
among.

--
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: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Friday, January 24, 2014 8:40 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks! I was planning on only using it to do my initial schema setup, and
have SqlScript do everything else. My current RedGate schema export is 144k
and it takes 6 minutes for the C++ CA to parse it :( Just trying to figure
out my options.

On Fri, Jan 24, 2014 at 9:33 AM, John Cooper jocoo...@jackhenry.com
wrote:

Well, I'll see if I can throw something together. I can't expose the
code, but I can describe the component custom actions and the table in
enough detail to make it easy enough to re-implement.

The one big gotcha is early releases of the SSDT had versions of
SqlPackage.exe that lacked a provision to extend the timeout. This
doesn't matter much on a remote deploy if you're only deploying one
database, but if you're deploying several, you'll need to extend the
timeout by setting a registry entry. We generally set it a 5 minutes
(300 seconds) which may be overkill, but works for us. I recommend
only use the October 2013 (or
later) SSDT package.

My technique deploys up to seven databases in this manner. I'm using
it in production on eight products currently (and converting an
additional product over to it that currently uses SqlScript/SqlString).

I'll try to have something up on my blog by Monday.

--
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: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Friday, January 24, 2014 8:21 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks for the responses guys, that helps a lot.

John: do you have any blog posts or anything that speaks to how you're
deploying databases and such with WiX with SqlPackage.exe? My other
post talks about some of the pain I'm having with a very large SQL
script (144k
lines) and wondering if SqlPackage.exe would alleviate some of that.

Thanks,

Levi

On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

If they are not in DTF then the WiX toolset doesn't provide them.
It's assumed that most of what drove you to managed code would
already be in the Framework so there isn't the same level of need to
invent the
wheel.

Having said that, I like John's reply. Cool system. I'll have to
remember that next time I'm faced with installers populating databases.

Blair

From: Levi Wilson
Sent: Thursday, January 23, 2014 6:37 AM
To: General discussion for Windows Installer XML toolset.

Being out of the WiX installer world for a handful of years, I was
used to writing all of my custom actions in C++. Getting back into
this I noticed that it is now acceptable to write them in C# and the
DTF.

That being said, I have a custom action that is currently written in
C++

Re: [WiX-users] C# Custom Actions / SQL

Sorry, one caveat to that post is that we will NOT be creating the actual
database. It will be empty, and the client sets up the permissions
beforehand.

On Fri, Jan 24, 2014 at 10:42 AM, Levi Wilson l...@leviwilson.com wrote:

I'm fine with using that to do both the schema and initial data deploy
with the one method. What I'm unclear/fuzzy are the incremental
changes/migrations that we do from release to release. Originally, this was
my plan:

http://nicholas.piasecki.name/blog/2009/09/running-update-sql-scripts-during-minor-upgrades-with-wix/

I still like the idea of that as it seems easier for me to grok.

Thank you so much for your thoughts; you clearly have done this before ;-)

On Fri, Jan 24, 2014 at 9:57 AM, John Cooper jocoo...@jackhenry.comwrote:

There are disadvantages to using this mixed approach. Chief among them
is that you inherit SqlScript/SqlString's limitations on default instances
if SQL browsing is disabled. I've tested and SqlPackage does not have this
limitation. That being said, we do have a mix (particularly to implement
ALTER RECOVERY SIMPLE), but we're always moving to merge them back into the
main package.

In fact, a lot of these scripts are common to are databases and are
shared among.

--
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: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Friday, January 24, 2014 8:40 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks! I was planning on only using it to do my initial schema setup,
and have SqlScript do everything else. My current RedGate schema export is
144k and it takes 6 minutes for the C++ CA to parse it :( Just trying to
figure out my options.

On Fri, Jan 24, 2014 at 9:33 AM, John Cooper jocoo...@jackhenry.com
wrote:

Well, I'll see if I can throw something together. I can't expose the
code, but I can describe the component custom actions and the table in
enough detail to make it easy enough to re-implement.

I'll try to have something up on my blog by Monday.

--
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: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Friday, January 24, 2014 8:21 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] C# Custom Actions / SQL

Thanks for the responses guys, that helps a lot.

Thanks,

Levi

On Fri, Jan 24, 2014 at 12:53 AM, Blair Murri os...@live.com wrote:

Having said that, I like John's reply. Cool system. I'll have to
remember that next time I'm faced with installers populating
databases.

Blair

From: Levi Wilson
Sent: Thursday, January 23, 2014 6:37 AM
To: General discussion for Windows Installer XML toolset.

Being out of the WiX installer world for a handful of years,

[WiX-users] searching for a registry key without worrying about any values

2014-01-24 Thread Sean Farrow

Hi all,

I'm in the process of refactoring an installer I wrote a while ago.
I've got a situation where I need to check that a registry key exists (I'm not 
worried about any of the values). What is the best way of doing this and 
assigning it to a property? I thought about setting the property to an initial 
value say test, and as the default value is an empty string I could check to 
see whether the string is empty and hence the property has been set. Or, Will 
the Util extension help here? How can I set a variable value to a property?
I'm currently using a custom action to do this using RegOpenKey internally.
Any help appreciated.
Cheers
Sean.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a connection to the Internet to create an installation file?

To use any of the WiX extensions you need to do two things.
1) Add the schema statement as you originally had.

Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
xmlns:bal=http://schemas.microsoft.com/wix/WixBalExtension;

The above three UtilExtension, NetFxExtension, and WixBalExtension are all
correct and necessary, but not enough. If you then add any code to your
project related to these three extensions like:
BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost ...
You will get the errors which you observed.

2) You also need to 'Add a Reference' to your Project file.
For me on VS2010 (and I think it is similar on 2012) look at you Solution
tree. There is a virtual folder named Reference. Right-Click and select
Add. You will get a dialog that has tabs Project, Browse, and Recent (at
least on 2VS2010). In Browse point at you Wix installation folder,
typically C:\Program Files (x86)\WiX Toolset v3.8\bin and select the DLL
which is named and related to the Wix extension that you are trying to use,
in this case WixBalExtension.dll. If you are also trying to use the
UtilExtension or the NetFxExtension, you need to repeat this process for
each DLL. (If you ever move the Wix Toolset to a different path, like E:\
then you will need to go to each project and fix these references.)

If you still have problems you can enable more verbose build logs in VS
Tools\Options\Projects and Solutions\Build and Run.

Actual relevant sections of code (and if necessary a detailed build log)
will clarify what the problem is.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Visual-Studio-2012-Does-the-Wix-installer-need-a-connection-to-the-Internet-to-create-an-installatio-tp7591955p7592043.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a connection to the Internet to create an installation file?

I'm sorry I misread part of your post.  I do not know about the schema issues
if you are on a closed network, how that should be handled.  Maybe someone
else can comment on that.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Visual-Studio-2012-Does-the-Wix-installer-need-a-connection-to-the-Internet-to-create-an-installatio-tp7591955p7592044.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] caSuffix.wxi and PrinEULA?

Is this what you are looking for?
#if defined _WIN64
#define PLATFORM_DECORATION(f) f ## L_64
#elif defined ARM
#define PLATFORM_DECORATION(f) f ## L_ARM
#else
#define PLATFORM_DECORATION(f) f
#endif

from src\ext\ca\inc\caSuffix.h



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/caSuffix-wxi-and-PrinEULA-tp7592038p7592045.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a connection to the Internet to create an installation file?

2014-01-24 Thread Jeremiah

No

Jeremiah 
 Hogland phogl...@rimage.com wrote:

 I'm sorry I misread part of your post.  I do not know about the schema issues
 if you are on a closed network, how that should be handled.  Maybe someone
 else can comment on that.
 
 
 
 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Visual-Studio-2012-Does-the-Wix-installer-need-a-connection-to-the-Internet-to-create-an-installatio-tp7591955p7592044.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today. 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Enabling platform features during install

I do not have the ADK or the path either.  And the API docs talk about
creating a 'application' which will modify /online images.  Here is a
sample:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh824804.aspx

I am preparing a CA to test pieces of this code relating to the query of a
feature status, as a test of the concept.  I am not quite ready to try and
compile it without or with the ADK, but I hope to have a better idea later
today after I work on some other issues. 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Enabling-platform-features-during-install-tp7591862p7592047.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

2014-01-24 Thread Sascha

I just ran into this exact same issue and have been trying to find a suitable
solution. I need to install the .NET Framework and also a newer C++ runtime
as per-machine prerequisites but my software on a per-user basis.

Would using the managed bootstrapper help get around this issue by any
chance? My understanding is that using the managed bootstrapper means there
are actually two bootstrappers, one that takes care of installing .NET
Framework if needed, and then the managed one that gets launched after.

If the inner managed bootstrapper is capable of doing a regular per-user
install after the outer native bootstrapper installs the .NET Framework,
that would solve most of this issue. I say most because I also need to
install the C++ runtime, but for now I could resort to deploy the C++ DLLs
locally with my app instead of using the merge module.

I'm looking at some of the managed bootstrapper tutorials and blob posts
right now and will slap something together to try out this theory, but if
anybody already knows the answer that would be even better. I'll post
another reply with my findings once I'm done.

The only other alternative I see is using some other means like a simple
batch file to execute multiple bundles in series, that way I would have one
bundle with .NET and C++ runtime in it which would run per-machine or just
the MSIs for those without a bundle, and then another bundle with my
per-user software MSI. Not ideal especially for issues and error conditions,
but better than asking my end-user to run a couple of MSIs manually.

// Sascha

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-purpose-installer-ALLUSERS-2-and-Bootstrapper-tp7591740p7592050.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

If you package is per-user then Burn handles that correctly. It will elevate 
only if necessary (i.e installing per-machine prerequisites) and install your 
per-user package.  Burn is *designed* to handle that correctly.

-Original Message-
From: Sascha [mailto:sascha.ser...@gmail.com] 
Sent: Friday, January 24, 2014 10:51 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

I just ran into this exact same issue and have been trying to find a suitable 
solution. I need to install the .NET Framework and also a newer C++ runtime as 
per-machine prerequisites but my software on a per-user basis.

Would using the managed bootstrapper help get around this issue by any chance? 
My understanding is that using the managed bootstrapper means there are 
actually two bootstrappers, one that takes care of installing .NET Framework if 
needed, and then the managed one that gets launched after.

If the inner managed bootstrapper is capable of doing a regular per-user 
install after the outer native bootstrapper installs the .NET Framework, that 
would solve most of this issue. I say most because I also need to install the 
C++ runtime, but for now I could resort to deploy the C++ DLLs locally with my 
app instead of using the merge module.

I'm looking at some of the managed bootstrapper tutorials and blob posts right 
now and will slap something together to try out this theory, but if anybody 
already knows the answer that would be even better. I'll post another reply 
with my findings once I'm done.

The only other alternative I see is using some other means like a simple batch 
file to execute multiple bundles in series, that way I would have one bundle 
with .NET and C++ runtime in it which would run per-machine or just the MSIs 
for those without a bundle, and then another bundle with my per-user software 
MSI. Not ideal especially for issues and error conditions, but better than 
asking my end-user to run a couple of MSIs manually.

// Sascha

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-purpose-installer-ALLUSERS-2-and-Bootstrapper-tp7591740p7592050.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] 0x80096005: timestamp signature and/or certificate could not be verified

2014-01-24 Thread roberthyang

Hi all -- we've got an installer built with Wix 3.6 stable (3.6.3303.0) and
burn (using the standard BA).  On one particular machine it is failing with
the following error displayed to the user :

0x80096005: The timestamp signature and/or certificate could not be
verified or is malformed

Here is an excerpt from the BA log :

[22AC:1A3C][2014-01-22T16:07:50]: Plan complete, result: 0x0
[22AC:1A3C][2014-01-22T16:07:50]: Apply begin
[1EF8:1CA4][2014-01-22T16:07:50]: Creating a system restore point.
[1EF8:1CA4][2014-01-22T16:08:13]: Created a system restore point.
[1EF8:1CA4][2014-01-22T16:08:13]: Caching bundle from:
'C:\Users\benjowen\AppData\Local\Temp\{9043c2b5-f090-4923-af17-9cf709bf495b}\.be\ProfinderSetup.exe'
to: 'C:\ProgramData\Package
Cache\{9043c2b5-f090-4923-af17-9cf709bf495b}\ProfinderSetup.exe'
[1EF8:1CA4][2014-01-22T16:08:13]: Registering bundle dependency provider:
{9043c2b5-f090-4923-af17-9cf709bf495b}, version: 6.0.606.0
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed authenticode
verification of payload: C:\ProgramData\Package
Cache\.unverified\ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to verify
signature of payload: ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Failed to verify payload: ProfinderMSI at
path: C:\ProgramData\Package Cache\.unverified\ProfinderMSI, error:
0x80096005. Deleting file.
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to cache payload:
ProfinderMSI
[22AC:1CDC][2014-01-22T16:08:14]: Failed to cache payload: ProfinderMSI from
working path:
C:\Users\benjowen\AppData\Local\Temp\{9043c2b5-f090-4923-af17-9cf709bf495b}\ProfinderMSI,
error: 0x80096005.
[22AC:1CDC][2014-01-22T16:08:14]: Application requested retry of payload:
ProfinderMSI, encountered error: 0x80096005. Retrying...
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed authenticode
verification of payload: C:\ProgramData\Package
Cache\.unverified\ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to verify
signature of payload: ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Failed to verify payload: ProfinderMSI at
path: C:\ProgramData\Package Cache\.unverified\ProfinderMSI, error:
0x80096005. Deleting file.
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to cache payload:
ProfinderMSI
[22AC:1CDC][2014-01-22T16:08:14]: Failed to cache payload: ProfinderMSI from
working path:
C:\Users\benjowen\AppData\Local\Temp\{9043c2b5-f090-4923-af17-9cf709bf495b}\ProfinderMSI,
error: 0x80096005.
[22AC:1CDC][2014-01-22T16:08:14]: Application requested retry of payload:
ProfinderMSI, encountered error: 0x80096005. Retrying...
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed authenticode
verification of payload: C:\ProgramData\Package
Cache\.unverified\ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to verify
signature of payload: ProfinderMSI
[1EF8:1C38][2014-01-22T16:08:14]: Failed to verify payload: ProfinderMSI at
path: C:\ProgramData\Package Cache\.unverified\ProfinderMSI, error:
0x80096005. Deleting file.
[1EF8:1C38][2014-01-22T16:08:14]: Error 0x80096005: Failed to cache payload:
ProfinderMSI
[22AC:1CDC][2014-01-22T16:08:14]: Failed to cache payload: ProfinderMSI from
working path:
C:\Users\benjowen\AppData\Local\Temp\{9043c2b5-f090-4923-af17-9cf709bf495b}\ProfinderMSI,
error: 0x80096005.
[22AC:1A3C][2014-01-22T16:08:14]: Error 0x80096005: Failed while caching,
aborting execution.
[1EF8:1CA4][2014-01-22T16:08:14]: Removed bundle dependency provider:
{9043c2b5-f090-4923-af17-9cf709bf495b}
[1EF8:1CA4][2014-01-22T16:08:14]: Removing cached bundle:
{9043c2b5-f090-4923-af17-9cf709bf495b}, from path: C:\ProgramData\Package
Cache\{9043c2b5-f090-4923-af17-9cf709bf495b}\
[22AC:1A3C][2014-01-22T16:08:14]: Apply complete, result: 0x80096005,
restart: None, ba requested restart:  No

The OS is Windows 7.  The same signing credentials are used as for another
product which seems to install fine as an MSI and was built with Wix 3.5,
and the machine has internet connectivity so I don't think it's a problem
with being able to access the timestamp server.

I also instructed the user to download the Microsoft CRL and then to try
disabling the CRL check (Internet Explorer - Tools - Internet Options -
Advanced - Security - Check for publisher’s certificate revocation), based
on some advice I found on the all-knowing google :)  This apparently didn't
help either.

Were there any known issues in Wix 3.6 that might cause this  ?  Any other
hints ?

Thanks for any assistance !
-Rob




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/0x80096005-timestamp-signature-and-or-certificate-could-not-be-verified-tp7592055.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud

Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a connection to the Internet to create an installation file?

The WixExtension 'references' should be added to the Wix based 'Projects'
which are using the particular extension.  So your Bundle 'project' should
have a 'reference' collection and you will almost certianly need to add a
reference to the WixBalExtension.

If you are using code for the WixFirewallExtension in your MSI project, then
you need to add a 'reference ' to that project, but not to the
Bundle/Bootsrapper project if it is not used there.

If your 'program to compile' is some application that you want to install,
but is not actually a Wix setup project then I do not know of any reason to
add a WixExtension to that project.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Visual-Studio-2012-Does-the-Wix-installer-need-a-connection-to-the-Internet-to-create-an-installatio-tp7591955p7592056.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Let me clarify a bit to tell you what I'm trying to do, what I've tried,
and what I thought isn't currently working:

Goal: Build a WiX installer for my software which installs .NET Framework
4.5.1 if needed, C++ Runtime if needed, and my software. My software needs
to be installed per-user, i.e. it should go into AppData\Local, not Program
Files.

My understanding is
- To accomplish my goal I need three components: .NET Framework 4.5.1
package (provided by NetFx extension), C++ Runtime merge module, and MSI
for my software
- The two prerequisites needs to be installed on a per-machine (elevated)
level, my software on a per-user level

This is what I've tried:
Attempt 1. Created a WiX bundle with two packages inside the Chain element:
A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my
software as well as the C++ merge module.
Problem: This wouldn't build because my software Package had InstallScope
perUser but apparently the C++ merge module forced ALLUSERS=1 which
conflicted with the perUser setting. This problem went away when I took the
merge module out of the package.

Attempt 2: Created a WiX bundle with three packages inside the Chain
element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++
Runtime merge module (InstallScope perMachine), and an MsiPackage for my
software (InstallScope perUser).
Problem: When running the resulting bundle it would prompt for elevation
(which is fine), then install .NET Framework fine, then install the merge
module fine, but throw an error for my perUser package: The installer has
insufficient privileges to access this directory: C:\Program
Files\product. The installation cannot continue. Log on as administrator
or contact your system administrator.

My software package uses a folder underneath ProgramFilesFolder as the
target folder and I was expecting that on Win7 and up in a per-user install
it automatically translates to LocalAppDataFolder instead.

I thought from what I had gathered in this thread is that once the bundle
gets elevated permissions it will also try to run my software package in
forced per machine mode but without elevation, and therefore fails when
trying to access the Program Files directory.

Your last remark sounds though as if this should work. Please help me
understand what I'm doing wrong.

// Sascha



On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.comwrote:

 If you package is per-user then Burn handles that correctly. It will
 elevate only if necessary (i.e installing per-machine prerequisites) and
 install your per-user package.  Burn is *designed* to handle that correctly.

 -Original Message-
 From: Sascha [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 10:51 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 I just ran into this exact same issue and have been trying to find a
 suitable solution. I need to install the .NET Framework and also a newer
 C++ runtime as per-machine prerequisites but my software on a per-user
 basis.

 Would using the managed bootstrapper help get around this issue by any
 chance? My understanding is that using the managed bootstrapper means there
 are actually two bootstrappers, one that takes care of installing .NET
 Framework if needed, and then the managed one that gets launched after.

 If the inner managed bootstrapper is capable of doing a regular per-user
 install after the outer native bootstrapper installs the .NET Framework,
 that would solve most of this issue. I say most because I also need to
 install the C++ runtime, but for now I could resort to deploy the C++ DLLs
 locally with my app instead of using the merge module.

 I'm looking at some of the managed bootstrapper tutorials and blob posts
 right now and will slap something together to try out this theory, but if
 anybody already knows the answer that would be even better. I'll post
 another reply with my findings once I'm done.

 The only other alternative I see is using some other means like a simple
 batch file to execute multiple bundles in series, that way I would have one
 bundle with .NET and C++ runtime in it which would run per-machine or just
 the MSIs for those without a bundle, and then another bundle with my
 per-user software MSI. Not ideal especially for issues and error
 conditions, but better than asking my end-user to run a couple of MSIs
 manually.

 // Sascha



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-purpose-installer-ALLUSERS-2-and-Bootstrapper-tp7591740p7592050.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
 Workloads, Development Environments  Everything In Between.
 Get a Quote or

Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a connection to the Internet to create an installation file?

2014-01-24 Thread Sean

I build WiX projects on computers without access to the internet (and never
were connected) all the time. I use the http://schemas.microsoft.com/wix
namespaces. You only talk about 2 projects: your application, and the MSI
project. You probably need a third project: the Bundle project. Maybe you
should post the file that has the Bundle element, and the project file that is
compiling that.

Date: Fri, 24 Jan 2014 12:08:22 -0800
From: phogl...@rimage.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Visual Studio 2012: Does the Wix installer need a
connection to the Internet to create an installation file?

The WixExtension 'references' should be added to the Wix based 'Projects'
which are using the particular extension. So your Bundle 'project' should
have a 'reference' collection and you will almost certianly need to add a
reference to the WixBalExtension.

If you are using code for the WixFirewallExtension in your MSI project, then
you need to add a 'reference ' to that project, but not to the
Bundle/Bootsrapper project if it is not used there.

If your 'program to compile' is some application that you want to install,
but is not actually a Wix setup project then I do not know of any reason to
add a WixExtension to that project.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Visual-Studio-2012-Does-the-Wix-installer-need-a-connection-to-the-Internet-to-create-an-installatio-tp7591955p7592056.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

2014-01-24 Thread Wesley Manning

Peruser can't install to C:\Program Files\.  That's a per machine location.

-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com] 
Sent: January-24-14 4:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Let me clarify a bit to tell you what I'm trying to do, what I've tried, and 
what I thought isn't currently working:

Goal: Build a WiX installer for my software which installs .NET Framework
4.5.1 if needed, C++ Runtime if needed, and my software. My software needs to 
be installed per-user, i.e. it should go into AppData\Local, not Program Files.

My understanding is
- To accomplish my goal I need three components: .NET Framework 4.5.1 package 
(provided by NetFx extension), C++ Runtime merge module, and MSI for my software
- The two prerequisites needs to be installed on a per-machine (elevated) 
level, my software on a per-user level

This is what I've tried:
Attempt 1. Created a WiX bundle with two packages inside the Chain element:
A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my software 
as well as the C++ merge module.
Problem: This wouldn't build because my software Package had InstallScope 
perUser but apparently the C++ merge module forced ALLUSERS=1 which 
conflicted with the perUser setting. This problem went away when I took the 
merge module out of the package.

Attempt 2: Created a WiX bundle with three packages inside the Chain
element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++ Runtime 
merge module (InstallScope perMachine), and an MsiPackage for my software 
(InstallScope perUser).
Problem: When running the resulting bundle it would prompt for elevation (which 
is fine), then install .NET Framework fine, then install the merge module fine, 
but throw an error for my perUser package: The installer has insufficient 
privileges to access this directory: C:\Program Files\product. The 
installation cannot continue. Log on as administrator or contact your system 
administrator.

My software package uses a folder underneath ProgramFilesFolder as the target 
folder and I was expecting that on Win7 and up in a per-user install it 
automatically translates to LocalAppDataFolder instead.

I thought from what I had gathered in this thread is that once the bundle gets 
elevated permissions it will also try to run my software package in forced per 
machine mode but without elevation, and therefore fails when trying to access 
the Program Files directory.

Your last remark sounds though as if this should work. Please help me 
understand what I'm doing wrong.

// Sascha

On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.comwrote:

 If you package is per-user then Burn handles that correctly. It will 
 elevate only if necessary (i.e installing per-machine prerequisites) 
 and install your per-user package.  Burn is *designed* to handle that 
 correctly.

 -Original Message-
 From: Sascha [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 10:51 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
 Bootstrapper

 I just ran into this exact same issue and have been trying to find a 
 suitable solution. I need to install the .NET Framework and also a 
 newer
 C++ runtime as per-machine prerequisites but my software on a per-user
 basis.

 Would using the managed bootstrapper help get around this issue by any 
 chance? My understanding is that using the managed bootstrapper means 
 there are actually two bootstrappers, one that takes care of 
 installing .NET Framework if needed, and then the managed one that gets 
 launched after.

 If the inner managed bootstrapper is capable of doing a regular 
 per-user install after the outer native bootstrapper installs the 
 .NET Framework, that would solve most of this issue. I say most 
 because I also need to install the C++ runtime, but for now I could 
 resort to deploy the C++ DLLs locally with my app instead of using the merge 
 module.

 I'm looking at some of the managed bootstrapper tutorials and blob 
 posts right now and will slap something together to try out this 
 theory, but if anybody already knows the answer that would be even 
 better. I'll post another reply with my findings once I'm done.

 The only other alternative I see is using some other means like a 
 simple batch file to execute multiple bundles in series, that way I 
 would have one bundle with .NET and C++ runtime in it which would run 
 per-machine or just the MSIs for those without a bundle, and then 
 another bundle with my per-user software MSI. Not ideal especially for 
 issues and error conditions, but better than asking my end-user to run 
 a couple of MSIs manually.

 // Sascha

 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-pur

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

2014-01-24 Thread Wesley Manning

 My software package uses a folder underneath ProgramFilesFolder as the target 
folder and I was expecting that on Win7 and up in a per-user install it 
automatically translates to LocalAppDataFolder instead.

I think Vista maybe but I think windows 7 doesn't do that.  Don't quote 
me.  I just vaguely remember reading something about that.  Maybe someone else 
can chime in.

Wes

-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com] 
Sent: January-24-14 4:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Let me clarify a bit to tell you what I'm trying to do, what I've tried, and 
what I thought isn't currently working:

Goal: Build a WiX installer for my software which installs .NET Framework
4.5.1 if needed, C++ Runtime if needed, and my software. My software needs to 
be installed per-user, i.e. it should go into AppData\Local, not Program Files.

My understanding is
- To accomplish my goal I need three components: .NET Framework 4.5.1 package 
(provided by NetFx extension), C++ Runtime merge module, and MSI for my software
- The two prerequisites needs to be installed on a per-machine (elevated) 
level, my software on a per-user level

This is what I've tried:
Attempt 1. Created a WiX bundle with two packages inside the Chain element:
A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my software 
as well as the C++ merge module.
Problem: This wouldn't build because my software Package had InstallScope 
perUser but apparently the C++ merge module forced ALLUSERS=1 which 
conflicted with the perUser setting. This problem went away when I took the 
merge module out of the package.

Attempt 2: Created a WiX bundle with three packages inside the Chain
element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++ Runtime 
merge module (InstallScope perMachine), and an MsiPackage for my software 
(InstallScope perUser).
Problem: When running the resulting bundle it would prompt for elevation (which 
is fine), then install .NET Framework fine, then install the merge module fine, 
but throw an error for my perUser package: The installer has insufficient 
privileges to access this directory: C:\Program Files\product. The 
installation cannot continue. Log on as administrator or contact your system 
administrator.

My software package uses a folder underneath ProgramFilesFolder as the target 
folder and I was expecting that on Win7 and up in a per-user install it 
automatically translates to LocalAppDataFolder instead.

I thought from what I had gathered in this thread is that once the bundle gets 
elevated permissions it will also try to run my software package in forced per 
machine mode but without elevation, and therefore fails when trying to access 
the Program Files directory.

Your last remark sounds though as if this should work. Please help me 
understand what I'm doing wrong.

// Sascha



On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.comwrote:

 If you package is per-user then Burn handles that correctly. It will 
 elevate only if necessary (i.e installing per-machine prerequisites) 
 and install your per-user package.  Burn is *designed* to handle that 
 correctly.

 -Original Message-
 From: Sascha [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 10:51 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
 Bootstrapper

 I just ran into this exact same issue and have been trying to find a 
 suitable solution. I need to install the .NET Framework and also a 
 newer
 C++ runtime as per-machine prerequisites but my software on a per-user
 basis.

 Would using the managed bootstrapper help get around this issue by any 
 chance? My understanding is that using the managed bootstrapper means 
 there are actually two bootstrappers, one that takes care of 
 installing .NET Framework if needed, and then the managed one that gets 
 launched after.

 If the inner managed bootstrapper is capable of doing a regular 
 per-user install after the outer native bootstrapper installs the 
 .NET Framework, that would solve most of this issue. I say most 
 because I also need to install the C++ runtime, but for now I could 
 resort to deploy the C++ DLLs locally with my app instead of using the merge 
 module.

 I'm looking at some of the managed bootstrapper tutorials and blob 
 posts right now and will slap something together to try out this 
 theory, but if anybody already knows the answer that would be even 
 better. I'll post another reply with my findings once I'm done.

 The only other alternative I see is using some other means like a 
 simple batch file to execute multiple bundles in series, that way I 
 would have one bundle with .NET and C++ runtime in it which would run 
 per-machine or just the MSIs for those without a bundle, and then 
 another bundle with my per-user

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

I think I figured it out! Typing up what I've done so far helped :-)

I had tried out so many things that I hadn't noticed I accidentally dropped
the MSIINSTALLPERUSER Property at some point. Putting back

Property Id=MSIINSTALLPERUSER Value=1 /

in my software package resolved the elevation issues in the bundle and .NET
Framework and C++ Runtime install fine as well as my user software package.
Yay!


On Fri, Jan 24, 2014 at 12:52 PM, Wesley Manning wmann...@dynagen.cawrote:

  My software package uses a folder underneath ProgramFilesFolder as the
 target folder and I was expecting that on Win7 and up in a per-user install
 it automatically translates to LocalAppDataFolder instead.

 I think Vista maybe but I think windows 7 doesn't do that.  Don't
 quote me.  I just vaguely remember reading something about that.  Maybe
 someone else can chime in.

 Wes

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: January-24-14 4:18 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 Let me clarify a bit to tell you what I'm trying to do, what I've tried,
 and what I thought isn't currently working:

 Goal: Build a WiX installer for my software which installs .NET Framework
 4.5.1 if needed, C++ Runtime if needed, and my software. My software needs
 to be installed per-user, i.e. it should go into AppData\Local, not Program
 Files.

 My understanding is
 - To accomplish my goal I need three components: .NET Framework 4.5.1
 package (provided by NetFx extension), C++ Runtime merge module, and MSI
 for my software
 - The two prerequisites needs to be installed on a per-machine (elevated)
 level, my software on a per-user level

 This is what I've tried:
 Attempt 1. Created a WiX bundle with two packages inside the Chain element:
 A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my
 software as well as the C++ merge module.
 Problem: This wouldn't build because my software Package had InstallScope
 perUser but apparently the C++ merge module forced ALLUSERS=1 which
 conflicted with the perUser setting. This problem went away when I took the
 merge module out of the package.

 Attempt 2: Created a WiX bundle with three packages inside the Chain
 element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++
 Runtime merge module (InstallScope perMachine), and an MsiPackage for my
 software (InstallScope perUser).
 Problem: When running the resulting bundle it would prompt for elevation
 (which is fine), then install .NET Framework fine, then install the merge
 module fine, but throw an error for my perUser package: The installer has
 insufficient privileges to access this directory: C:\Program
 Files\product. The installation cannot continue. Log on as administrator
 or contact your system administrator.

 My software package uses a folder underneath ProgramFilesFolder as the
 target folder and I was expecting that on Win7 and up in a per-user install
 it automatically translates to LocalAppDataFolder instead.

 I thought from what I had gathered in this thread is that once the bundle
 gets elevated permissions it will also try to run my software package in
 forced per machine mode but without elevation, and therefore fails when
 trying to access the Program Files directory.

 Your last remark sounds though as if this should work. Please help me
 understand what I'm doing wrong.

 // Sascha



 On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.com
 wrote:

  If you package is per-user then Burn handles that correctly. It will
  elevate only if necessary (i.e installing per-machine prerequisites)
  and install your per-user package.  Burn is *designed* to handle that
 correctly.
 
  -Original Message-
  From: Sascha [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 10:51 AM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
  Bootstrapper
 
  I just ran into this exact same issue and have been trying to find a
  suitable solution. I need to install the .NET Framework and also a
  newer
  C++ runtime as per-machine prerequisites but my software on a per-user
  basis.
 
  Would using the managed bootstrapper help get around this issue by any
  chance? My understanding is that using the managed bootstrapper means
  there are actually two bootstrappers, one that takes care of
  installing .NET Framework if needed, and then the managed one that gets
 launched after.
 
  If the inner managed bootstrapper is capable of doing a regular
  per-user install after the outer native bootstrapper installs the
  .NET Framework, that would solve most of this issue. I say most
  because I also need to install the C++ runtime, but for now I could
  resort to deploy the C++ DLLs locally with my app instead of using the
 merge module.
 
  I'm looking at some of the managed bootstrapper tutorials and

Re: [WiX-users] Windows Service Deployment - Installation Fails on Server 2003 but works elsewhere

2014-01-24 Thread Phil Wilson

...it's also worth reporting the actual error number in the range
1920-1923 that should have been shown somewhere - it's a bit more
specific about what went wrong.
Phil Wilson


On Thu, Jan 23, 2014 at 9:43 PM, Blair Murri os...@live.com wrote:
 Windows Installer a long time ago swallowed the actual error code and 
 determined that this error message was the most likely cause of any failure 
 to install/start a service. With time that’s been proven wrong, but as 
 Raymond Chen would tell you about maintaining backward compatibility…


 What you should always do when you see that message pop up is (with the box 
 still up) open an elevated command prompt and do a “net start servicename” 
 and see what error that returns. If it returns a time out check to see if its 
 possible that the service executable had popped up a dialog/message box 
 (possibly in the service desktop on vista/2008 and newer). One of those two 
 will usually tell you what went wrong.






 Blair





 From: Palmer, Joel
 Sent: Wednesday, January 22, 2014 7:14 PM
 To: General discussion for Windows Installer XML toolset.





 * I use WiX 3.8 to create an installer for my Windows Service.  When 
 it is run on my Server 2003 test box, I get this very unhelpful and generic 
 message:
 Verify that you have sufficient privileges to install system services.
 I am logged in to an Admin account when I run the installer.  According to 
 the installation log I am successful until it hits the main .exe of my 
 project.  I install using LocalSystem and this works when I install to my 
 dev box (Windows 7).  However, it fails when I attempt to install it onto my 
 Windows 2003 test server.  I already verified that the prerequisites 
 (Framework 4.0, etc) exist on the box.  Any troubleshooting tips you can give 
 me is appreciated.  Oy, my life for a good error message.
 I can forward the windows installer logging if that is helpful.

 Joel Palmer
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Burn does lots of work to make this scenario work (per-machine prerequisites 
and one or more per-user packages). It's unique among bootstrappers because it 
does it in all the right user contexts and all that. I saw a follow up email 
from you on a fork of this thread that found the most important thing: You need 
to make sure your per-user package is truly per-user.  The easiest way to do 
that is to use: Package/@InstallScope='perUser'.

-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com] 
Sent: Friday, January 24, 2014 12:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Let me clarify a bit to tell you what I'm trying to do, what I've tried, and 
what I thought isn't currently working:

Goal: Build a WiX installer for my software which installs .NET Framework
4.5.1 if needed, C++ Runtime if needed, and my software. My software needs to 
be installed per-user, i.e. it should go into AppData\Local, not Program Files.

My understanding is
- To accomplish my goal I need three components: .NET Framework 4.5.1 package 
(provided by NetFx extension), C++ Runtime merge module, and MSI for my software
- The two prerequisites needs to be installed on a per-machine (elevated) 
level, my software on a per-user level

This is what I've tried:
Attempt 1. Created a WiX bundle with two packages inside the Chain element:
A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my software 
as well as the C++ merge module.
Problem: This wouldn't build because my software Package had InstallScope 
perUser but apparently the C++ merge module forced ALLUSERS=1 which 
conflicted with the perUser setting. This problem went away when I took the 
merge module out of the package.

Attempt 2: Created a WiX bundle with three packages inside the Chain
element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++ Runtime 
merge module (InstallScope perMachine), and an MsiPackage for my software 
(InstallScope perUser).
Problem: When running the resulting bundle it would prompt for elevation (which 
is fine), then install .NET Framework fine, then install the merge module fine, 
but throw an error for my perUser package: The installer has insufficient 
privileges to access this directory: C:\Program Files\product. The 
installation cannot continue. Log on as administrator or contact your system 
administrator.

My software package uses a folder underneath ProgramFilesFolder as the target 
folder and I was expecting that on Win7 and up in a per-user install it 
automatically translates to LocalAppDataFolder instead.

I thought from what I had gathered in this thread is that once the bundle gets 
elevated permissions it will also try to run my software package in forced per 
machine mode but without elevation, and therefore fails when trying to access 
the Program Files directory.

Your last remark sounds though as if this should work. Please help me 
understand what I'm doing wrong.

// Sascha



On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.comwrote:

 If you package is per-user then Burn handles that correctly. It will 
 elevate only if necessary (i.e installing per-machine prerequisites) 
 and install your per-user package.  Burn is *designed* to handle that 
 correctly.

 -Original Message-
 From: Sascha [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 10:51 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
 Bootstrapper

 I just ran into this exact same issue and have been trying to find a 
 suitable solution. I need to install the .NET Framework and also a 
 newer
 C++ runtime as per-machine prerequisites but my software on a per-user
 basis.

 Would using the managed bootstrapper help get around this issue by any 
 chance? My understanding is that using the managed bootstrapper means 
 there are actually two bootstrappers, one that takes care of 
 installing .NET Framework if needed, and then the managed one that gets 
 launched after.

 If the inner managed bootstrapper is capable of doing a regular 
 per-user install after the outer native bootstrapper installs the 
 .NET Framework, that would solve most of this issue. I say most 
 because I also need to install the C++ runtime, but for now I could 
 resort to deploy the C++ DLLs locally with my app instead of using the merge 
 module.

 I'm looking at some of the managed bootstrapper tutorials and blob 
 posts right now and will slap something together to try out this 
 theory, but if anybody already knows the answer that would be even 
 better. I'll post another reply with my findings once I'm done.

 The only other alternative I see is using some other means like a 
 simple batch file to execute multiple bundles in series, that way I 
 would have one bundle with .NET and C++ runtime in it which would run 
 per-machine or just the MSIs for those

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

If you really want a per-user package, it's easier to just set 
Package/@InstallScope='perUser' and remove the ALLUSERS and MSIINSTALLPERUSER 
properties completely.

-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com] 
Sent: Friday, January 24, 2014 1:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

I think I figured it out! Typing up what I've done so far helped :-)

I had tried out so many things that I hadn't noticed I accidentally dropped the 
MSIINSTALLPERUSER Property at some point. Putting back

Property Id=MSIINSTALLPERUSER Value=1 /

in my software package resolved the elevation issues in the bundle and .NET 
Framework and C++ Runtime install fine as well as my user software package.
Yay!

On Fri, Jan 24, 2014 at 12:52 PM, Wesley Manning wmann...@dynagen.cawrote:

  My software package uses a folder underneath ProgramFilesFolder as 
 the target folder and I was expecting that on Win7 and up in a 
 per-user install it automatically translates to LocalAppDataFolder instead.

 I think Vista maybe but I think windows 7 doesn't do that.  
 Don't quote me.  I just vaguely remember reading something about that.  
 Maybe someone else can chime in.

 Wes

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: January-24-14 4:18 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
 Bootstrapper

 Let me clarify a bit to tell you what I'm trying to do, what I've 
 tried, and what I thought isn't currently working:

 Goal: Build a WiX installer for my software which installs .NET 
 Framework
 4.5.1 if needed, C++ Runtime if needed, and my software. My software 
 needs to be installed per-user, i.e. it should go into AppData\Local, 
 not Program Files.

 My understanding is
 - To accomplish my goal I need three components: .NET Framework 4.5.1 
 package (provided by NetFx extension), C++ Runtime merge module, and 
 MSI for my software
 - The two prerequisites needs to be installed on a per-machine 
 (elevated) level, my software on a per-user level

 This is what I've tried:
 Attempt 1. Created a WiX bundle with two packages inside the Chain element:
 A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my 
 software as well as the C++ merge module.
 Problem: This wouldn't build because my software Package had 
 InstallScope perUser but apparently the C++ merge module forced 
 ALLUSERS=1 which conflicted with the perUser setting. This problem 
 went away when I took the merge module out of the package.

 Attempt 2: Created a WiX bundle with three packages inside the Chain
 element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++ 
 Runtime merge module (InstallScope perMachine), and an MsiPackage for 
 my software (InstallScope perUser).
 Problem: When running the resulting bundle it would prompt for 
 elevation (which is fine), then install .NET Framework fine, then 
 install the merge module fine, but throw an error for my perUser 
 package: The installer has insufficient privileges to access this 
 directory: C:\Program Files\product. The installation cannot 
 continue. Log on as administrator or contact your system administrator.

 My software package uses a folder underneath ProgramFilesFolder as the 
 target folder and I was expecting that on Win7 and up in a per-user 
 install it automatically translates to LocalAppDataFolder instead.

 I thought from what I had gathered in this thread is that once the 
 bundle gets elevated permissions it will also try to run my software 
 package in forced per machine mode but without elevation, and 
 therefore fails when trying to access the Program Files directory.

 Your last remark sounds though as if this should work. Please help me 
 understand what I'm doing wrong.

 // Sascha

 On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.com
 wrote:

  If you package is per-user then Burn handles that correctly. It will 
  elevate only if necessary (i.e installing per-machine prerequisites) 
  and install your per-user package.  Burn is *designed* to handle 
  that
 correctly.

  -Original Message-
  From: Sascha [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 10:51 AM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
  Bootstrapper

  I just ran into this exact same issue and have been trying to find a 
  suitable solution. I need to install the .NET Framework and also a 
  newer
  C++ runtime as per-machine prerequisites but my software on a 
  C++ per-user
  basis.

  Would using the managed bootstrapper help get around this issue by 
  any chance? My understanding is that using the managed bootstrapper 
  means there are actually two bootstrappers, one that takes care of 
  installing .NET Framework if needed, and then the

Re: [WiX-users] WiX instalers not installing empty directories on target computer

CreateFolder in the chm?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-instalers-not-installing-empty-directories-on-target-computer-tp7592032p7592067.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Making a symbolic link in an installer

2014-01-24 Thread Scott Palmer

Can someone show me code that can successfully do it?

I tried:

CustomAction Id='Mklink' Directory=myDir
  ExeCommand='[SystemFolder]cmd.exe /K mklink /D mylink
[$(var.linkDest)]' Execute=deferred Impersonate=no /

InstallExecuteSequence
Custom Action=Mklink
Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
install of that Compoent Id --

/InstallExecuteSequence

I'm running on Windows 7

The cmd window that pops up (titled: Administrator:
C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't have
permission to make a symbolic link (thanks Microsoft!):
You do not have sufficient privilege to perform this operation.


Thanks,

Scott
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

I always had Package/@InstallScope='perUser', that never changed.

But the key thing for me to get it to work was MSIINSTALLPERUSER=1, without
it I kept getting the insufficient privileges error both in the bundle and
when running the stand-alone MSI.

// Sascha



On Fri, Jan 24, 2014 at 1:34 PM, Rob Mensching r...@robmensching.com wrote:

 Burn does lots of work to make this scenario work (per-machine
 prerequisites and one or more per-user packages). It's unique among
 bootstrappers because it does it in all the right user contexts and all
 that. I saw a follow up email from you on a fork of this thread that found
 the most important thing: You need to make sure your per-user package is
 truly per-user.  The easiest way to do that is to use:
 Package/@InstallScope='perUser'.

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 12:18 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 Let me clarify a bit to tell you what I'm trying to do, what I've tried,
 and what I thought isn't currently working:

 Goal: Build a WiX installer for my software which installs .NET Framework
 4.5.1 if needed, C++ Runtime if needed, and my software. My software needs
 to be installed per-user, i.e. it should go into AppData\Local, not Program
 Files.

 My understanding is
 - To accomplish my goal I need three components: .NET Framework 4.5.1
 package (provided by NetFx extension), C++ Runtime merge module, and MSI
 for my software
 - The two prerequisites needs to be installed on a per-machine (elevated)
 level, my software on a per-user level

 This is what I've tried:
 Attempt 1. Created a WiX bundle with two packages inside the Chain element:
 A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my
 software as well as the C++ merge module.
 Problem: This wouldn't build because my software Package had InstallScope
 perUser but apparently the C++ merge module forced ALLUSERS=1 which
 conflicted with the perUser setting. This problem went away when I took the
 merge module out of the package.

 Attempt 2: Created a WiX bundle with three packages inside the Chain
 element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++
 Runtime merge module (InstallScope perMachine), and an MsiPackage for my
 software (InstallScope perUser).
 Problem: When running the resulting bundle it would prompt for elevation
 (which is fine), then install .NET Framework fine, then install the merge
 module fine, but throw an error for my perUser package: The installer has
 insufficient privileges to access this directory: C:\Program
 Files\product. The installation cannot continue. Log on as administrator
 or contact your system administrator.

 My software package uses a folder underneath ProgramFilesFolder as the
 target folder and I was expecting that on Win7 and up in a per-user install
 it automatically translates to LocalAppDataFolder instead.

 I thought from what I had gathered in this thread is that once the bundle
 gets elevated permissions it will also try to run my software package in
 forced per machine mode but without elevation, and therefore fails when
 trying to access the Program Files directory.

 Your last remark sounds though as if this should work. Please help me
 understand what I'm doing wrong.

 // Sascha



 On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.com
 wrote:

  If you package is per-user then Burn handles that correctly. It will
  elevate only if necessary (i.e installing per-machine prerequisites)
  and install your per-user package.  Burn is *designed* to handle that
 correctly.
 
  -Original Message-
  From: Sascha [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 10:51 AM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
  Bootstrapper
 
  I just ran into this exact same issue and have been trying to find a
  suitable solution. I need to install the .NET Framework and also a
  newer
  C++ runtime as per-machine prerequisites but my software on a per-user
  basis.
 
  Would using the managed bootstrapper help get around this issue by any
  chance? My understanding is that using the managed bootstrapper means
  there are actually two bootstrappers, one that takes care of
  installing .NET Framework if needed, and then the managed one that gets
 launched after.
 
  If the inner managed bootstrapper is capable of doing a regular
  per-user install after the outer native bootstrapper installs the
  .NET Framework, that would solve most of this issue. I say most
  because I also need to install the C++ runtime, but for now I could
  resort to deploy the C++ DLLs locally with my app instead of using the
 merge module.
 
  I'm looking at some of the managed bootstrapper tutorials and blob
  posts right now and will slap something together to try out this

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

Did you have ALLUSERS set the whole time as well?

-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com] 
Sent: Friday, January 24, 2014 2:21 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

I always had Package/@InstallScope='perUser', that never changed.

But the key thing for me to get it to work was MSIINSTALLPERUSER=1, without it 
I kept getting the insufficient privileges error both in the bundle and when 
running the stand-alone MSI.

// Sascha

On Fri, Jan 24, 2014 at 1:34 PM, Rob Mensching r...@robmensching.com wrote:

 Burn does lots of work to make this scenario work (per-machine 
 prerequisites and one or more per-user packages). It's unique among 
 bootstrappers because it does it in all the right user contexts and 
 all that. I saw a follow up email from you on a fork of this thread 
 that found the most important thing: You need to make sure your 
 per-user package is truly per-user.  The easiest way to do that is to use:
 Package/@InstallScope='perUser'.

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 12:18 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
 Bootstrapper

 Let me clarify a bit to tell you what I'm trying to do, what I've 
 tried, and what I thought isn't currently working:

 Goal: Build a WiX installer for my software which installs .NET 
 Framework
 4.5.1 if needed, C++ Runtime if needed, and my software. My software 
 needs to be installed per-user, i.e. it should go into AppData\Local, 
 not Program Files.

 My understanding is
 - To accomplish my goal I need three components: .NET Framework 4.5.1 
 package (provided by NetFx extension), C++ Runtime merge module, and 
 MSI for my software
 - The two prerequisites needs to be installed on a per-machine 
 (elevated) level, my software on a per-user level

 This is what I've tried:
 Attempt 1. Created a WiX bundle with two packages inside the Chain element:
 A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my 
 software as well as the C++ merge module.
 Problem: This wouldn't build because my software Package had 
 InstallScope perUser but apparently the C++ merge module forced 
 ALLUSERS=1 which conflicted with the perUser setting. This problem 
 went away when I took the merge module out of the package.

 Attempt 2: Created a WiX bundle with three packages inside the Chain
 element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++ 
 Runtime merge module (InstallScope perMachine), and an MsiPackage for 
 my software (InstallScope perUser).
 Problem: When running the resulting bundle it would prompt for 
 elevation (which is fine), then install .NET Framework fine, then 
 install the merge module fine, but throw an error for my perUser 
 package: The installer has insufficient privileges to access this 
 directory: C:\Program Files\product. The installation cannot 
 continue. Log on as administrator or contact your system administrator.

 My software package uses a folder underneath ProgramFilesFolder as the 
 target folder and I was expecting that on Win7 and up in a per-user 
 install it automatically translates to LocalAppDataFolder instead.

 I thought from what I had gathered in this thread is that once the 
 bundle gets elevated permissions it will also try to run my software 
 package in forced per machine mode but without elevation, and 
 therefore fails when trying to access the Program Files directory.

 Your last remark sounds though as if this should work. Please help me 
 understand what I'm doing wrong.

 // Sascha

 On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.com
 wrote:

  If you package is per-user then Burn handles that correctly. It will 
  elevate only if necessary (i.e installing per-machine prerequisites) 
  and install your per-user package.  Burn is *designed* to handle 
  that
 correctly.

  -Original Message-
  From: Sascha [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 10:51 AM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and 
  Bootstrapper

  I just ran into this exact same issue and have been trying to find a 
  suitable solution. I need to install the .NET Framework and also a 
  newer
  C++ runtime as per-machine prerequisites but my software on a 
  C++ per-user
  basis.

  Would using the managed bootstrapper help get around this issue by 
  any chance? My understanding is that using the managed bootstrapper 
  means there are actually two bootstrappers, one that takes care of 
  installing .NET Framework if needed, and then the managed one that 
  gets
 launched after.

  If the inner managed bootstrapper is capable of doing a regular 
  per-user install after the outer native bootstrapper installs the 
  .NET

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

No I did not set ALLUSERS directly.


On Fri, Jan 24, 2014 at 2:32 PM, Rob Mensching r...@robmensching.com wrote:

 Did you have ALLUSERS set the whole time as well?

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: Friday, January 24, 2014 2:21 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 I always had Package/@InstallScope='perUser', that never changed.

 But the key thing for me to get it to work was MSIINSTALLPERUSER=1,
 without it I kept getting the insufficient privileges error both in the
 bundle and when running the stand-alone MSI.

 // Sascha



 On Fri, Jan 24, 2014 at 1:34 PM, Rob Mensching r...@robmensching.com
 wrote:

  Burn does lots of work to make this scenario work (per-machine
  prerequisites and one or more per-user packages). It's unique among
  bootstrappers because it does it in all the right user contexts and
  all that. I saw a follow up email from you on a fork of this thread
  that found the most important thing: You need to make sure your
  per-user package is truly per-user.  The easiest way to do that is to
 use:
  Package/@InstallScope='perUser'.
 
  -Original Message-
  From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 12:18 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
  Bootstrapper
 
  Let me clarify a bit to tell you what I'm trying to do, what I've
  tried, and what I thought isn't currently working:
 
  Goal: Build a WiX installer for my software which installs .NET
  Framework
  4.5.1 if needed, C++ Runtime if needed, and my software. My software
  needs to be installed per-user, i.e. it should go into AppData\Local,
  not Program Files.
 
  My understanding is
  - To accomplish my goal I need three components: .NET Framework 4.5.1
  package (provided by NetFx extension), C++ Runtime merge module, and
  MSI for my software
  - The two prerequisites needs to be installed on a per-machine
  (elevated) level, my software on a per-user level
 
  This is what I've tried:
  Attempt 1. Created a WiX bundle with two packages inside the Chain
 element:
  A PackageGroupRef for NetFx451Web, and an MsiPackage that includes my
  software as well as the C++ merge module.
  Problem: This wouldn't build because my software Package had
  InstallScope perUser but apparently the C++ merge module forced
  ALLUSERS=1 which conflicted with the perUser setting. This problem
  went away when I took the merge module out of the package.
 
  Attempt 2: Created a WiX bundle with three packages inside the Chain
  element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++
  Runtime merge module (InstallScope perMachine), and an MsiPackage for
  my software (InstallScope perUser).
  Problem: When running the resulting bundle it would prompt for
  elevation (which is fine), then install .NET Framework fine, then
  install the merge module fine, but throw an error for my perUser
  package: The installer has insufficient privileges to access this
  directory: C:\Program Files\product. The installation cannot
  continue. Log on as administrator or contact your system administrator.
 
  My software package uses a folder underneath ProgramFilesFolder as the
  target folder and I was expecting that on Win7 and up in a per-user
  install it automatically translates to LocalAppDataFolder instead.
 
  I thought from what I had gathered in this thread is that once the
  bundle gets elevated permissions it will also try to run my software
  package in forced per machine mode but without elevation, and
  therefore fails when trying to access the Program Files directory.
 
  Your last remark sounds though as if this should work. Please help me
  understand what I'm doing wrong.
 
  // Sascha
 
 
 
  On Fri, Jan 24, 2014 at 11:14 AM, Rob Mensching r...@robmensching.com
  wrote:
 
   If you package is per-user then Burn handles that correctly. It will
   elevate only if necessary (i.e installing per-machine prerequisites)
   and install your per-user package.  Burn is *designed* to handle
   that
  correctly.
  
   -Original Message-
   From: Sascha [mailto:sascha.ser...@gmail.com]
   Sent: Friday, January 24, 2014 10:51 AM
   To: wix-users@lists.sourceforge.net
   Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
   Bootstrapper
  
   I just ran into this exact same issue and have been trying to find a
   suitable solution. I need to install the .NET Framework and also a
   newer
   C++ runtime as per-machine prerequisites but my software on a
   C++ per-user
   basis.
  
   Would using the managed bootstrapper help get around this issue by
   any chance? My understanding is that using the managed bootstrapper
   means there are actually two bootstrappers, one that takes care of
   installing .NET Framework if needed, and then the managed

[WiX-users] Strange permissions failure for EFI handling

2014-01-24 Thread Mustafa Jamil

Hello.
I have a WiX MSI that installs a bootloader.  On EFI systems, it does so in the 
EFI system partition.  On BIOS systems, it chainloads the new boot option to 
the Windows Boot Manager (and so running bcdedit shows the new option).
When I run my MSI on a BIOS system, everything works as expected. If I run cmd 
as administrator and then install the MSI via msiexec, things work. If I 
instead run cmd normally, or just double-click on the MSI, I'll get a UAC 
prompt, and then things work as expected.
For EFI, the story is different. On an EFI-installed system, if I run cmd as 
administrator and then install the MSI via msiexec, things work.  But if I go 
the UAC prompt route, my MSI installation fails.
This is confusing. I thought there is no difference between running a command 
explicitly as administrator, and running a command by accepting the UAC prompt, 
but this clearly shows there is in fact a difference.
Any ideas why I'm running into this behaviour?  Any ideas how I can fix this, 
or at least debug it further?
P.S. I use the Get/SetEnvironmentVariable API calls from my code to tweak the 
EFI partition.  This requires the SeSystemEnvironmentPrivilege, which I do set, 
so that's not the issue, AFAIK. 
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Making a symbolic link in an installer

2014-01-24 Thread Jeremiahf

Are you using
 InstallPrivileges=elevated
 InstallScope=perMachine/
in Package Id=
?

I've done it this way...give it a try. I to am running on windows 7

CustomAction Id=ScriptForRemove
  Directory=TARGETDIR
 ExeCommand=cmd.exe /c sc delete something
 Return=check
Execute=deferred
Impersonate=no /


On Fri, Jan 24, 2014 at 4:12 PM, Scott Palmer swpal...@gmail.com wrote:

 Can someone show me code that can successfully do it?

 I tried:

 CustomAction Id='Mklink' Directory=myDir
   ExeCommand='[SystemFolder]cmd.exe /K mklink /D mylink
 [$(var.linkDest)]' Execute=deferred Impersonate=no /

 InstallExecuteSequence
 Custom Action=Mklink
 Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
 install of that Compoent Id --

 /InstallExecuteSequence

 I'm running on Windows 7

 The cmd window that pops up (titled: Administrator:
 C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't have
 permission to make a symbolic link (thanks Microsoft!):
 You do not have sufficient privilege to perform this operation.


 Thanks,

 Scott

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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




-- 
They may forget what you said but they will never forget how you made them
feel. -- Anonymous
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] 3 questions about Burn

2014-01-24 Thread Jun Yin

I am trying to create a simple Bundle with a few MSP patches using WIX and 
Burn. According to the documentation, it seems very straight forward, like this:

?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension; 
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
   Bundle Version=1.0 UpgradeCode=E2713294-EE47-4A20-A2B0-7F9BD6EF0D50
  BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.RtfLicense
 bal:WixStandardBootstrapperApplication 
LicenseFile=eula-en-us.rtf SuppressOptionsUI=yes/
  /BootstrapperApplicationRef
  Chain
 MspPackage Id=ccc SourceFile=ccc-x-none.msp /
 MspPackage Id=mmm SourceFile=mmm-x-none.msp /
  /Chain
   /Bundle
/Wix

However, the built bundle seems very primitive and therefore I want to know if 
Burn supports the following features:

1. It display EULA only in en-us language. Is it possible or how to embed EULA 
of multiple languages into the bundle, so Burn can display EULA corresponding 
to user's operating system locale?

2. Bundle.exe /layout does not extract EULA and individual MSP files, 
instead, it copies Bundle.exe itself to the specified directory. Our scenario 
requires the support of file extraction, so users can examine the files or 
deploy them to elsewhere.

I know we can use dark to decompose the bundle, but users have to download WIX 
toolset to have dark.exe. It is not convenient compared to a self-extracting 
archive.

3. The bundle does not detect MSP applicability. If I install Bundle.exe to a 
system with no RTM product installed, the bundle still claims it installs 
successfully. We would like to show an error instead.

Though it is possible to use util:ProductSearch and bal:Condition to detect 
MSP applicability, it is really cumbersome and duplicated work, as in the 
bundle, Burn already generates in UX\manifest.xml that contains the 
/BurnManifest/Chain/MspPackage/@PatchXml  which is designed specifically for 
MSP applicability detection.

Thank you,
Jun



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] SqlScript with large schema setup

2014-01-24 Thread Chad Petersen

We've run into this. Luckily the one largest SQL script is also the last one we 
need to execute so we removed it from the installer and just have customers run 
that one manually using SQL Management Studio. About 34 seconds to run through 
there while the installer takes an hour and a half to run the same script.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Thursday, January 23, 2014 4:39 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SqlScript with large schema setup

Code was originally written sometime around 2001. It hasn't changed really 
since then.

-Original Message-
From: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Thursday, January 23, 2014 2:31 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SqlScript with large schema setup

I'm actually looking at it now :-) I can live with the initial, since that's 
only going to happen the first time you run our installer and our schema is not 
there. On an update (doing major upgrades) we are going to have migration 
scripts run. Those should not be near what this initial one is.

Looking at the code (I just have 3.7, but it doesn't sounds like it's changed 
in awhile) I'm not seeing any tests for any of the parsing in scasqlstr.cpp, 
which intimidates me :-) It's doing a LOT, but mostly looks like it is just 
eating comments and removing GO statements to execute each command 
individually. I may fall into the group of living with it ;-)

On Thu, Jan 23, 2014 at 4:47 PM, Rob Mensching r...@robmensching.com wrote:

 I assume most people live with the perf since no one has ever bothered 
 to fix the bug.

 -Original Message-
 From: Levi Wilson [mailto:l...@leviwilson.com]
 Sent: Thursday, January 23, 2014 12:30 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] SqlScript with large schema setup

 What are other ways that people have gotten around it? It doesn't seem 
 desirable to execute `sqlcmd` from a CA.

 On Thu, Jan 23, 2014 at 2:26 PM, Rob Mensching r...@robmensching.com
 wrote:

  You'll want to think about security with that second option. I don't 
  think the MSI property is the issue. I think it's the SQLCA code 
  itself that is slow parsing. IIRC, there is a (very old) bug about 
  the perf problem. Maybe you'd like to tackle it?

  -Original Message-
  From: Levi Wilson [mailto:l...@leviwilson.com]
  Sent: Thursday, January 23, 2014 10:41 AM
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] SqlScript with large schema setup

  Sorry I didn't mention this before, but the database is already 
  going to exist. Our customers create this beforehand. The installer 
  will just be running the SQL script for the initial schema to create 
  all of our tables, triggers, sprocs, etc.

  When looking at the installer log, I see two lines that jump out at me:

  MSI (s) (C4!BC) [11:44:00:998]: Closing MSIHANDLE (45) of type
  790540 for thread 12732 MSI (s) (C4!BC) [11:50:33:616]: PROPERTY CHANGE:
  Adding ExecuteSqlStrings property. Its value is '**'.

  So it looks like it takes 6 minutes to take the 144k lines of my SQL 
  script that is stored in a binary / to create the 
  ExecuteSqlStrings property.
  Seems like I'm holding it wrong :-)

  Would a better option be to create a CA that reads the SQL out of a 
  binary record and execute it myself? Rather than having the 
  intermediate step of creating an MSI property?

  Levi

   Why not right click on the DB, tasks and generate in MS? What 
   version of SQL?

  On Thu, Jan 23, 2014 at 10:52 AM, Levi Wilson levi@... wrote:
I am using a SqlScript / to create our database schema. I 
exported the schema using RedGate. The file is 10MB (I know, I
 know...).
Everything works as expected, but during the installation the 
Configuring SQL
   Server
takes forever.

I know, 10MB file with 144k lines of SQL to parse is a lot...is 
there a better alternative to getting this initial script created?

Thanks in advance,

Levi

   --
   --
   --

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For 
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.

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

   --
   They may forget what you said but they will never forget how you 
   made them feel. -- Anonymous

  --
   CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More

Re: [WiX-users] Making a symbolic link in an installer

2014-01-24 Thread Scott Palmer

Yes.  As far as I can tell my Custom Action is running elevated, but even
at that level there is no privilege to create a symlink.  I can't imagine
why.. but that seems to be the case.

Try it yourself... change your command to execute something like

cmd.exe /c mklink /D some_link_name  some_directory_path


I can't get it to work.

When I used cmd.exe /k ... so the window remained I ran:

whoami /user

That told me the account was 'nt authority\system',  SID 'S-1-5-18'


Scott


On Fri, Jan 24, 2014 at 5:55 PM, Jeremiahf jeremi...@gmail.com wrote:

 Are you using
  InstallPrivileges=elevated
  InstallScope=perMachine/
 in Package Id=
 ?

 I've done it this way...give it a try. I to am running on windows 7

 CustomAction Id=ScriptForRemove
   Directory=TARGETDIR
  ExeCommand=cmd.exe /c sc delete something
  Return=check
 Execute=deferred
 Impersonate=no /


 On Fri, Jan 24, 2014 at 4:12 PM, Scott Palmer swpal...@gmail.com wrote:

  Can someone show me code that can successfully do it?
 
  I tried:
 
  CustomAction Id='Mklink' Directory=myDir
ExeCommand='[SystemFolder]cmd.exe /K mklink /D
 mylink
  [$(var.linkDest)]' Execute=deferred Impersonate=no /
 
  InstallExecuteSequence
  Custom Action=Mklink
  Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
  install of that Compoent Id --
 
  /InstallExecuteSequence
 
  I'm running on Windows 7
 
  The cmd window that pops up (titled: Administrator:
  C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't have
  permission to make a symbolic link (thanks Microsoft!):
  You do not have sufficient privilege to perform this operation.
 
 
  Thanks,
 
  Scott
 
 
 --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For
  Critical Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 



 --
 They may forget what you said but they will never forget how you made them
 feel. -- Anonymous

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Making a symbolic link in an installer

2014-01-24 Thread Jeremiahf

Interesting... does it not work with removing the quotes from
[$(var.linkDest)]' ? btw... I copied your line and there is an extra '
after [$(var.linkDest)]. I pasted it in notepad and saw it more clear.

Check this out.

http://www.windows7home.net/how-to-create-symbolic-link-in-windows-7/

use runas if you need to really need to rock the cmd.exe

C:\runas /user:localmachinename\administrator cmd.exe /c mklink /D
some_link_name  some_directory_path


C:\runas /user:DomainName\AdministratorAccountName cmd

ref from: C:\runas /user:DomainName\AdministratorAccountName cmd

cheers



On Fri, Jan 24, 2014 at 4:12 PM, Scott Palmer swpal...@gmail.com wrote:

 Can someone show me code that can successfully do it?

 I tried:

 CustomAction Id='Mklink' Directory=myDir
   ExeCommand='[SystemFolder]cmd.exe /K mklink /D mylink
 [$(var.linkDest)]' Execute=deferred Impersonate=no /

 InstallExecuteSequence
 Custom Action=Mklink
 Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
 install of that Compoent Id --

 /InstallExecuteSequence

 I'm running on Windows 7

 The cmd window that pops up (titled: Administrator:
 C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't have
 permission to make a symbolic link (thanks Microsoft!):
 You do not have sufficient privilege to perform this operation.


 Thanks,

 Scott

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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




-- 
They may forget what you said but they will never forget how you made them
feel. -- Anonymous
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Install busy executables at reboot - Windows 7

2014-01-24 Thread Walter Dexter

I have an embedded system running Windows POSReady 7 (Windows 7 for POS
devices.)

I have an MSI that installs a collection of .Net .exe files, VBScripts, and
other stuff.

Three of the executables are always running under a user account. That's
just a normal thing on this device - it boots, automatically logs in as a
specific user, and these executables start.

I'm now trying to do a upgrade by doing a Major Upgrade of the prior MSI.
That's actually working fine. My problem is that Windows Installer seems to
be shutting down the executables that are always running to do the install.

I've read a bit about the restart manager, and other things, but all I
really want it to do is make a note that these files are to be replaced at
the next reboot (which happens at 4:00 AM every day) and leave the
executables running.

We run the MSIs out of the usual set of Microsoft system management tools
(SCCM? SCOM? It isn't my area so I don't real know) so there's no UI, and
no user to say shut them down and restart them.

Honestly I haven't tried this out of the Microsoft infrastructure; I'm just
firing up a runas /user:administrator cmd.exe and running the MSI with
the /quiet flag. I guess it's possible that it will behave differently
there but it seems unlikely.

So is there a way to get it to do this?

I've read a bit about the restart manager and messed about with various
property values but none of it seemed to have any impact. If I run without
/quiet it presented a variety of different dialogs telling me the programs
needed to be stopped, sometimes offering to do it and restart them later.
If I run with /quiet, it always quietly kills them and doesn't restart them.

My fallback position is to have the MSI logoff the console - whiich is
trivial to do - because it will then autolog back on and start all the
programs up.

It's a lot easier politically if I can hand off an MSI that the users don't
notice installing. If they notice it - if the programs stop and restart, or
if it logs off and back on - then we've got a lot of communication that
needs to happen.

Thanks for any advice!

Walt
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 3 questions about Burn

1. wixstdba supports this.

2. Burn doesn't work that way. See the archive of this mailing list for 
previous discussions about it. There may be a feature request open about it.

3. wixstdba doesn't behave that way today. You'd need a custom BA to do 
something more automatically.

-Original Message-
From: Jun Yin [mailto:jun...@microsoft.com] 
Sent: Friday, January 24, 2014 3:14 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 3 questions about Burn

I am trying to create a simple Bundle with a few MSP patches using WIX and 
Burn. According to the documentation, it seems very straight forward, like this:

?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension; 
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
   Bundle Version=1.0 UpgradeCode=E2713294-EE47-4A20-A2B0-7F9BD6EF0D50
  BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.RtfLicense
 bal:WixStandardBootstrapperApplication 
LicenseFile=eula-en-us.rtf SuppressOptionsUI=yes/
  /BootstrapperApplicationRef
  Chain
 MspPackage Id=ccc SourceFile=ccc-x-none.msp /
 MspPackage Id=mmm SourceFile=mmm-x-none.msp /
  /Chain
   /Bundle
/Wix

However, the built bundle seems very primitive and therefore I want to know if 
Burn supports the following features:

1. It display EULA only in en-us language. Is it possible or how to embed EULA 
of multiple languages into the bundle, so Burn can display EULA corresponding 
to user's operating system locale?

2. Bundle.exe /layout does not extract EULA and individual MSP files, 
instead, it copies Bundle.exe itself to the specified directory. Our scenario 
requires the support of file extraction, so users can examine the files or 
deploy them to elsewhere.

I know we can use dark to decompose the bundle, but users have to download WIX 
toolset to have dark.exe. It is not convenient compared to a self-extracting 
archive.

3. The bundle does not detect MSP applicability. If I install Bundle.exe to a 
system with no RTM product installed, the bundle still claims it installs 
successfully. We would like to show an error instead.

Though it is possible to use util:ProductSearch and bal:Condition to detect 
MSP applicability, it is really cumbersome and duplicated work, as in the 
bundle, Burn already generates in UX\manifest.xml that contains the 
/BurnManifest/Chain/MspPackage/@PatchXml  which is designed specifically for 
MSP applicability detection.

Thank you,
Jun



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install busy executables at reboot - Windows 7