[WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

2014-08-27 Thread Thomas Due
Hello, 

I have recently had an epiphany regarding Burn, and have been busy writing a 
bundle for our installer package. 
Now, we have several prerequisites that needs to be installed before our own 
installer is executed. 

The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the 
NetFxExtension, 
but how about Windows Installer 4.5?
SharedManagementObjects?
Sql Server 2012 Express?

I realize that I can download all these and add them compressed or uncompressed 
directly to my bundle, but what if I do not want to redistribute these myself, 
but rather just add a download link, just like the NetFx45Web package. 

Alternatively how can I define the redists in my bundle but not include them 
directly in the build? But rather package them when we deploy? 

This way I would be able to package two different deployment packages, one for 
32-bit and one for 64-bit. 

I have found direct links for the Sql Server Express 2012, thanks to Scott 
Hanselman here: http://downloadsqlserverexpress.com/
But I cannot figure out how to include them in my bundle for downloading, but 
not having them physically present. 

I have this:

ExePackage Id=SqlExpress86
PerMachine=yes
Permanent=yes
Name=SQLEXPRWT_x86_ENU.exe
Compressed=no
Cache=no

DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe;
DetectCondition=InstallSQL AND (NOT VersionNT64)/

It seems I need to include a RemotePayload, which requires all sorts of 
information regarding public keys etc. that I don't have. 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210 
Johann Gutenbergs vej 5-9, Aarhus N, Denmark 
t...@scanvaegt.dk | www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: wix-users-requ...@lists.sourceforge.net 
[mailto:wix-users-requ...@lists.sourceforge.net] 
Sent: 27. august 2014 04:58
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 99, Issue 59

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
wix-users-requ...@lists.sourceforge.net

You can reach the person managing the list at
wix-users-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific than Re: 
Contents of WiX-users digest...

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread linos
Hi Rob,

My mistake.  I should have been more descriptive with my wix.zip
reference.  
I was referring to the wix-16a8b5dbf828f92e28138ce3c9ee852affeaa1ef.zip.

Just curious, since I have you attention, but what is the preferred method
to using the existing wixBA?
Is it first creating a new solution in visual studio then adding the wixBA
and core projects? Or what I mentioned above in my previous post in order to
get things to work?  I would like to prevent others from having this bad
experience.

Thanks,
Lino



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-view-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596570.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

2014-08-27 Thread Matt O'Connell
For those without a support contract, where's the most visible place to 
post? msdn forums (clickonce and setup  deployment projects, I've never 
found an MSI one...) or microsoft.public.platformsdk.msi newsgroup?  The 
installer team blog would've been a good place but its not updated anymore..

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread Asbjørn Mikkelsen
Hm, the wix.zip files that are on wixtoolset.org is names
wix32-binaries.zip etc?


On Wed, Aug 27, 2014 at 2:49 PM, linos lino...@hotmail.com wrote:

 Hi Rob,

 My mistake.  I should have been more descriptive with my wix.zip
 reference.
 I was referring to the wix-16a8b5dbf828f92e28138ce3c9ee852affeaa1ef.zip.

 Just curious, since I have you attention, but what is the preferred method
 to using the existing wixBA?
 Is it first creating a new solution in visual studio then adding the wixBA
 and core projects? Or what I mentioned above in my previous post in order
 to
 get things to work?  I would like to prevent others from having this bad
 experience.

 Thanks,
 Lino



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-view-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596570.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
mvh
Asbjørn
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

2014-08-27 Thread Hoover, Jacob
The bundle build process requires them on disk or you can satisfy this with the 
RemotePayload. If you specify a DownloadURL, you don't need to distribute the 
payload with your bundle.  It will download them if and only if the payload is 
needed. 

 

-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk] 
Sent: Wednesday, August 27, 2014 7:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

Hello, 

I have recently had an epiphany regarding Burn, and have been busy writing a 
bundle for our installer package. 
Now, we have several prerequisites that needs to be installed before our own 
installer is executed. 

The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the 
NetFxExtension, but how about Windows Installer 4.5?
SharedManagementObjects?
Sql Server 2012 Express?

I realize that I can download all these and add them compressed or uncompressed 
directly to my bundle, but what if I do not want to redistribute these myself, 
but rather just add a download link, just like the NetFx45Web package. 

Alternatively how can I define the redists in my bundle but not include them 
directly in the build? But rather package them when we deploy? 

This way I would be able to package two different deployment packages, one for 
32-bit and one for 64-bit. 

I have found direct links for the Sql Server Express 2012, thanks to Scott 
Hanselman here: http://downloadsqlserverexpress.com/
But I cannot figure out how to include them in my bundle for downloading, but 
not having them physically present. 

I have this:

ExePackage Id=SqlExpress86
PerMachine=yes
Permanent=yes
Name=SQLEXPRWT_x86_ENU.exe
Compressed=no
Cache=no

DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe;
DetectCondition=InstallSQL AND (NOT VersionNT64)/

It seems I need to include a RemotePayload, which requires all sorts of 
information regarding public keys etc. that I don't have. 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210
Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | 
www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: wix-users-requ...@lists.sourceforge.net 
[mailto:wix-users-requ...@lists.sourceforge.net]
Sent: 27. august 2014 04:58
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 99, Issue 59

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
wix-users-requ...@lists.sourceforge.net

You can reach the person managing the list at
wix-users-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific than Re: 
Contents of WiX-users digest...

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread Phill Hogland
If you go to https://github.com/wixtoolset/wix3 and click on Download you
will get a zip which has a name of wix-alphanumeric string.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-view-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596574.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread Rob Mensching
Sounds like you are getting snapshots of the source code from GitHub. Usually, 
if you want the source code I'd say just use git to clone the repo.

The WixBA also isn't designed to be a starting point. It's good as a reference 
codebase but the source code certainly isn't packaged up as a starter kit.

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

-Original Message-
From: linos [mailto:lino...@hotmail.com] 
Sent: Wednesday, August 27, 2014 5:49 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

Hi Rob,

My mistake.  I should have been more descriptive with my wix.zip
reference.  
I was referring to the wix-16a8b5dbf828f92e28138ce3c9ee852affeaa1ef.zip.

Just curious, since I have you attention, but what is the preferred method to 
using the existing wixBA?
Is it first creating a new solution in visual studio then adding the wixBA and 
core projects? Or what I mentioned above in my previous post in order to get 
things to work?  I would like to prevent others from having this bad experience.

Thanks,
Lino



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-view-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596570.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn to MSI -- Secure password -- Best Parctice

2014-08-27 Thread Phill Hogland
If I collect a password in my mba, I am wondering what the best way is to
pass it down to the MSI.  I considered calling the win32 Crypt API to store
the password (and then have the MSI retrieve the password from the store),
but if a mba should not change the system, what is a secure way to pass this
information to a MSI?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-to-MSI-Secure-password-Best-Parctice-tp7596576.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn to MSI -- Secure password -- Best Parctice

2014-08-27 Thread Rob Mensching
Mark the Bundle/@Variable and Product/@Property Hidden='yes'. Burn v3.9 will 
store it as a secure string... Windows Installer will do what it does (it's not 
documented).

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

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: Wednesday, August 27, 2014 8:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Burn to MSI -- Secure password -- Best Parctice

If I collect a password in my mba, I am wondering what the best way is to pass 
it down to the MSI.  I considered calling the win32 Crypt API to store the 
password (and then have the MSI retrieve the password from the store), but if a 
mba should not change the system, what is a secure way to pass this information 
to a MSI?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-to-MSI-Secure-password-Best-Parctice-tp7596576.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn to MSI -- Secure password -- Best Parctice

2014-08-27 Thread Phill Hogland
Thanks Rob, very much.  I had the Bundle/@Variable hidden but missed the
Product/@Property.  Thanks again.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-to-MSI-Secure-password-Best-Parctice-tp7596576p7596578.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread gregbty
gregbty wrote
 I'll fill in some background information before the question. (/smile)
 
 I started working on a custom updater application that essentially needed
 to perform the following tasks:
 
 1) Get latest version information for application from a remote location
 2) Display release notes and latest version information to the user
 3) Download the setup package (currently with WCF via TCP or directly via
 HTTP) 
 4) Install the setup package
 
 I was able to set this up fine without any issues. But I wanted to extend
 it and provide actual progress and status to the user through the updater
 application instead of just opening the MSI file after downloading it. The
 Bootstrapper Engine already provided this logic, so why reinvent the
 wheel?
 
 We already are using WiX with a custom Bootstrapper UI for our installer.
 I ended up integrating the updater logic there as well so that we could
 ensure that users always had the latest package before installation. Then
 I started wondering whether or not I could just use the Bootstrapper UI
 post installation as my updater application instead. I could just pass in
 various command line arguments to accomplish the flow that I wanted. The
 big problem is that there is a circular dependency. The Bootstrapper
 bundle needs the final MSI and the updater needs to be included in the MSI
 to ensure that it is installed with the application.
 
 So I have a few questions that I haven't found any definitive answers to:
 
 1) Is it possible to install the executing Bootstrapper application into
 the application's folder? Is there some variable exposed? (This is
 probably a long shot since the MSI knows nothing of the Bootstrapper)
 
 2) Is it possible or in the works to externalize a MSI package in a bundle
 chain? Can I use the DownloadUrl property or somehow hook into a
 Boostrapper engine event that allows me to download the MSI package for
 the bundle at run time (The DetectUpdateBegin event comes to mind).
 
 3) Is it possible to create a fake bundle with a fake MSI that can be
 used to just build the Bootstrapper application? Then, would I able to
 ignore the bundle completely and use an event like DetectUpdateBegin to
 force the Bootstrapper application to install a package not listed in the
 bundle?
 
 I want to get these questions answered to determine whether or not it's
 worth it going down this rabbit hole. Thanks in advance!

Replying to message since I had to resubscribe to the list first.




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596579p7596580.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread gregbty
I'll fill in some background information before the question. (/smile)

I started working on a custom updater application that essentially needed to
perform the following tasks:

1) Get latest version information for application from a remote location
2) Display release notes and latest version information to the user
3) Download the setup package (currently with WCF via TCP or directly via
HTTP) 
4) Install the setup package

I was able to set this up fine without any issues. But I wanted to extend it
and provide actual progress and status to the user through the updater
application instead of just opening the MSI file after downloading it. The
Bootstrapper Engine already provided this logic, so why reinvent the wheel?

We already are using WiX with a custom Bootstrapper UI for our installer. I
ended up integrating the updater logic there as well so that we could ensure
that users always had the latest package before installation. Then I started
wondering whether or not I could just use the Bootstrapper UI post
installation as my updater application instead. I could just pass in various
command line arguments to accomplish the flow that I wanted. The big problem
is that there is a circular dependency. The Bootstrapper bundle needs the
final MSI and the updater needs to be included in the MSI to ensure that it
is installed with the application.

So I have a few questions that I haven't found any definitive answers to:

1) Is it possible to install the executing Bootstrapper application into
the application's folder? Is there some variable exposed? (This is probably
a long shot since the MSI knows nothing of the Bootstrapper)

2) Is it possible or in the works to externalize a MSI package in a bundle
chain? Can I use the DownloadUrl property or somehow hook into a Boostrapper
engine event that allows me to download the MSI package for the bundle at
run time (The DetectUpdateBegin event comes to mind).

3) Is it possible to create a fake bundle with a fake MSI that can be
used to just build the Bootstrapper application? Then, would I able to
ignore the bundle completely and use an event like DetectUpdateBegin to
force the Bootstrapper application to install a package not listed in the
bundle?

I want to get these questions answered to determine whether or not it's
worth it going down this rabbit hole. Thanks in advance!



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596581.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread Rob Mensching
Jacob is working towards a solution to this using the Bundle update feature in 
WiX v3.9.

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

-Original Message-
From: gregbty [mailto:greg.bea...@gmail.com] 
Sent: Wednesday, August 27, 2014 10:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Updater application using Bootstrapper UI/Bundle

I'll fill in some background information before the question. (/smile)

I started working on a custom updater application that essentially needed to 
perform the following tasks:

1) Get latest version information for application from a remote location
2) Display release notes and latest version information to the user
3) Download the setup package (currently with WCF via TCP or directly via
HTTP)
4) Install the setup package

I was able to set this up fine without any issues. But I wanted to extend it 
and provide actual progress and status to the user through the updater 
application instead of just opening the MSI file after downloading it. The 
Bootstrapper Engine already provided this logic, so why reinvent the wheel?

We already are using WiX with a custom Bootstrapper UI for our installer. I 
ended up integrating the updater logic there as well so that we could ensure 
that users always had the latest package before installation. Then I started 
wondering whether or not I could just use the Bootstrapper UI post installation 
as my updater application instead. I could just pass in various command line 
arguments to accomplish the flow that I wanted. The big problem is that there 
is a circular dependency. The Bootstrapper bundle needs the final MSI and the 
updater needs to be included in the MSI to ensure that it is installed with the 
application.

So I have a few questions that I haven't found any definitive answers to:

1) Is it possible to install the executing Bootstrapper application into the 
application's folder? Is there some variable exposed? (This is probably a long 
shot since the MSI knows nothing of the Bootstrapper)

2) Is it possible or in the works to externalize a MSI package in a bundle 
chain? Can I use the DownloadUrl property or somehow hook into a Boostrapper 
engine event that allows me to download the MSI package for the bundle at run 
time (The DetectUpdateBegin event comes to mind).

3) Is it possible to create a fake bundle with a fake MSI that can be used 
to just build the Bootstrapper application? Then, would I able to ignore the 
bundle completely and use an event like DetectUpdateBegin to force the 
Bootstrapper application to install a package not listed in the bundle?

I want to get these questions answered to determine whether or not it's worth 
it going down this rabbit hole. Thanks in advance!



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596581.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread Hoover, Jacob
Have a look at dutil.lib's butil.cpp.

BundleEnumRelatedBundle - BundleGetBundleInfo

I wrapped butil in a simple DLL, and I deployed the DLL with the application.  
The application has to know the upgrade code of the bundle, but when the 
application wants to check for an update it gets the ModifyPath bundle key 
value and passes a custom checkupdate switch to the bundle in the package 
cache. From there, it's all standard Wix behavior as long as your bundle has a 
feed supplied to the bundle.

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Wednesday, August 27, 2014 1:07 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

Jacob is working towards a solution to this using the Bundle update feature in 
WiX v3.9.

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

-Original Message-
From: gregbty [mailto:greg.bea...@gmail.com] 
Sent: Wednesday, August 27, 2014 10:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Updater application using Bootstrapper UI/Bundle

I'll fill in some background information before the question. (/smile)

I started working on a custom updater application that essentially needed to 
perform the following tasks:

1) Get latest version information for application from a remote location
2) Display release notes and latest version information to the user
3) Download the setup package (currently with WCF via TCP or directly via
HTTP)
4) Install the setup package

I was able to set this up fine without any issues. But I wanted to extend it 
and provide actual progress and status to the user through the updater 
application instead of just opening the MSI file after downloading it. The 
Bootstrapper Engine already provided this logic, so why reinvent the wheel?

We already are using WiX with a custom Bootstrapper UI for our installer. I 
ended up integrating the updater logic there as well so that we could ensure 
that users always had the latest package before installation. Then I started 
wondering whether or not I could just use the Bootstrapper UI post installation 
as my updater application instead. I could just pass in various command line 
arguments to accomplish the flow that I wanted. The big problem is that there 
is a circular dependency. The Bootstrapper bundle needs the final MSI and the 
updater needs to be included in the MSI to ensure that it is installed with the 
application.

So I have a few questions that I haven't found any definitive answers to:

1) Is it possible to install the executing Bootstrapper application into the 
application's folder? Is there some variable exposed? (This is probably a long 
shot since the MSI knows nothing of the Bootstrapper)

2) Is it possible or in the works to externalize a MSI package in a bundle 
chain? Can I use the DownloadUrl property or somehow hook into a Boostrapper 
engine event that allows me to download the MSI package for the bundle at run 
time (The DetectUpdateBegin event comes to mind).

3) Is it possible to create a fake bundle with a fake MSI that can be used 
to just build the Bootstrapper application? Then, would I able to ignore the 
bundle completely and use an event like DetectUpdateBegin to force the 
Bootstrapper application to install a package not listed in the bundle?

I want to get these questions answered to determine whether or not it's worth 
it going down this rabbit hole. Thanks in advance!



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596581.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread Hoover, Jacob
Note, to get that info from the bundle to the application I utilized 

MsiProperty Name=BUNDLEPROVIDERKEY Value=[WixBundleProviderKey]/

In the bundle, and then in the MSI you can consume this property to write it to 
an application specific location (ini, registry, etc) via a standard custom 
action.

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Wednesday, August 27, 2014 1:28 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

Have a look at dutil.lib's butil.cpp.

BundleEnumRelatedBundle - BundleGetBundleInfo

I wrapped butil in a simple DLL, and I deployed the DLL with the application.  
The application has to know the upgrade code of the bundle, but when the 
application wants to check for an update it gets the ModifyPath bundle key 
value and passes a custom checkupdate switch to the bundle in the package 
cache. From there, it's all standard Wix behavior as long as your bundle has a 
feed supplied to the bundle.

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Wednesday, August 27, 2014 1:07 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

Jacob is working towards a solution to this using the Bundle update feature in 
WiX v3.9.

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

-Original Message-
From: gregbty [mailto:greg.bea...@gmail.com] 
Sent: Wednesday, August 27, 2014 10:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Updater application using Bootstrapper UI/Bundle

I'll fill in some background information before the question. (/smile)

I started working on a custom updater application that essentially needed to 
perform the following tasks:

1) Get latest version information for application from a remote location
2) Display release notes and latest version information to the user
3) Download the setup package (currently with WCF via TCP or directly via
HTTP)
4) Install the setup package

I was able to set this up fine without any issues. But I wanted to extend it 
and provide actual progress and status to the user through the updater 
application instead of just opening the MSI file after downloading it. The 
Bootstrapper Engine already provided this logic, so why reinvent the wheel?

We already are using WiX with a custom Bootstrapper UI for our installer. I 
ended up integrating the updater logic there as well so that we could ensure 
that users always had the latest package before installation. Then I started 
wondering whether or not I could just use the Bootstrapper UI post installation 
as my updater application instead. I could just pass in various command line 
arguments to accomplish the flow that I wanted. The big problem is that there 
is a circular dependency. The Bootstrapper bundle needs the final MSI and the 
updater needs to be included in the MSI to ensure that it is installed with the 
application.

So I have a few questions that I haven't found any definitive answers to:

1) Is it possible to install the executing Bootstrapper application into the 
application's folder? Is there some variable exposed? (This is probably a long 
shot since the MSI knows nothing of the Bootstrapper)

2) Is it possible or in the works to externalize a MSI package in a bundle 
chain? Can I use the DownloadUrl property or somehow hook into a Boostrapper 
engine event that allows me to download the MSI package for the bundle at run 
time (The DetectUpdateBegin event comes to mind).

3) Is it possible to create a fake bundle with a fake MSI that can be used 
to just build the Bootstrapper application? Then, would I able to ignore the 
bundle completely and use an event like DetectUpdateBegin to force the 
Bootstrapper application to install a package not listed in the bundle?

I want to get these questions answered to determine whether or not it's worth 
it going down this rabbit hole. Thanks in advance!



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596581.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

2014-08-27 Thread Thomas Due
Oh, okay, so if I do not wish to use the RemotePayload (due to the Hash 
requirements) I just need the prereqs for building? 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210 
Johann Gutenbergs vej 5-9, Aarhus N, Denmark 
t...@scanvaegt.dk | www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: 27. august 2014 16:11
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

The bundle build process requires them on disk or you can satisfy this with the 
RemotePayload. If you specify a DownloadURL, you don't need to distribute the 
payload with your bundle.  It will download them if and only if the payload is 
needed. 

 

-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk] 
Sent: Wednesday, August 27, 2014 7:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

Hello, 

I have recently had an epiphany regarding Burn, and have been busy writing a 
bundle for our installer package. 
Now, we have several prerequisites that needs to be installed before our own 
installer is executed. 

The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the 
NetFxExtension, but how about Windows Installer 4.5?
SharedManagementObjects?
Sql Server 2012 Express?

I realize that I can download all these and add them compressed or uncompressed 
directly to my bundle, but what if I do not want to redistribute these myself, 
but rather just add a download link, just like the NetFx45Web package. 

Alternatively how can I define the redists in my bundle but not include them 
directly in the build? But rather package them when we deploy? 

This way I would be able to package two different deployment packages, one for 
32-bit and one for 64-bit. 

I have found direct links for the Sql Server Express 2012, thanks to Scott 
Hanselman here: http://downloadsqlserverexpress.com/
But I cannot figure out how to include them in my bundle for downloading, but 
not having them physically present. 

I have this:

ExePackage Id=SqlExpress86
PerMachine=yes
Permanent=yes
Name=SQLEXPRWT_x86_ENU.exe
Compressed=no
Cache=no

DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe;
DetectCondition=InstallSQL AND (NOT VersionNT64)/

It seems I need to include a RemotePayload, which requires all sorts of 
information regarding public keys etc. that I don't have. 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210
Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | 
www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: wix-users-requ...@lists.sourceforge.net 
[mailto:wix-users-requ...@lists.sourceforge.net]
Sent: 27. august 2014 04:58
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 99, Issue 59

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
wix-users-requ...@lists.sourceforge.net

You can reach the person managing the list at
wix-users-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific than Re: 
Contents of WiX-users digest...

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

2014-08-27 Thread Rob Mensching
Yes, because the build process is going to get the hash.

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

-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk] 
Sent: Wednesday, August 27, 2014 11:49 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

Oh, okay, so if I do not wish to use the RemotePayload (due to the Hash 
requirements) I just need the prereqs for building? 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210
Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | 
www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 27. august 2014 16:11
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

The bundle build process requires them on disk or you can satisfy this with the 
RemotePayload. If you specify a DownloadURL, you don't need to distribute the 
payload with your bundle.  It will download them if and only if the payload is 
needed. 

 

-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk]
Sent: Wednesday, August 27, 2014 7:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)

Hello, 

I have recently had an epiphany regarding Burn, and have been busy writing a 
bundle for our installer package. 
Now, we have several prerequisites that needs to be installed before our own 
installer is executed. 

The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the 
NetFxExtension, but how about Windows Installer 4.5?
SharedManagementObjects?
Sql Server 2012 Express?

I realize that I can download all these and add them compressed or uncompressed 
directly to my bundle, but what if I do not want to redistribute these myself, 
but rather just add a download link, just like the NetFx45Web package. 

Alternatively how can I define the redists in my bundle but not include them 
directly in the build? But rather package them when we deploy? 

This way I would be able to package two different deployment packages, one for 
32-bit and one for 64-bit. 

I have found direct links for the Sql Server Express 2012, thanks to Scott 
Hanselman here: http://downloadsqlserverexpress.com/
But I cannot figure out how to include them in my bundle for downloading, but 
not having them physically present. 

I have this:

ExePackage Id=SqlExpress86
PerMachine=yes
Permanent=yes
Name=SQLEXPRWT_x86_ENU.exe
Compressed=no
Cache=no

DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe;
DetectCondition=InstallSQL AND (NOT VersionNT64)/

It seems I need to include a RemotePayload, which requires all sorts of 
information regarding public keys etc. that I don't have. 


Med venlig hilsen / Best regards,
Thomas Due  - Software Developer
Tel: +45 8678 5500 Fax: +45 8678 5210
Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | 
www.scanvaegt.dk 


This e-mail and its attachments are intended for the named addressee only and 
may contain information that is confidential and privileged. Unauthorized use 
can instigate a claim for damages and constitute a criminal offence. If you 
received this in error, please contact the sender and delete the material. 


-Original Message-
From: wix-users-requ...@lists.sourceforge.net 
[mailto:wix-users-requ...@lists.sourceforge.net]
Sent: 27. august 2014 04:58
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 99, Issue 59

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
wix-users-requ...@lists.sourceforge.net

You can reach the person managing the list at
wix-users-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific than Re: 
Contents of WiX-users digest...

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___

Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread gregbty
Thanks for the quick response! So essentially I will need to:

1) Create a wrapper for butil (if you have an example that would be great)
2) Install the wrapper with my application
3) Add the WixBundleProviderKey to my application so that I can save the
value to use with the wrapper later

This will allow me to call to the wrapper with the key and basically open
the Bootstrapper as an updater. From there I can do all the necessary leg
work in the OnDetectUpdateBegin event, etc to download and install the
appropriate update, if there is one of course. Is that correct? Is this part
of the WiX 3.9 RC?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596579p7596589.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread Hoover, Jacob
1) I needed a wrapper because my application is not written in C. This is the 
only semi fragile part of the setup, as the internals of how the bundle info is 
stored could change over time (low likelihood, but it is possible). You need to 
remember to recompile your wrapper DLL any time you update the version of Wix 
you are using for your Bundle (Rob/Wix didn't want to have to maintain another 
helper DLL).

// WixUtil.cpp
#include stdafx.h
#include WixUtil.h

#pragma comment(lib, dutil.lib)

HRESULT DAPI WixBundleGetBundleInfo(
  __in LPCWSTR   szBundleId, // Bundle code
  __in LPCWSTR   szAttribute,// attribute name
  __out_ecount_opt(*pcchValueBuf) LPWSTR lpValueBuf, // returned value, 
NULL if not desired
  __inout_opt LPDWORD pcchValueBuf   // in/out buffer 
character count
)
{
return BundleGetBundleInfo(szBundleId, szAttribute, lpValueBuf, 
pcchValueBuf);
}

HRESULT DAPI WixBundleEnumRelatedBundle(
  __in LPCWSTR lpUpgradeCode,
  __in BUNDLE_INSTALL_CONTEXT context,
  __inout  PDWORD pdwStartIndex,
  __out_ecount(MAX_GUID_CHARS+1)  LPWSTR lpBundleIdBuf
)
{
return BundleEnumRelatedBundle(lpUpgradeCode, context, pdwStartIndex, 
lpBundleIdBuf);
}

2) Yes, and write code in the application for the querying and invoking of the 
bundle.
3) One could, though I just looked and in my use case I hard coded the upgrade 
code.

I implemented a custom switch to my the BA, so that I could customize the user 
experience. (Display minimal/no UI while checking, display full UI if update is 
found, auto close the bundle if no update is found, etc.) The updates have been 
in Wix for some time, the 3.9 RC has my changes for allowing the engine to 
download and parse the atom feed instead of having to do it from within your BA.

-Original Message-
From: gregbty [mailto:greg.bea...@gmail.com] 
Sent: Wednesday, August 27, 2014 2:08 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

Thanks for the quick response! So essentially I will need to:

1) Create a wrapper for butil (if you have an example that would be great)
2) Install the wrapper with my application
3) Add the WixBundleProviderKey to my application so that I can save the value 
to use with the wrapper later

This will allow me to call to the wrapper with the key and basically open the 
Bootstrapper as an updater. From there I can do all the necessary leg work in 
the OnDetectUpdateBegin event, etc to download and install the appropriate 
update, if there is one of course. Is that correct? Is this part of the WiX 3.9 
RC?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596579p7596589.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread Asbjørn Mikkelsen
So what would be an good startingpoint?, since this is not very good
documentet, some good startingpoints would be very nice.. As of now, wixba
will be an starting point.. :)


On Wed, Aug 27, 2014 at 5:07 PM, Rob Mensching r...@firegiant.com wrote:

 Sounds like you are getting snapshots of the source code from GitHub.
 Usually, if you want the source code I'd say just use git to clone the repo.

 The WixBA also isn't designed to be a starting point. It's good as a
 reference codebase but the source code certainly isn't packaged up as a
 starter kit.

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

 -Original Message-
 From: linos [mailto:lino...@hotmail.com]
 Sent: Wednesday, August 27, 2014 5:49 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Cannot view RootView.xaml file in visual studio
 2010

 Hi Rob,

 My mistake.  I should have been more descriptive with my wix.zip
 reference.
 I was referring to the wix-16a8b5dbf828f92e28138ce3c9ee852affeaa1ef.zip.

 Just curious, since I have you attention, but what is the preferred method
 to using the existing wixBA?
 Is it first creating a new solution in visual studio then adding the wixBA
 and core projects? Or what I mentioned above in my previous post in order
 to get things to work?  I would like to prevent others from having this bad
 experience.

 Thanks,
 Lino



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-view-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596570.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
mvh
Asbjørn
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread gregbty
One last question (hopefully):

1) Can I pass any additional command line parameters? (From what I read, it
looks like you pass in the checkupdate switch automatically)



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596579p7596592.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

2014-08-27 Thread Hoover, Jacob
All the dutil wrapper is doing you is getting access to the location of the 
bundle and it's properties.  It's up to your code inside your application to 
invoke the bundle (so you have full control over the parameters). 

-Original Message-
From: gregbty [mailto:greg.bea...@gmail.com] 
Sent: Wednesday, August 27, 2014 3:39 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Updater application using Bootstrapper UI/Bundle

One last question (hopefully):

1) Can I pass any additional command line parameters? (From what I read, it 
looks like you pass in the checkupdate switch automatically)



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-tp7596579p7596592.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

2014-08-27 Thread Rob Mensching
It's a reasonable reference. No one has yet contributed a project template for 
creating your own Custom BA, yet.

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

-Original Message-
From: Asbjørn Mikkelsen [mailto:asbj...@neslekkim.net] 
Sent: Wednesday, August 27, 2014 12:36 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Cannot view RootView.xaml file in visual studio 2010

So what would be an good startingpoint?, since this is not very good 
documentet, some good startingpoints would be very nice.. As of now, wixba will 
be an starting point.. :)


On Wed, Aug 27, 2014 at 5:07 PM, Rob Mensching r...@firegiant.com wrote:

 Sounds like you are getting snapshots of the source code from GitHub.
 Usually, if you want the source code I'd say just use git to clone the repo.

 The WixBA also isn't designed to be a starting point. It's good as a 
 reference codebase but the source code certainly isn't packaged up as 
 a starter kit.

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

 -Original Message-
 From: linos [mailto:lino...@hotmail.com]
 Sent: Wednesday, August 27, 2014 5:49 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Cannot view RootView.xaml file in visual 
 studio
 2010

 Hi Rob,

 My mistake.  I should have been more descriptive with my wix.zip
 reference.
 I was referring to the wix-16a8b5dbf828f92e28138ce3c9ee852affeaa1ef.zip.

 Just curious, since I have you attention, but what is the preferred 
 method to using the existing wixBA?
 Is it first creating a new solution in visual studio then adding the 
 wixBA and core projects? Or what I mentioned above in my previous post 
 in order to get things to work?  I would like to prevent others from 
 having this bad experience.

 Thanks,
 Lino



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-v
 iew-RootView-xaml-file-in-visual-studio-2010-tp7596500p7596570.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
mvh
Asbjørn
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Burn to MSI -- Secure password -- Best Parctice

2014-08-27 Thread Sean Hall
Make sure that your mba uses the SecureStringVariables property in the
Engine class, which requires that your password is in a SecureString.  You
shouldn't put the password in a System.String.


On Wed, Aug 27, 2014 at 11:55 AM, Phill Hogland phogl...@rimage.com wrote:

 Thanks Rob, very much.  I had the Bundle/@Variable hidden but missed the
 Product/@Property.  Thanks again.



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-to-MSI-Secure-password-Best-Parctice-tp7596576p7596578.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users