date:20140311

Regarding how to use the DifxExtension if you have the driver files, create a
msi which installs the drivers files to a cache location. (At that point
you, in general for any driver prior to using the DifxApi, you should be
able to right click on the INF file and see the driver successfully install.
If you can't accomplish that step there is no point in authoring the DifxExt
yet IMO.) Also for my drivers which support both x86 and x64, I structured
the msi to be build twice in either configuration, installing all files,
because of signing, to either the appropriate programfiles tree. Then add
the DifxExt schema to the wxs file which contains the INF file component,
and add the difx:Driver element to the component which has the INF file.
(I'm sure there may be other approaches.)
http://www.codeproject.com/Articles/44191/Drivers-Installation-With-WiX

Regarding the printer driver and configuring for 'print-to-file', I am
working on a similar requirement. I found that I could not use the
DifxExtension for this purpose. I will later also work on a project that
requires the printer driver to be installed for PNP connection of of the
printer device, and based on preliminary testing I think the DifxApp
extension may work in that situation. I have three different printer
drivers (six platform variants), which I deliver as part of my suite. For
this project each is configured for 'print-to-file'. One of the drivers is
based on an HP engine (and includes the HP driver). Yes you could implement
a CA to call the AddPrinter, and related Print Spooler api functions which
you will also need. (I created a setup application used in a non-wix
process some time ago which takes that approach.) However the approach I
have settled on is to call the PrintUI dll.
http://technet.microsoft.com/en-us/library/ee624057.aspx

Both AddPrinter (and related functions) and the PrintUI dll docs warn that
the calls may bock, but I decided that using PrintUI which is well tested,
is more reliable than me rolling my own setup application and maintaining
changes over time. I am working on an extension which is not ready to be
submitted back to the community yet, but I know that this approach can be
achieved. (I originally implemented the approach as a custom table driven
CA, while I also worked on issues getting even sample extension code to
compile.)

When I tried to first call Difxapp Extension and then call PrintUI in the
same Component/msi, it always fails. I had to abandon calling DifxAPP
(Ext). While DifxAPP is the recommended approach in many situations, it is
not intended to be used in some scenarios. In an earlier non-wix setup I
have called DifxAPI to put the driver in the Driver Store and then PrintUI
to install the driver and configure as 'print-to-file' which has been a
reliable approach for years. There also in a non-msi setup, the DifxAPP was
not useful. I have not implemented anything to call DifxApi in wix yet, but
I plan too. All of my drivers are fully signed PNP drivers which have been
deployed for years (and are not open for changes related to this wix
project).

Additional reading:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-problem-with-printer-driver-installation-td7591538.html

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-HP-LaserJet-4-Printer-Driver-on-FILE-instead-of-LPT1-tp7593244p7593283.html
Sent from the wix-users mailing list archive at Nabble.com.

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

Re: [WiX-users] Installing HP LaserJet 4 Printer Driver on FILE instead of LPT1

Here are the PrintUI commands that I use.  I would test your parameters on a
target machine in a admin CMD box prior to integrating into a msi.
LPWSTR pwzAddPrinterCommand = L\%lsRunDll32.exe\
PrintUI.dll,PrintUIEntry /if /b \%ls\ /f \%ls\ /r %ls /m \%ls\ /u /q
/z /Gw;
LPWSTR pwzDelPrinterCommand = L\%lsRunDll32.exe\
PrintUI.dll,PrintUIEntry /dl /n \%ls\ /q /Gw;
LPWSTR pwzDelDriverCommand = L\%lsRunDll32.exe\ 
PrintUI.dll,PrintUIEntry
/dd /m \%ls\ /q /Gw;


Snippet of deferred CA code that uses the above commands.  While this is
working the driver is not in the driver store and I have yet to work on a
DifxApi solution.  There is other refactoring that I am in the process of
doing to extension project.
switch (iOperation)
{
case WCA_TODO_INSTALL:
case WCA_TODO_REINSTALL:
fDoQuietExec = true;
hr = RegOpen(HKEY_LOCAL_MACHINE, pwzPrinterKey, 
KEY_QUERY_VALUE,
hkPrinter);
if (ERROR_SUCCESS == hr) {
/*If the printer exsts, skip calling the 
'install' command on PrintUI
api to avoid creating another printer*/
WcaLog(LOGMSG_VERBOSE, Printer exists, so skip 
calling install
action.\nPrinter Key: %ls\n, pwzPrinterKey);
fDoQuietExec = false;
break;
}

if (true == fDoQuietExec) {
hr = StrAllocFormatted(pwzCommand, 
pwzAddPrinterCommand, pwzSystemPath,
pwzModel, pwzInfPath, pwzPort, pwzName);
ExitOnFailure(hr, failed to format the command 
to install a printer);

hr = QuietExec(pwzCommand, dwTimeout);
ExitOnFailure1(hr, QuietExec failed to execute 
install command, %ls,
and may have timed out., pwzCommand);
}
break;
case WCA_TODO_UNINSTALL:
//uninstalling so look for printers with names which 
include our printer
name.  Typically 'printer name (Copy 1)'
hr = RegOpen(HKEY_LOCAL_MACHINE, pwzPrintersKey, 
KEY_READ, hkPrinters);
ExitOnFailure1(hr, Failed to open the Windows Printers 
key: %ls, ,
pwzPrintersKey);

for (DWORD dwIndex = 0; /* exit via break below */; 
++dwIndex)
{
ReleaseNullStr(pwzPrinterObject);
hr = RegKeyEnum(hkPrinters, dwIndex, 
pwzPrinterObject);
if (E_NOMOREITEMS == hr)
{
hr = S_OK;
break;
}
ExitOnFailure(hr, Failed to enumerate printer 
objects.);

if (NULL == wcsistr(pwzPrinterObject, pwzName)) 
{
//WcaLog(LOGMSG_VERBOSE, RegKeyEnum 
returned %ls, which is not of any
interest to us.  Look for another printer., pwzPrinterObject);
continue;
}

//create a list of printers with similar name, 
to remove later
hr = WcaWriteStringToCaData(pwzPrinterObject, 
pwzRelatedPrinters);
ExitOnFailure2(hr, failed to add printer ( %ls 
) to the list: %ls,
pwzPrinterObject, pwzId);

cPrinters++;
}

ReleaseNullStr(pwz);
pwz = pwzRelatedPrinters;
while (pwz  *pwz)
{
ReleaseNullStr(pwzPrinterObject);
hr = WcaReadStringFromCaData(pwz, 
pwzPrinterObject);
ExitOnFailure(hr, failed to read related 
printer name from related
printer list.);

//remove this printer
ReleaseNullStr(pwzCommand);
hr = StrAllocFormatted(pwzCommand, 
pwzDelPrinterCommand, pwzSystemPath,
pwzPrinterObject);
ExitOnFailure(hr, failed to format the command 
to remove a printer);

hr = QuietExec(pwzCommand, dwTimeout);
ExitOnFailure1(hr, QuietExec failed to execute 
uninstall printer
command, %ls, and may have timed out., pwzCommand);

// Tick the progress bar along
hr = WcaProgressMessage(COST_RDPPRINTERS, 
FALSE);
ExitOnFailure1(hr, failed to tick progress bar 
for printer instance:
%ls, pwzId);
}

Re: [WiX-users] ICE03 or Unresolved reference

Those Merge Modules have NEVER WORKED CORRECTLY.  I can't even get  
those to work in VS2005.  I have an app still on .NET 2.0.  If you  
complain on the SAP Forums, SAP states that the tool we use  
internally to compile them passes validadation, but they never tell  
you what that tool is...  As such the recommended course of action is  
to download CR2008 Runtimes SP5 for VS =2008 or the new plugin  
architecture for =VS2010.  If you could figure out how to fix these,  
I sure would appreciate it...

Carter

Quoting John Ludlow john.ludlow...@gmail.com:

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

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

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

 Hi All

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

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

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

 AdvertiseExecuteSequence
   MsiPublishAssemblies Sequence=1502 /
 /AdvertiseExecuteSequence

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

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


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

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

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

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

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

 Could someone help me with this please?

 The msm module I took from here:

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


 Thanks everyone.

 Dmitry Nechaev

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

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

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






--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their

Re: [WiX-users] Installing HP LaserJet 4 Printer Driver on FILE instead of LPT1

2014-03-11 Thread Arthur, Christopher

Thx, will give it a try,...

Christopher Arthur


-Ursprüngliche Nachricht-
Von: Phill Hogland [mailto:phogl...@rimage.com]
Gesendet: Dienstag, 11. März 2014 13:37
An: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] Installing HP LaserJet 4 Printer Driver on FILE 
instead of LPT1

Here are the PrintUI commands that I use.  I would test your parameters on a 
target machine in a admin CMD box prior to integrating into a msi.
LPWSTR pwzAddPrinterCommand = L\%lsRunDll32.exe\
PrintUI.dll,PrintUIEntry /if /b \%ls\ /f \%ls\ /r %ls /m \%ls\ /u /q /z 
/Gw;
LPWSTR pwzDelPrinterCommand = L\%lsRunDll32.exe\
PrintUI.dll,PrintUIEntry /dl /n \%ls\ /q /Gw;
LPWSTR pwzDelDriverCommand = L\%lsRunDll32.exe\ 
PrintUI.dll,PrintUIEntry /dd /m \%ls\ /q /Gw;


Snippet of deferred CA code that uses the above commands.  While this is 
working the driver is not in the driver store and I have yet to work on a 
DifxApi solution.  There is other refactoring that I am in the process of doing 
to extension project.
switch (iOperation)
{
case WCA_TODO_INSTALL:
case WCA_TODO_REINSTALL:
fDoQuietExec = true;
hr = RegOpen(HKEY_LOCAL_MACHINE, pwzPrinterKey, 
KEY_QUERY_VALUE, hkPrinter);
if (ERROR_SUCCESS == hr) {
/*If the printer exsts, skip calling the 
'install' command on PrintUI api to avoid creating another printer*/
WcaLog(LOGMSG_VERBOSE, Printer exists, so skip 
calling install action.\nPrinter Key: %ls\n, pwzPrinterKey);
fDoQuietExec = false;
break;
}

if (true == fDoQuietExec) {
hr = StrAllocFormatted(pwzCommand, 
pwzAddPrinterCommand, pwzSystemPath, pwzModel, pwzInfPath, pwzPort, pwzName);
ExitOnFailure(hr, failed to format the command 
to install a printer);

hr = QuietExec(pwzCommand, dwTimeout);
ExitOnFailure1(hr, QuietExec failed to execute 
install command, %ls, and may have timed out., pwzCommand);
}
break;
case WCA_TODO_UNINSTALL:
//uninstalling so look for printers with names which 
include our printer name.  Typically 'printer name (Copy 1)'
hr = RegOpen(HKEY_LOCAL_MACHINE, pwzPrintersKey, 
KEY_READ, hkPrinters);
ExitOnFailure1(hr, Failed to open the Windows Printers 
key: %ls, , pwzPrintersKey);

for (DWORD dwIndex = 0; /* exit via break below */; 
++dwIndex)
{
ReleaseNullStr(pwzPrinterObject);
hr = RegKeyEnum(hkPrinters, dwIndex, 
pwzPrinterObject);
if (E_NOMOREITEMS == hr)
{
hr = S_OK;
break;
}
ExitOnFailure(hr, Failed to enumerate printer 
objects.);

if (NULL == wcsistr(pwzPrinterObject, pwzName)) 
{
//WcaLog(LOGMSG_VERBOSE, RegKeyEnum 
returned %ls, which is not of any interest to us.  Look for another printer., 
pwzPrinterObject);
continue;
}

//create a list of printers with similar name, 
to remove later
hr = WcaWriteStringToCaData(pwzPrinterObject, 
pwzRelatedPrinters);
ExitOnFailure2(hr, failed to add printer ( %ls 
) to the list: %ls, pwzPrinterObject, pwzId);

cPrinters++;
}

ReleaseNullStr(pwz);
pwz = pwzRelatedPrinters;
while (pwz  *pwz)
{
ReleaseNullStr(pwzPrinterObject);
hr = WcaReadStringFromCaData(pwz, 
pwzPrinterObject);
ExitOnFailure(hr, failed to read related 
printer name from related printer list.);

//remove this printer
ReleaseNullStr(pwzCommand);
hr = StrAllocFormatted(pwzCommand, 
pwzDelPrinterCommand, pwzSystemPath, pwzPrinterObject);
ExitOnFailure(hr, failed to format the command 
to remove a printer);

hr = QuietExec(pwzCommand, dwTimeout);
ExitOnFailure1(hr, QuietExec failed to execute 
uninstall printer command, %ls, and may have timed out.,

Re: [WiX-users] How to do in wix v3.8 what setupbld.exe did

On 07-Mar-14 05:45, Dan Watson wrote:
 1) I understand the power of Bootstrapper project in bundling multiple MSI 
 setups (the Office installation being a good example) but is there an 
 equivalent of Burn command that would package my MSI setup as setupbld.exe 
 did with a command switches?
No. Bundles are built like everything else in WiX, by compiling and linking.

 2) If I use a Bootstrapper project,  does it mean that I need to move my 
 existing UI in the MSI installer to the Bootstrapper?
In general, that's the best user experience. It's possible to use 
MsiPackage/@DisplayInternalUI but it has limitations and ends up with 
two UIs (the bundle and the .msi).

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


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

Re: [WiX-users] WixExtension: how to use a messages.xml file

On 27-Feb-14 14:45, Phill Hogland wrote:
 Is there a way to display an Information message to the Output window,
 without having to set the 'Verbose' property and without it being either an
 Error or a Warning.
I don't think so. The info logging level doesn't really exist.

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


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

Re: [WiX-users] ICE03 or Unresolved reference

On 10-Mar-14 22:12, Dmitry Nechaev wrote:
 There is no way for me to fix ICE03 error for this MSM using InsureTable for 
 the last dozen of tables commented out in the code above.
WiX doesn't know what those tables are so it can't create them. If the 
merge modules are fundamentally broken, you can suppress ICE03.

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


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

Re: [WiX-users] Require fields/disable InstallButton in bootstrapper

On 07-Mar-14 14:02, Joel Dart wrote:
 ... but I cannot figure out how to set ButtonNameState based on a different 
 variable or how to reevaluate such a condition.
You could use BA functions in WiX v3.8 and later but that would only let 
you set the variables once, as part of planning. WixStdBA doesn't have 
custom actions that run during the UI itself.

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


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

Re: [WiX-users] Bundle Command line not passed to second MSI package

On 08-Mar-14 17:04, Phill Hogland wrote:
 I have a bundle with an mba and several nearly identical MsiPackages (which
 install various printer drivers).  So except for a different path to the msi
 the bundle MsiPackage authoring is identical for each driver package.  The
 thing that I noticed is that when I set LOGVERBOSE on the command line of
 the bundle, I can see in the mba's InstallViewModel in
 ExecutePackageComplete that for each MsiPackage the
 sender.base.Command.wzCommandLine includes LOGVERBOSE (or whatever command
 line parameter I handed to my bundle.)
The Command object applies to the whole bundle; it's not 
package-specific. Burn automatically requests verbose logging but uses 
the MSI API to do so. LOGVERBOSE is a property used by WiX custom 
actions to determine whether they should log verbose messages. See 
http://www.joyofsetup.com/2008/07/15/verbose-logging-from-wcautil/.

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


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

Re: [WiX-users] Bundle Command line not passed to second MSI package

I could tell that the Command object was a single bundle instance. I had
read somewhere that a mba needed to implement passing those values to a Msi
and I was trying to find where to add code to add the values to the msiexec
command line. In my chain I have a mixture of my MSIs and third-party MSI
(and EXEs). I eventually concluded that for my MSIs I need to pass the
infor into MsiProperty and use that to trigger in the Msi that I authored a
SetProperty on the MsiLogging (for one example, there are others). I
basically have that working, although I am still testing certain scenarios.
I was trying to to turn on verbose logging (*v and not LOGVERBOSE as
indicated earlier) in certain packages and not in others based on burn
command-line/mba behavior. I have simplified that effort some as I tend to
make a problem more complicated than is really necessary smile/ (This is
also true of MSIFASTINSTALL and of 'enabling' WIXFAILWHENDEFERRED in one of
several packages, selected at run-time by the tester.)

Thanks for the feedback Bob.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Bundle-Command-line-not-passed-to-second-MSI-package-tp7593291p7593293.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] Call Web Service in CustomAction method

2014-03-11 Thread DiegoS

I need to call an existing Web Service in al Custom Action method when the
Application is Unistalled.
I have my Custom Action Method where i have a reference to my webservice
like this
*using CheckPID.WCFReference;*

* [CustomAction]
public static ActionResult CheckPID(Session session)
{
WebServiceClient webServiceBitClient = new WebServiceClient();
return ActionResult.Success;
}
*
It through an error in txt file
*MainEngineThread is returning 1603*

How must I make a web Service call?
thanks



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Call-Web-Service-in-CustomAction-method-tp7593295.html
Sent from the wix-users mailing list archive at Nabble.com.

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

[WiX-users] Conditional SSPI / SQL Authentication on SqlScript

2014-03-11 Thread Levi Wilson

I have a component that has multiple SqlScript / elements. In my dialog
sequence  I allow the user to choose whether or not they want to use SQL or
Windows Authentication for the connection.

Each SqlScript / references my SqlDatabase / that currently looks like
this:

util:User Id='SqlInstallerUserId'
  Name='[SQL_ADMIN_USERNAME]'
  Password='[SQL_ADMIN_PASSWORD]' /

sql:SqlDatabase Id=CompassFrameworkDatabase
  Server=[SQL_SERVER] Database=[SQL_DATABASE]
  User=SqlInstallerUserId /

The problem is that will never work with Windows Authentication :-)

I've seen some have two different components that specified different
SqlDatabase / elements, but I would rather not do that.

Is there a way to basically clear the User_ record in the
SqlDatabase table in the MSI to force it to use Windows Authentication
depending on what the user chose in the dialog?

Thanks in advance.

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

Re: [WiX-users] Conditional SSPI / SQL Authentication on SqlScript

2014-03-11 Thread John Cooper

Yes.  In your case, if SQL_ADMIN_USERNAME and SQL_ADMIN_PASSWORD both evaluate 
to empty-string, then the sql:SqlDatabase will deploy with Windows 
Authentication.

I use this pattern all the time.

--
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: Tuesday, March 11, 2014 10:33 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditional SSPI / SQL Authentication on SqlScript

I have a component that has multiple SqlScript / elements. In my dialog 
sequence  I allow the user to choose whether or not they want to use SQL or 
Windows Authentication for the connection.

Each SqlScript / references my SqlDatabase / that currently looks like
this:

util:User Id='SqlInstallerUserId'
  Name='[SQL_ADMIN_USERNAME]'
  Password='[SQL_ADMIN_PASSWORD]' /

sql:SqlDatabase Id=CompassFrameworkDatabase
  Server=[SQL_SERVER] Database=[SQL_DATABASE]
  User=SqlInstallerUserId /

The problem is that will never work with Windows Authentication :-)

I've seen some have two different components that specified different 
SqlDatabase / elements, but I would rather not do that.

Is there a way to basically clear the User_ record in the SqlDatabase table 
in the MSI to force it to use Windows Authentication depending on what the user 
chose in the dialog?

Thanks in advance.

Levi
--
Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the 
definitive new guide to graph databases and their applications. Written by 
three acclaimed leaders in the field, this first edition is now available. 
Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


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

Re: [WiX-users] Conditional SSPI / SQL Authentication on SqlScript

I know you probably don't want to hear this, but I've Seen:

Condition 1Server Authentication AND NOT  
WindowsAuthentication/Condition 1
Condition 2Windows Authentication AND NOT  
ServerAuthentication/Condition 2

then Choose A condition based on what the user chose in your setup  
dialog, ie condition 1 is what you've described and condition 2 is  
Windows Authentication.

Carter

Quoting Levi Wilson l...@leviwilson.com:

 I have a component that has multiple SqlScript / elements. In my dialog
 sequence  I allow the user to choose whether or not they want to use SQL or
 Windows Authentication for the connection.

 Each SqlScript / references my SqlDatabase / that currently looks like
 this:

 util:User Id='SqlInstallerUserId'
   Name='[SQL_ADMIN_USERNAME]'
   Password='[SQL_ADMIN_PASSWORD]' /

 sql:SqlDatabase Id=CompassFrameworkDatabase
   Server=[SQL_SERVER] Database=[SQL_DATABASE]
   User=SqlInstallerUserId /

 The problem is that will never work with Windows Authentication :-)

 I've seen some have two different components that specified different
 SqlDatabase / elements, but I would rather not do that.

 Is there a way to basically clear the User_ record in the
 SqlDatabase table in the MSI to force it to use Windows Authentication
 depending on what the user chose in the dialog?

 Thanks in advance.

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






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

Re: [WiX-users] Generating a unique file name

2014-03-11 Thread Hoover, Jacob

Taking a step back, I would have to ask why you are needing to make a copy of a 
file with a random name. If it's a user modified file, then an upgrade 
shouldn't touch it. 

-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net] 
Sent: Monday, March 10, 2014 8:58 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name

Hi Harold,

Then we're back to doing a custom action, though, which means I can do anything 
I want, including calling GetTempFilePath() directly. :)

Cheers,
Soren

On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital)  
v-wow...@microsoft.com wrote:

 Set the name as a global property, generate the name in a custom 
 action, there you can use datetime.Tostring(HHmmss ) to format 
 it any way you like, then put the value back into the session object 
 where you can now use it any way you like.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 5:45 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Rob,

 As far as I can tell from the docs (
 http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx), 
 the format of the time might include a colon, such as 18:57:00, which 
 isn't a valid file name on Windows.

 Cheers,
 Soren

 On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com wrote:

  What about using [Time]?
  ___
   FireGiant  |  Dedicated support for the WiX toolset  | 
  http://www.firegiant.com/

  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 3:38 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name

   I don't know how you would go about Randomizing the Names, but as 
   long as the DestinationName contains a name different from the 
   SourceName the file name will be different after the copy completes.

  Yes, that's pretty much the point of DestinationName. :) What I'm 
  looking for, however, is a way to generate a unique temp file on the 
  fly without having to shell out to a custom action that does this 
  for me. The reason I want to do this is because I don't know what 
  other files could potentially exist in the directory, so I want to 
  just create a temporary unique file name similar to what 
  GetTempFilePath() (

  http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v
  =v
  s.85%29.aspx
  )
  does.

  It sounds like that might not be possible currently.

  Thanks though!

  On Mon, Mar 10, 2014 at 1:35 PM, Carter Young 
  ecyo...@grandecom.net
  wrote:

   I don't know how you would go about Randomizing the Names, but as 
   long as the DestinationName contains a name different from the 
   SourceName the file name will be different after the copy completes.

   Quote:
   SourceName:
   If this attribute is not specified (and this element is not nested 
   under a File element or specify a FileId attribute) then the 
   SourceProperty attribute should be set to the name of a property 
   that will resolve to the full path of the source filename. If the 
   value of this attribute contains a * wildcard and the 
   DestinationName attribute is specified, all moved or copied files 
   retain the file names from their sources.

   Quote:
   DestinationName:
   In prior versions of the WiX toolset, this attribute specified the 
   short file name. Now set this value to the localizable name to be 
   given to the original file after it is moved or copied. If this 
   attribute is not specified, then the destination file is given the 
   same name as the source file. If a short file name is specified, 
   the DestinationShortName attribute may not be specified. If a long 
   file name is specified, the DestinationLongName attribute may not 
   be specified. Also, if this value is a long file name, the 
   DestinationShortName attribute may be omitted to allow WiX to 
   attempt to generate a unique short file name. However, if this 
   name collides with another file or you wish to manually specify 
   the short file name, then the DestinationShortName attribute may be 
   specified.

   Quoting Soren Dreijer dreijer+l...@echobit.net:

Hey Carter,

That's not quite what I'm after (unless I'm misreading the docs).
I want the *destination* file name to be uniquely generated, and 
as far as I can tell from the docs, only a unique short name 
will be generated if one
   isn't
provided.

Cheers,
SOren

On Mon, Mar 10, 2014 at 11:28 AM, Carter Young 
   ecyo...@grandecom.net
   wrote:

I believe the SourceName Attribute is what you're looking for.

http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.
ht
ml

Carter

Re: [WiX-users] Generating a unique file name

Hey Jacob,

It's an app.config file that's part of the installation, so a major upgrade
will remove it and I'd like to make sure it's persisted so that I can
migrate it as part of the upgrade flow.

Cheers,
Soren


On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:

 Taking a step back, I would have to ask why you are needing to make a copy
 of a file with a random name. If it's a user modified file, then an upgrade
 shouldn't touch it.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 8:58 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Harold,

 Then we're back to doing a custom action, though, which means I can do
 anything I want, including calling GetTempFilePath() directly. :)

 Cheers,
 Soren


 On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
 v-wow...@microsoft.com wrote:

  Set the name as a global property, generate the name in a custom
  action, there you can use datetime.Tostring(HHmmss ) to format
  it any way you like, then put the value back into the session object
  where you can now use it any way you like.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 5:45 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Rob,
 
  As far as I can tell from the docs (
  http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
  the format of the time might include a colon, such as 18:57:00, which
  isn't a valid file name on Windows.
 
  Cheers,
  Soren
 
 
  On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
 wrote:
 
   What about using [Time]?
   ___
FireGiant  |  Dedicated support for the WiX toolset  |
   http://www.firegiant.com/
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 3:38 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
I don't know how you would go about Randomizing the Names, but as
long as the DestinationName contains a name different from the
SourceName the file name will be different after the copy completes.
  
   Yes, that's pretty much the point of DestinationName. :) What I'm
   looking for, however, is a way to generate a unique temp file on the
   fly without having to shell out to a custom action that does this
   for me. The reason I want to do this is because I don't know what
   other files could potentially exist in the directory, so I want to
   just create a temporary unique file name similar to what
   GetTempFilePath() (
  
   http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v
   =v
   s.85%29.aspx
   )
   does.
  
   It sounds like that might not be possible currently.
  
   Thanks though!
  
  
   On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
   ecyo...@grandecom.net
   wrote:
  
I don't know how you would go about Randomizing the Names, but as
long as the DestinationName contains a name different from the
SourceName the file name will be different after the copy completes.
   
Quote:
SourceName:
If this attribute is not specified (and this element is not nested
under a File element or specify a FileId attribute) then the
SourceProperty attribute should be set to the name of a property
that will resolve to the full path of the source filename. If the
value of this attribute contains a * wildcard and the
DestinationName attribute is specified, all moved or copied files
retain the file names from their sources.
   
Quote:
DestinationName:
In prior versions of the WiX toolset, this attribute specified the
short file name. Now set this value to the localizable name to be
given to the original file after it is moved or copied. If this
attribute is not specified, then the destination file is given the
same name as the source file. If a short file name is specified,
the DestinationShortName attribute may not be specified. If a long
file name is specified, the DestinationLongName attribute may not
be specified. Also, if this value is a long file name, the
DestinationShortName attribute may be omitted to allow WiX to
attempt to generate a unique short file name. However, if this
name collides with another file or you wish to manually specify
the short file name, then the DestinationShortName attribute may be
 specified.
   
   
   
Quoting Soren Dreijer dreijer+l...@echobit.net:
   
 Hey Carter,

 That's not quite what I'm after (unless I'm misreading the docs).
 I want the *destination* file name to be uniquely generated, and
 as far as I can tell from the docs, only a unique short name

Re: [WiX-users] Generating a unique file name

2014-03-11 Thread Harold Wood (H10 Capital)

Yes..ahh well

-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net] 
Sent: Monday, March 10, 2014 6:58 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name

Hi Harold,

Then we're back to doing a custom action, though, which means I can do anything 
I want, including calling GetTempFilePath() directly. :)

Cheers,
Soren

On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital)  
v-wow...@microsoft.com wrote:

 Set the name as a global property, generate the name in a custom 
 action, there you can use datetime.Tostring(HHmmss ) to format 
 it any way you like, then put the value back into the session object 
 where you can now use it any way you like.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 5:45 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Rob,

 As far as I can tell from the docs (
 http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx), 
 the format of the time might include a colon, such as 18:57:00, which 
 isn't a valid file name on Windows.

 Cheers,
 Soren

 On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com wrote:

  What about using [Time]?
  ___
   FireGiant  |  Dedicated support for the WiX toolset  | 
  http://www.firegiant.com/

  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 3:38 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name

   I don't know how you would go about Randomizing the Names, but as 
   long as the DestinationName contains a name different from the 
   SourceName the file name will be different after the copy completes.

  Yes, that's pretty much the point of DestinationName. :) What I'm 
  looking for, however, is a way to generate a unique temp file on the 
  fly without having to shell out to a custom action that does this 
  for me. The reason I want to do this is because I don't know what 
  other files could potentially exist in the directory, so I want to 
  just create a temporary unique file name similar to what 
  GetTempFilePath() (

  http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v
  =v
  s.85%29.aspx
  )
  does.

  It sounds like that might not be possible currently.

  Thanks though!

  On Mon, Mar 10, 2014 at 1:35 PM, Carter Young 
  ecyo...@grandecom.net
  wrote:

   I don't know how you would go about Randomizing the Names, but as 
   long as the DestinationName contains a name different from the 
   SourceName the file name will be different after the copy completes.

   Quote:
   SourceName:
   If this attribute is not specified (and this element is not nested 
   under a File element or specify a FileId attribute) then the 
   SourceProperty attribute should be set to the name of a property 
   that will resolve to the full path of the source filename. If the 
   value of this attribute contains a * wildcard and the 
   DestinationName attribute is specified, all moved or copied files 
   retain the file names from their sources.

   Quote:
   DestinationName:
   In prior versions of the WiX toolset, this attribute specified the 
   short file name. Now set this value to the localizable name to be 
   given to the original file after it is moved or copied. If this 
   attribute is not specified, then the destination file is given the 
   same name as the source file. If a short file name is specified, 
   the DestinationShortName attribute may not be specified. If a long 
   file name is specified, the DestinationLongName attribute may not 
   be specified. Also, if this value is a long file name, the 
   DestinationShortName attribute may be omitted to allow WiX to 
   attempt to generate a unique short file name. However, if this 
   name collides with another file or you wish to manually specify 
   the short file name, then the DestinationShortName attribute may be 
   specified.

   Quoting Soren Dreijer dreijer+l...@echobit.net:

Hey Carter,

That's not quite what I'm after (unless I'm misreading the docs).
I want the *destination* file name to be uniquely generated, and 
as far as I can tell from the docs, only a unique short name 
will be generated if one
   isn't
provided.

Cheers,
SOren

On Mon, Mar 10, 2014 at 11:28 AM, Carter Young 
   ecyo...@grandecom.net
   wrote:

I believe the SourceName Attribute is what you're looking for.

http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.
ht
ml

Carter

   --
   --
   --
    Learn Graph Databases - Download FREE O'Reilly Book 
   Graph Databases is the

Re: [WiX-users] Generating a unique file name

2014-03-11 Thread Hoover, Jacob

But if it hasn't been modified then you already know what is in it.  If a user 
manually modifies the file, then a major upgrade should not remove it. If it 
was modified with XmlFile CA's or the likes, were the original user choices 
persisted in the registry?

-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net] 
Sent: Tuesday, March 11, 2014 12:12 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name

Hey Jacob,

It's an app.config file that's part of the installation, so a major upgrade 
will remove it and I'd like to make sure it's persisted so that I can migrate 
it as part of the upgrade flow.

Cheers,
Soren

On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:

 Taking a step back, I would have to ask why you are needing to make a 
 copy of a file with a random name. If it's a user modified file, then 
 an upgrade shouldn't touch it.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 8:58 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Harold,

 Then we're back to doing a custom action, though, which means I can do 
 anything I want, including calling GetTempFilePath() directly. :)

 Cheers,
 Soren

 On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital)  
 v-wow...@microsoft.com wrote:

  Set the name as a global property, generate the name in a custom 
  action, there you can use datetime.Tostring(HHmmss ) to format 
  it any way you like, then put the value back into the session object 
  where you can now use it any way you like.

  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 5:45 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name

  Hi Rob,

  As far as I can tell from the docs ( 
  http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
  the format of the time might include a colon, such as 18:57:00, 
  which isn't a valid file name on Windows.

  Cheers,
  Soren

  On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
 wrote:

   What about using [Time]?
   ___
FireGiant  |  Dedicated support for the WiX toolset  | 
   http://www.firegiant.com/

   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 3:38 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name

I don't know how you would go about Randomizing the Names, but 
as long as the DestinationName contains a name different from 
the SourceName the file name will be different after the copy completes.

   Yes, that's pretty much the point of DestinationName. :) What I'm 
   looking for, however, is a way to generate a unique temp file on 
   the fly without having to shell out to a custom action that does 
   this for me. The reason I want to do this is because I don't know 
   what other files could potentially exist in the directory, so I 
   want to just create a temporary unique file name similar to what
   GetTempFilePath() (

   http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
   8v
   =v
   s.85%29.aspx
   )
   does.

   It sounds like that might not be possible currently.

   Thanks though!

   On Mon, Mar 10, 2014 at 1:35 PM, Carter Young 
   ecyo...@grandecom.net
   wrote:

I don't know how you would go about Randomizing the Names, but 
as long as the DestinationName contains a name different from 
the SourceName the file name will be different after the copy completes.

Quote:
SourceName:
If this attribute is not specified (and this element is not 
nested under a File element or specify a FileId attribute) then 
the SourceProperty attribute should be set to the name of a 
property that will resolve to the full path of the source 
filename. If the value of this attribute contains a * wildcard 
and the DestinationName attribute is specified, all moved or 
copied files retain the file names from their sources.

Quote:
DestinationName:
In prior versions of the WiX toolset, this attribute specified 
the short file name. Now set this value to the localizable name 
to be given to the original file after it is moved or copied. If 
this attribute is not specified, then the destination file is 
given the same name as the source file. If a short file name is 
specified, the DestinationShortName attribute may not be 
specified. If a long file name is specified, the 
DestinationLongName attribute may not be specified. Also, if 
this value is a long file name, the DestinationShortName 
attribute may be omitted to

Re: [WiX-users] Generating a unique file name

2014-03-11 Thread tanu gupta

Hi,
We found an issue in wixbootstrapper window cancel button while installation.
Once wix bootstrapper installation starts, our msi installation gets started 
with its own dialog. And if I cancel the bootstrapper window in between, 
installation do not proceed or roll back do not happen, it just hangs.
Can anyone please help me in resolving this.
Thanks Tanu



On Tuesday, March 11, 2014 10:48 PM, Soren Dreijer dreijer+l...@echobit.net 
wrote:
  
Hey Jacob,

It's an app.config file that's part of the installation, so a major upgrade
will remove it and I'd like to make sure it's persisted so that I can
migrate it as part of the upgrade flow.

Cheers,
Soren


On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:

 Taking a step back, I would have to ask why you are needing to make a copy
 of a file with a random name. If it's a user modified file, then an upgrade
 shouldn't touch it.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 8:58 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Harold,

 Then we're back to doing a custom action, though, which means I can do

 anything I want, including calling GetTempFilePath() directly. :)

 Cheers,
 Soren


 On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
 v-wow...@microsoft.com wrote:

  Set the name as a global property, generate the name in a custom
  action, there you can use datetime.Tostring(HHmmss ) to format
  it any way you like, then put the value back into the session object
  where you can now use it any way you like.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 5:45 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Rob,
 
  As far as I can tell from the docs (
  http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
  the format of the time might include a colon, such as 18:57:00, which
  isn't a valid file name on Windows.
 
  Cheers,
  Soren
 
 
 
 On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
 wrote:
 
   What about using [Time]?
   ___
    FireGiant  |  Dedicated support for the WiX toolset  |
   http://www.firegiant.com/
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 3:38 PM
   To: General
 discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
I don't know how you would go about Randomizing the Names, but as
long as the DestinationName contains a name different from the
SourceName the file name will be different after the copy completes.
  
   Yes, that's pretty much the point of DestinationName. :) What I'm
   looking for, however, is a way to generate a unique temp file on the
   fly without having to shell out to a custom action that does this
   for me. The reason I want to do this is because I don't know what
   other files could potentially exist in the directory, so
 I want to
   just create a temporary unique file name similar to what
   GetTempFilePath() (
  
   http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v
   =v
   s.85%29.aspx
   )
   does.
  
   It sounds like that might not be possible currently.
  
   Thanks though!
  
  
   On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
   ecyo...@grandecom.net
   wrote:
  
I don't know how you would go about Randomizing the Names, but as
long as the DestinationName contains a name different from the
SourceName the file name will be different after the copy completes.
   
Quote:
SourceName:
If this attribute is not specified (and this element is not nested
under a File element or specify a FileId attribute) then the
SourceProperty attribute should be set to the name of a property
that will resolve to the full path of the source filename.
 If the
value of this attribute contains a * wildcard and the
DestinationName attribute is specified, all moved or copied files
retain the file names from their sources.
   
Quote:
DestinationName:
In prior versions of the WiX toolset, this attribute specified the
short file name. Now set this value to the localizable name to be
given to the original file after it is moved or copied. If this
attribute is not specified, then the destination file is given the
same name as the source file. If a short file name is specified,
the
 DestinationShortName attribute may not be specified. If a long
file name is specified, the DestinationLongName attribute may not
be specified. Also, if this value is a long file name, the
DestinationShortName attribute may be omitted to allow WiX to
attempt to generate a unique short file name. However, if

[WiX-users] wixbootstrapper cancel button while installation

2014-03-11 Thread tanu gupta

Hi,
wix 3.7
We found an issue in wixbootstrapper window cancel button while installation.
Once wix bootstrapper installation starts, our msi installation gets started 
with its own dialog. And if I cancel the bootstrapper window in between, 
installation do not proceed or roll back do not happen, it just hangs.
Can anyone please help me in resolving this.
Thanks Tanu



On Tuesday, March 11, 2014 8:26 PM, Phill Hogland phogl...@rimage.com wrote:
  
I could tell that the Command object was a single bundle instance.  I had
read somewhere that a mba needed to implement passing those values to a Msi
and I was trying to find where to add code to add the values to the msiexec
command line.  In my chain I have a mixture of my MSIs and third-party MSI
(and EXEs).  I eventually concluded that for my MSIs I need to pass the
infor into MsiProperty and use that to trigger in the Msi that I authored a
SetProperty on the MsiLogging (for one example, there are others).  I
basically have that working, although I am still testing certain scenarios. 
I was trying to to turn on verbose logging (*v and not LOGVERBOSE as
indicated earlier) in certain packages and not in others based on burn
command-line/mba behavior.  I have simplified that effort some as I tend to
make a problem more complicated than is really necessary smile/  (This is
also true of MSIFASTINSTALL and of 'enabling' WIXFAILWHENDEFERRED in one of
several packages, selected at run-time by the tester.)

Thanks for the feedback Bob.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Bundle-Command-line-not-passed-to-second-MSI-package-tp7593291p7593293.html
Sent from the wix-users mailing list archive at Nabble.com.


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

Re: [WiX-users] Generating a unique file name

The app.config is modified after installation by one of our tools. On an
upgrade, I do want to install a new app.config since there could be new
changes in it and I therefore need to (manually) migrate certain
information from the old app.config to the new one.


On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:

 But if it hasn't been modified then you already know what is in it.  If a
 user manually modifies the file, then a major upgrade should not remove it.
 If it was modified with XmlFile CA's or the likes, were the original user
 choices persisted in the registry?

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Tuesday, March 11, 2014 12:12 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hey Jacob,

 It's an app.config file that's part of the installation, so a major
 upgrade will remove it and I'd like to make sure it's persisted so that I
 can migrate it as part of the upgrade flow.

 Cheers,
 Soren


 On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
 jacob.hoo...@greenheck.comwrote:

  Taking a step back, I would have to ask why you are needing to make a
  copy of a file with a random name. If it's a user modified file, then
  an upgrade shouldn't touch it.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 8:58 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Harold,
 
  Then we're back to doing a custom action, though, which means I can do
  anything I want, including calling GetTempFilePath() directly. :)
 
  Cheers,
  Soren
 
 
  On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
  v-wow...@microsoft.com wrote:
 
   Set the name as a global property, generate the name in a custom
   action, there you can use datetime.Tostring(HHmmss ) to format
   it any way you like, then put the value back into the session object
   where you can now use it any way you like.
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 5:45 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
   Hi Rob,
  
   As far as I can tell from the docs (
   http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
   the format of the time might include a colon, such as 18:57:00,
   which isn't a valid file name on Windows.
  
   Cheers,
   Soren
  
  
   On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
  wrote:
  
What about using [Time]?
___
 FireGiant  |  Dedicated support for the WiX toolset  |
http://www.firegiant.com/
   
-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
Sent: Monday, March 10, 2014 3:38 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.
   
Yes, that's pretty much the point of DestinationName. :) What I'm
looking for, however, is a way to generate a unique temp file on
the fly without having to shell out to a custom action that does
this for me. The reason I want to do this is because I don't know
what other files could potentially exist in the directory, so I
want to just create a temporary unique file name similar to what
GetTempFilePath() (
   
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
8v
=v
s.85%29.aspx
)
does.
   
It sounds like that might not be possible currently.
   
Thanks though!
   
   
On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
ecyo...@grandecom.net
wrote:
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.

 Quote:
 SourceName:
 If this attribute is not specified (and this element is not
 nested under a File element or specify a FileId attribute) then
 the SourceProperty attribute should be set to the name of a
 property that will resolve to the full path of the source
 filename. If the value of this attribute contains a * wildcard
 and the DestinationName attribute is specified, all moved or
 copied files retain the file names from their sources.

 Quote:
 DestinationName:
 In prior versions of the WiX toolset, this attribute specified
 the short file name. Now set this value to the localizable name
 to be given to the original file after it is

Re: [WiX-users] Generating a unique file name

2014-03-11 Thread Phil Wilson

A major upgrade with RemoveExistingProducts at the end will update
using file update rules and altered data files will not be
overwritten. Maybe the REP is early?
---
Phil Wilson


On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
 But if it hasn't been modified then you already know what is in it.  If a 
 user manually modifies the file, then a major upgrade should not remove it. 
 If it was modified with XmlFile CA's or the likes, were the original user 
 choices persisted in the registry?

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Tuesday, March 11, 2014 12:12 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hey Jacob,

 It's an app.config file that's part of the installation, so a major upgrade 
 will remove it and I'd like to make sure it's persisted so that I can migrate 
 it as part of the upgrade flow.

 Cheers,
 Soren


 On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
 jacob.hoo...@greenheck.comwrote:

 Taking a step back, I would have to ask why you are needing to make a
 copy of a file with a random name. If it's a user modified file, then
 an upgrade shouldn't touch it.

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 8:58 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hi Harold,

 Then we're back to doing a custom action, though, which means I can do
 anything I want, including calling GetTempFilePath() directly. :)

 Cheers,
 Soren


 On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
 v-wow...@microsoft.com wrote:

  Set the name as a global property, generate the name in a custom
  action, there you can use datetime.Tostring(HHmmss ) to format
  it any way you like, then put the value back into the session object
  where you can now use it any way you like.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 5:45 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Rob,
 
  As far as I can tell from the docs (
  http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
  the format of the time might include a colon, such as 18:57:00,
  which isn't a valid file name on Windows.
 
  Cheers,
  Soren
 
 
  On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
 wrote:
 
   What about using [Time]?
   ___
FireGiant  |  Dedicated support for the WiX toolset  |
   http://www.firegiant.com/
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 3:38 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
I don't know how you would go about Randomizing the Names, but
as long as the DestinationName contains a name different from
the SourceName the file name will be different after the copy 
completes.
  
   Yes, that's pretty much the point of DestinationName. :) What I'm
   looking for, however, is a way to generate a unique temp file on
   the fly without having to shell out to a custom action that does
   this for me. The reason I want to do this is because I don't know
   what other files could potentially exist in the directory, so I
   want to just create a temporary unique file name similar to what
   GetTempFilePath() (
  
   http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
   8v
   =v
   s.85%29.aspx
   )
   does.
  
   It sounds like that might not be possible currently.
  
   Thanks though!
  
  
   On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
   ecyo...@grandecom.net
   wrote:
  
I don't know how you would go about Randomizing the Names, but
as long as the DestinationName contains a name different from
the SourceName the file name will be different after the copy 
completes.
   
Quote:
SourceName:
If this attribute is not specified (and this element is not
nested under a File element or specify a FileId attribute) then
the SourceProperty attribute should be set to the name of a
property that will resolve to the full path of the source
filename. If the value of this attribute contains a * wildcard
and the DestinationName attribute is specified, all moved or
copied files retain the file names from their sources.
   
Quote:
DestinationName:
In prior versions of the WiX toolset, this attribute specified
the short file name. Now set this value to the localizable name
to be given to the original file after it is moved or copied. If
this attribute is not specified, then the destination file is
given the same name as the source file. If a short file name is

Re: [WiX-users] Generating a unique file name

I suggest using Jacob's Approach.  Instead of keeping the app.config  
file, and trying all this mess with copy etc, write the changes that  
your tool makes to the registry, and only keep the settings that don't  
change in the app.config.  Then every major upgrade, have your app  
read the registry values...  Takes a little bit of work and research,  
but will save you this headache.

Carter

Quoting Soren Dreijer dreijer+l...@echobit.net:

 The app.config is modified after installation by one of our tools. On an
 upgrade, I do want to install a new app.config since there could be new
 changes in it and I therefore need to (manually) migrate certain
 information from the old app.config to the new one.


 On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
 jacob.hoo...@greenheck.comwrote:

 But if it hasn't been modified then you already know what is in it.  If a
 user manually modifies the file, then a major upgrade should not remove it.
 If it was modified with XmlFile CA's or the likes, were the original user
 choices persisted in the registry?

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Tuesday, March 11, 2014 12:12 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

 Hey Jacob,

 It's an app.config file that's part of the installation, so a major
 upgrade will remove it and I'd like to make sure it's persisted so that I
 can migrate it as part of the upgrade flow.

 Cheers,
 Soren


 On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
 jacob.hoo...@greenheck.comwrote:

  Taking a step back, I would have to ask why you are needing to make a
  copy of a file with a random name. If it's a user modified file, then
  an upgrade shouldn't touch it.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 8:58 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Harold,
 
  Then we're back to doing a custom action, though, which means I can do
  anything I want, including calling GetTempFilePath() directly. :)
 
  Cheers,
  Soren
 
 
  On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
  v-wow...@microsoft.com wrote:
 
   Set the name as a global property, generate the name in a custom
   action, there you can use datetime.Tostring(HHmmss ) to format
   it any way you like, then put the value back into the session object
   where you can now use it any way you like.
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 5:45 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
   Hi Rob,
  
   As far as I can tell from the docs (
   http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
   the format of the time might include a colon, such as 18:57:00,
   which isn't a valid file name on Windows.
  
   Cheers,
   Soren
  
  
   On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
  wrote:
  
What about using [Time]?
___
 FireGiant  |  Dedicated support for the WiX toolset  |
http://www.firegiant.com/
   
-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
Sent: Monday, March 10, 2014 3:38 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.
   
Yes, that's pretty much the point of DestinationName. :) What I'm
looking for, however, is a way to generate a unique temp file on
the fly without having to shell out to a custom action that does
this for me. The reason I want to do this is because I don't know
what other files could potentially exist in the directory, so I
want to just create a temporary unique file name similar to what
GetTempFilePath() (
   
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
8v
=v
s.85%29.aspx
)
does.
   
It sounds like that might not be possible currently.
   
Thanks though!
   
   
On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
ecyo...@grandecom.net
wrote:
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.

 Quote:
 SourceName:
 If this attribute is not specified (and this element is not
 nested under a File element or specify a FileId attribute) then
 the SourceProperty attribute should be set to the name of a
 property that will resolve

[WiX-users] Not Really: My problem. Bundle Command line not passed to second MSI package

For looking at this in the future reference I should add that original post
was deleted because I discovered that I was delusional when I wrote Bundle
Command line not passed to second MSI package.  An errant line of code was
causing the specific behavior that one MSI had LOGVERBOSE set and the others
did not have it set.

Tanu, you probably should start a new thread with your new concerns.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wix-users-f687560.html

It sounds like you are describing the intended wix design.  Since burn.exe
is more than just a bootstrapper and owns the MSI which it launched for the
life of the installation, I would expect all of the threads to be killed
when the parent process is killed.  Burn is not designed to
'launch-and-forget'.  I expect others can explain this better than I.





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Bundle-Command-line-not-passed-to-second-MSI-package-tp7593291p7593311.html
Sent from the wix-users mailing list archive at Nabble.com.

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

Re: [WiX-users] How to do in wix v3.8 what setupbld.exe did

2014-03-11 Thread Dan Watson

Thanks for your reply.

 In general, that's the best user experience. It's possible to use 
 MsiPackage/@DisplayInternalUI but it has limitations and ends up with 
 two UIs (the bundle and the .msi).

Now everything makes sense and by relying on setupbld.exe thus far I just 
managed to ignore one important aspect of Windows setup, i.e. the Bootstrapper 
with Burn.
Since I posted the question, I have tried to catch up with Bootstrapper 
project, and as you indicate in your reply I used the 
MsiPackage/@DisplayInternalUI but not happy with the two UIs that show up 
(bundle and msi) which could be confusing to the end users. Now I know this is 
the limitation of the MsiPackage/@DisplayInternalUI route.

If I understand it fully, it means [ideally] the goal is:
- to check system settings in Bootstrapper and decide whether to progress with 
the setup;
- collect relevant system settings by a Bootstrapper for use by MSI (which may 
be passed on as MSI variables?), and
- do system configuration silently with MSI.

Is the above assumption correct? 
If so, can every setup be mapped as such?
I am trying to think in terms of a web application project setup that involves 
IIS and database configuration and I wonder if a solution can be as clear-cut 
as the above assumption.  I have to move my MSI UIs into a Bootstrapper and see 
how far I can get.

Thanks again.


 Date: Tue, 11 Mar 2014 00:52:53 -0400
 From: b...@joyofsetup.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] How to do in wix v3.8 what setupbld.exe did
 
 On 07-Mar-14 05:45, Dan Watson wrote:
  1) I understand the power of Bootstrapper project in bundling multiple MSI 
  setups (the Office installation being a good example) but is there an 
  equivalent of Burn command that would package my MSI setup as setupbld.exe 
  did with a command switches?
 No. Bundles are built like everything else in WiX, by compiling and linking.
 
  2) If I use a Bootstrapper project,  does it mean that I need to move my 
  existing UI in the MSI installer to the Bootstrapper?
 In general, that's the best user experience. It's possible to use 
 MsiPackage/@DisplayInternalUI but it has limitations and ends up with 
 two UIs (the bundle and the .msi).
 
 -- 
 sig://boB
 http://joyofsetup.com/
 
 
 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?




Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo 
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.


On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send 
 request to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 connect to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get 
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt 
 to download URL: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 acquire payload from: 
 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to working path:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e313: Failed to acquire payload:
 ProjectAggregator2 to working path:
 C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42
 dc4}\ProjectAggregator2,
 error: 0x80070002.
 [1BA8:0C04][2013-09-10T12:24:12]e000: Error 0x80070002: Failed while 
 caching, aborting execution.

 This machine (where I actually develop from) has no internet.




 Keith Douglas
 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
 Facsimile | Télécopieur 613-951-1966 Government of Canada | 
 Gouvernement du Canada


 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: September-10-13 12:17 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] offline install

 The wix37.exe is essentially self-contained (except for 
 ProjectAggregator2.msi which is only needed for VS2005).  It doesn't 
 use the wix37-binaries.zip. What exactly is the issue you are having?


 On Tue, Sep 10, 2013 at 9:02 AM, keith.doug...@statcan.gc.ca wrote:

  How exactly does one use offline install mode in WiX 3.7 ? I have 
  the binaries package and the 20 meg .exe but it doesn't seem to find 
  the binaries if they are loose in the directory. (/layout doesn't 
  work for me on my public net machine due to web proxies or the like 
  in the
  way.)
 
 
 
  Keith Douglas
  Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
  Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
  0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
  Facsimile | Télécopieur 613-951-1966 Government of Canada | 
  Gouvernement du Canada

Re: [WiX-users] Generating a unique file name

Phil,

So, that will be a problem then because I *do* want the new app.config
installed so that I can merge the existing changes into the new config file.


On Tue, Mar 11, 2014 at 10:48 AM, Phil Wilson phildgwil...@gmail.comwrote:

 A major upgrade with RemoveExistingProducts at the end will update
 using file update rules and altered data files will not be
 overwritten. Maybe the REP is early?
 ---
 Phil Wilson


 On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
 jacob.hoo...@greenheck.com wrote:
  But if it hasn't been modified then you already know what is in it.  If
 a user manually modifies the file, then a major upgrade should not remove
 it. If it was modified with XmlFile CA's or the likes, were the original
 user choices persisted in the registry?
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Tuesday, March 11, 2014 12:12 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hey Jacob,
 
  It's an app.config file that's part of the installation, so a major
 upgrade will remove it and I'd like to make sure it's persisted so that I
 can migrate it as part of the upgrade flow.
 
  Cheers,
  Soren
 
 
  On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
  jacob.hoo...@greenheck.comwrote:
 
  Taking a step back, I would have to ask why you are needing to make a
  copy of a file with a random name. If it's a user modified file, then
  an upgrade shouldn't touch it.
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Monday, March 10, 2014 8:58 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hi Harold,
 
  Then we're back to doing a custom action, though, which means I can do
  anything I want, including calling GetTempFilePath() directly. :)
 
  Cheers,
  Soren
 
 
  On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
  v-wow...@microsoft.com wrote:
 
   Set the name as a global property, generate the name in a custom
   action, there you can use datetime.Tostring(HHmmss ) to format
   it any way you like, then put the value back into the session object
   where you can now use it any way you like.
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 5:45 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
   Hi Rob,
  
   As far as I can tell from the docs (
   http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx),
   the format of the time might include a colon, such as 18:57:00,
   which isn't a valid file name on Windows.
  
   Cheers,
   Soren
  
  
   On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
  wrote:
  
What about using [Time]?
___
 FireGiant  |  Dedicated support for the WiX toolset  |
http://www.firegiant.com/
   
-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
Sent: Monday, March 10, 2014 3:38 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.
   
Yes, that's pretty much the point of DestinationName. :) What I'm
looking for, however, is a way to generate a unique temp file on
the fly without having to shell out to a custom action that does
this for me. The reason I want to do this is because I don't know
what other files could potentially exist in the directory, so I
want to just create a temporary unique file name similar to what
GetTempFilePath() (
   
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
8v
=v
s.85%29.aspx
)
does.
   
It sounds like that might not be possible currently.
   
Thanks though!
   
   
On Mon, Mar 10, 2014 at 1:35 PM, Carter Young
ecyo...@grandecom.net
wrote:
   
 I don't know how you would go about Randomizing the Names, but
 as long as the DestinationName contains a name different from
 the SourceName the file name will be different after the copy
 completes.

 Quote:
 SourceName:
 If this attribute is not specified (and this element is not
 nested under a File element or specify a FileId attribute) then
 the SourceProperty attribute should be set to the name of a
 property that will resolve to the full path of the source
 filename. If the value of this attribute contains a * wildcard
 and the DestinationName attribute is specified, all moved or
 copied files retain the file names from their sources.

 Quote:
 DestinationName:

Re: [WiX-users] Generating a unique file name

Carter,

I can't easily change the location where these changes are made. It's an
existing codebase that happens to use the app.config, so that's sort of
where I have to start from (sadly).

At this point, I think I'll just make a custom action that does this whole
thing and be done with it. :)

/ Soren


On Tue, Mar 11, 2014 at 11:12 AM, Carter Young ecyo...@grandecom.netwrote:

 I suggest using Jacob's Approach.  Instead of keeping the app.config
 file, and trying all this mess with copy etc, write the changes that
 your tool makes to the registry, and only keep the settings that don't
 change in the app.config.  Then every major upgrade, have your app
 read the registry values...  Takes a little bit of work and research,
 but will save you this headache.

 Carter

 Quoting Soren Dreijer dreijer+l...@echobit.net:

  The app.config is modified after installation by one of our tools. On an
  upgrade, I do want to install a new app.config since there could be new
  changes in it and I therefore need to (manually) migrate certain
  information from the old app.config to the new one.
 
 
  On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
  jacob.hoo...@greenheck.comwrote:
 
  But if it hasn't been modified then you already know what is in it.  If
 a
  user manually modifies the file, then a major upgrade should not remove
 it.
  If it was modified with XmlFile CA's or the likes, were the original
 user
  choices persisted in the registry?
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Tuesday, March 11, 2014 12:12 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hey Jacob,
 
  It's an app.config file that's part of the installation, so a major
  upgrade will remove it and I'd like to make sure it's persisted so that
 I
  can migrate it as part of the upgrade flow.
 
  Cheers,
  Soren
 
 
  On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
  jacob.hoo...@greenheck.comwrote:
 
   Taking a step back, I would have to ask why you are needing to make a
   copy of a file with a random name. If it's a user modified file, then
   an upgrade shouldn't touch it.
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 8:58 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
   Hi Harold,
  
   Then we're back to doing a custom action, though, which means I can do
   anything I want, including calling GetTempFilePath() directly. :)
  
   Cheers,
   Soren
  
  
   On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
   v-wow...@microsoft.com wrote:
  
Set the name as a global property, generate the name in a custom
action, there you can use datetime.Tostring(HHmmss ) to format
it any way you like, then put the value back into the session object
where you can now use it any way you like.
   
-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
Sent: Monday, March 10, 2014 5:45 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name
   
Hi Rob,
   
As far as I can tell from the docs (
http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx
 ),
the format of the time might include a colon, such as 18:57:00,
which isn't a valid file name on Windows.
   
Cheers,
Soren
   
   
On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
   wrote:
   
 What about using [Time]?
 ___
  FireGiant  |  Dedicated support for the WiX toolset  |
 http://www.firegiant.com/

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 3:38 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

  I don't know how you would go about Randomizing the Names, but
  as long as the DestinationName contains a name different from
  the SourceName the file name will be different after the copy
  completes.

 Yes, that's pretty much the point of DestinationName. :) What I'm
 looking for, however, is a way to generate a unique temp file on
 the fly without having to shell out to a custom action that does
 this for me. The reason I want to do this is because I don't know
 what other files could potentially exist in the directory, so I
 want to just create a temporary unique file name similar to what
 GetTempFilePath() (


 http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%2
 8v
 =v
 s.85%29.aspx
 )
 does.

 It sounds like that might not be possible currently.

 Thanks though!


 On Mon, Mar 10, 2014 at 1:35 PM, Carter Young

Re: [WiX-users] Generating a unique file name

In that Case, create a directory in %USERS%/AppData/Local/AppName.   
Move the app.config file there til after the upgrade then use a CA, as  
you stated earlier to merge the 2 files, alleviating the need for a  
temporary name.

Carter

Quoting Soren Dreijer dreijer+l...@echobit.net:

 Carter,

 I can't easily change the location where these changes are made. It's an
 existing codebase that happens to use the app.config, so that's sort of
 where I have to start from (sadly).

 At this point, I think I'll just make a custom action that does this whole
 thing and be done with it. :)

 / Soren


 On Tue, Mar 11, 2014 at 11:12 AM, Carter Young ecyo...@grandecom.netwrote:

 I suggest using Jacob's Approach.  Instead of keeping the app.config
 file, and trying all this mess with copy etc, write the changes that
 your tool makes to the registry, and only keep the settings that don't
 change in the app.config.  Then every major upgrade, have your app
 read the registry values...  Takes a little bit of work and research,
 but will save you this headache.

 Carter

 Quoting Soren Dreijer dreijer+l...@echobit.net:

  The app.config is modified after installation by one of our tools. On an
  upgrade, I do want to install a new app.config since there could be new
  changes in it and I therefore need to (manually) migrate certain
  information from the old app.config to the new one.
 
 
  On Tue, Mar 11, 2014 at 10:25 AM, Hoover, Jacob
  jacob.hoo...@greenheck.comwrote:
 
  But if it hasn't been modified then you already know what is in it.  If
 a
  user manually modifies the file, then a major upgrade should not remove
 it.
  If it was modified with XmlFile CA's or the likes, were the original
 user
  choices persisted in the registry?
 
  -Original Message-
  From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
  Sent: Tuesday, March 11, 2014 12:12 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Generating a unique file name
 
  Hey Jacob,
 
  It's an app.config file that's part of the installation, so a major
  upgrade will remove it and I'd like to make sure it's persisted so that
 I
  can migrate it as part of the upgrade flow.
 
  Cheers,
  Soren
 
 
  On Tue, Mar 11, 2014 at 9:30 AM, Hoover, Jacob
  jacob.hoo...@greenheck.comwrote:
 
   Taking a step back, I would have to ask why you are needing to make a
   copy of a file with a random name. If it's a user modified file, then
   an upgrade shouldn't touch it.
  
   -Original Message-
   From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
   Sent: Monday, March 10, 2014 8:58 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] Generating a unique file name
  
   Hi Harold,
  
   Then we're back to doing a custom action, though, which means I can do
   anything I want, including calling GetTempFilePath() directly. :)
  
   Cheers,
   Soren
  
  
   On Mon, Mar 10, 2014 at 6:00 PM, Harold Wood (H10 Capital) 
   v-wow...@microsoft.com wrote:
  
Set the name as a global property, generate the name in a custom
action, there you can use datetime.Tostring(HHmmss ) to format
it any way you like, then put the value back into the session object
where you can now use it any way you like.
   
-Original Message-
From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
Sent: Monday, March 10, 2014 5:45 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Generating a unique file name
   
Hi Rob,
   
As far as I can tell from the docs (
http://msdn.microsoft.com/en-us/library/aa372079%28v=vs.85%29.aspx
 ),
the format of the time might include a colon, such as 18:57:00,
which isn't a valid file name on Windows.
   
Cheers,
Soren
   
   
On Mon, Mar 10, 2014 at 4:06 PM, Rob Mensching r...@firegiant.com
   wrote:
   
 What about using [Time]?
 ___
  FireGiant  |  Dedicated support for the WiX toolset  |
 http://www.firegiant.com/

 -Original Message-
 From: Soren Dreijer [mailto:dreijer+l...@echobit.net]
 Sent: Monday, March 10, 2014 3:38 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Generating a unique file name

  I don't know how you would go about Randomizing the Names, but
  as long as the DestinationName contains a name different from
  the SourceName the file name will be different after the copy
  completes.

 Yes, that's pretty much the point of DestinationName. :) What I'm
 looking for, however, is a way to generate a unique temp file on
 the fly without having to shell out to a custom action that does
 this for me. The reason I want to do this is because I don't know
 what other files could potentially exist in the directory, so I
 want to just create a temporary unique file name similar to what
 GetTempFilePath()

Re: [WiX-users] offline install

Another way into the questions I asked:

What precisely are the prerequisites for WiX 3.7 *itself*? Is there any 
particular reason why these are not in the bundle?



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo 
Sent: March-11-14 3:05 PM
To: Douglas, Keith - CoSD/DSCo; 'General discussion for Windows Installer XML 
toolset.'
Subject: RE: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?




Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.


On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send 
 request to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 connect to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get 
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt 
 to download URL: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 acquire payload from: 
 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to working path:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e313: Failed to acquire payload:
 ProjectAggregator2 to working path:
 C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42
 dc4}\ProjectAggregator2,
 error: 0x80070002.
 [1BA8:0C04][2013-09-10T12:24:12]e000: Error 0x80070002: Failed while 
 caching, aborting execution.

 This machine (where I actually develop from) has no internet.




 Keith Douglas
 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
 Facsimile | Télécopieur 613-951-1966 Government of Canada | 
 Gouvernement du Canada


 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: September-10-13 12:17 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] offline install

 The wix37.exe is essentially self-contained (except for 
 ProjectAggregator2.msi which is only needed for VS2005).  It doesn't 
 use the wix37-binaries.zip. What exactly is the issue you are having?


 On Tue, Sep 10,

Re: [WiX-users] offline install

2014-03-11 Thread Hoover, Jacob

You can't use a signed bundle to install the root certs for the cert which 
signed the bundle.

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] 
Sent: Tuesday, March 11, 2014 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

Another way into the questions I asked:

What precisely are the prerequisites for WiX 3.7 *itself*? Is there any 
particular reason why these are not in the bundle?

Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 

-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: March-11-14 3:05 PM
To: Douglas, Keith - CoSD/DSCo; 'General discussion for Windows Installer XML 
toolset.'
Subject: RE: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?

Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 

-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,

Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.

On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send 
 request to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 connect to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get 
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt 
 to download URL: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 acquire payload from: 
 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to working path:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e313: Failed to acquire payload:
 ProjectAggregator2 to working path:
 C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42
 dc4}\ProjectAggregator2,
 error: 0x80070002.
 [1BA8:0C04][2013-09-10T12:24:12]e000: Error 0x80070002: Failed while 
 caching, aborting execution.

 This machine (where I actually develop from) has no internet.

 Keith Douglas
 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A
 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 
 Facsimile | Télécopieur 613-951-1966 Government of Canada | 
 Gouvernement du Canada

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: September-10-13 12:17 PM
 To:

Re: [WiX-users] offline install

That's understandable; are there any other prerequisites?


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: March-11-14 4:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] offline install

You can't use a signed bundle to install the root certs for the cert which 
signed the bundle.

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Tuesday, March 11, 2014 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

Another way into the questions I asked:

What precisely are the prerequisites for WiX 3.7 *itself*? Is there any 
particular reason why these are not in the bundle?



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: March-11-14 3:05 PM
To: Douglas, Keith - CoSD/DSCo; 'General discussion for Windows Installer XML 
toolset.'
Subject: RE: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?




Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.


On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send 
 request to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 connect to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get 
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt 
 to download URL: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 acquire payload from: 
 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to working path:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e313: Failed to acquire payload:
 ProjectAggregator2 to working path:
 C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42
 dc4}\ProjectAggregator2,
 error: 0x80070002.
 [1BA8:0C04][2013-09-10T12:24:12]e000:

Re: [WiX-users] offline install

2014-03-11 Thread Rob Mensching

NETFX 4.0 is required. ProjectAggregator2.msi is only necessary if you have 
VS2008 installed.

The log file should show what the issue is. I doubt it's certificate issues 
since we don't sign our payloads, only the Bundle itself (and that doesn't 
trigger the issues with certificates).

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

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] 
Sent: Tuesday, March 11, 2014 1:35 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

That's understandable; are there any other prerequisites?


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: March-11-14 4:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] offline install

You can't use a signed bundle to install the root certs for the cert which 
signed the bundle.

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Tuesday, March 11, 2014 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

Another way into the questions I asked:

What precisely are the prerequisites for WiX 3.7 *itself*? Is there any 
particular reason why these are not in the bundle?



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: March-11-14 3:05 PM
To: Douglas, Keith - CoSD/DSCo; 'General discussion for Windows Installer XML 
toolset.'
Subject: RE: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?




Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.


On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send 
 request to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to 
 connect to URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get 
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt 
 to download URL:

Re: [WiX-users] offline install

Root certificates mattered when I installed 3.7 on Server 2003 a few months 
ago. Nevertheless, I will await the log ...



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: March-11-14 4:44 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] offline install

NETFX 4.0 is required. ProjectAggregator2.msi is only necessary if you have 
VS2008 installed.

The log file should show what the issue is. I doubt it's certificate issues 
since we don't sign our payloads, only the Bundle itself (and that doesn't 
trigger the issues with certificates).

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

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Tuesday, March 11, 2014 1:35 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

That's understandable; are there any other prerequisites?


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: March-11-14 4:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] offline install

You can't use a signed bundle to install the root certs for the cert which 
signed the bundle.

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Tuesday, March 11, 2014 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] offline install

Another way into the questions I asked:

What precisely are the prerequisites for WiX 3.7 *itself*? Is there any 
particular reason why these are not in the bundle?



Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: March-11-14 3:05 PM
To: Douglas, Keith - CoSD/DSCo; 'General discussion for Windows Installer XML 
toolset.'
Subject: RE: [WiX-users] offline install

A co-worker is having trouble doing an offline install of Wix 3.7. I'll send 
along the log later on (once he can get me a copy), but meanwhile, based on my 
earlier mishaps:

Does Windows 7 ship with the root certificates needed to validate the install?
What prerequisites are needed beyond ProjectAggregator2.msi in the same 
directory?




Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: September-10-13 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] offline install

Ah ha, gotcha. I'll do that.

Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | 
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: September-10-13 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] offline install

That's because http://wixtoolset.org suffered catastrophic hardware failure. 
It's taking them days to try to recover all the data. You can find 
ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put it 
next to the wix37.exe. That is what /layout would do... if the website would 
respond.


On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:

Re: [WiX-users] offline install