date:20120201

What about duplicating the files?  I know that sounds a bit crazy but if
you're okay taking a bit more size on disk when installed, the WiX
toolset's smartcabbing will only carry the files once in the package.

On Wed, Feb 1, 2012 at 3:47 PM, McKinnon, Chris  wrote:

> Hi,
>
> I'm updating my install process and I'd like to hear suggestions on
> improving my install process.
>
> My apps normally consist of a web site and a windows service.  The apps
> and installers are for "in-house" use only.  In the past, I've modified the
> install UI to allow to separate install locations for the web site and
> windows service.  I think I did it this way because that's how we used to
> manually install apps.
>
> Now, I'm re-visiting this decision and I'd like to fix two install related
> "issues":
> 1.  Have one install location for the application.
> 2.  Move common files to a "Common" location.
>
> Addressing #1 is fairly simple.  Use one install location and use
> subfolders for the different components:
>
> [Install Directory]
>[bin] <-- application DLLs
>[Web Site] <-- Web Site files
>[Windows Service] <-- Windows Service files
>
> Both the Web Site's and Windows Service's DLLs are in the "bin" folder.
>  This introduces a new problem:  How do the .NET apps find the DLLs?  I
> used SysInternals "junction.exe" to create a junction to the bin folder in
> both the "Web Site" and "Windows Services" folders.  In the config files of
> both apps, I use a "runtime->probing" specification to tell the apps to
> look for the DLLs in a "bin" subfolder.  So, I end up with:
>
> [Install Directory]
>[bin] <-- application DLLs
>[Web Site] <-- Web Site files
>[bin] <-- Junction pointing back to top level "bin" folder
>[Windows Service] <-- Windows Service files
>[bin] <-- Junction pointing back to top level "bin" folder
>
> This seems to work nicely.  I'm not particularly fond of calling
> "junction.exe" at the end of my install but it works.  I'd rather have a
> DLL call.  Since the DLL could be included as a binary.  I've been
> searching around for common solutions to this install problem but I haven't
> seen it addressed.
>
> I'm wondering if there is a better solution?  I looked at using "codebase"
> but didn't like having to specify specific DLL information.  And I think it
> would be inappropriate to use the GAC as the DLLs are for a specific app
> (rather than DLLs that could be used by any app).
>
> Thanks,
>
> Chris McKinnon
>
>
> The information contained in this e-mail is confidential and may contain
> privileged information. It is intended only for the person or persons named
> above. If you are not an intended recipient of this e-mail please be
> advised that any distribution or copying of this e-mail is prohibited. If
> you have received this e-mail in error, please notify us by return e-mail
> and delete all copies of the e-mail and any attachments.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



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

Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

That's what I was going to suggest first. Can you open a bug to track the
issue?

On Wed, Feb 1, 2012 at 1:12 PM, John Cooper  wrote:

> Hmm.  Rebuilt with the latest Wix 3.6, and I still get:
>
> Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values
> MSI (s) (44:24) [15:10:21:915]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section for
> DirProp
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS
> DirProperties.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note
> this may not be 100% accurate if translation happened inside sandbox)
> Action ended 15:10:22: InstallFinalize. Return value 3.
>
> --
> John M. Cooper
>
> -Original Message-
> From: John Cooper
> Sent: Wednesday, February 01, 2012 2:36 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed
> get handlers section for DirProp
>
> Wonderful.   Is there an assembly I can take from the Wix 3.6 build and
> replace in the 3.5?  I've got to stay with 3.5 until 3.6 goes RTM.
> --
> John M. Cooper
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, February 01, 2012 2:25 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed
> get handlers section for DirProp
>
> This sounds very much like a bug that was fixed in WiX v3.6...
>
> On Wed, Feb 1, 2012 at 11:17 AM, John Cooper 
> wrote:
>
> > Replying to myself:
> >
> > Commenting out the iis:WebDirProperties element results in a different
> > error:
> >
> > Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and
> > Values MSI (s) (60:E0) [13:13:03:168]: Executing op:
> > CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> > urce=BinaryData,Target=**,CustomActionData=**)
> > MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL:
> > C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges
> > WriteIIS7ConfigChanges:  Error 0x80070057: Failed get httpErrors
> > section
> > WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS web
> > svc ext.
> > WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> > CustomAction WriteIIS7ConfigChanges returned actual error code 1603
> > (note this may not be 100% accurate if translation happened inside
> > sandbox) Action ended 13:13:06: InstallFinalize. Return value 3.
> >
> > --
> > John M. Cooper
> >
> > -Original Message-
> > From: John Cooper
> > Sent: Wednesday, February 01, 2012 12:45 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed
> > get handlers section for DirProp
> >
> > I'm getting an install time error during IIS7 Configuration:
> >  WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers for
> DirProp.
> >
> > This is with Wix 3.5 RTM.
> >
> > An extract of the verbose log looks like:
> >
> > Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and
> > Values MSI (s) (F4:74) [12:37:38:134]: Executing op:
> > CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> > urce=BinaryData,Target=**,CustomActionData=**)
> > MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL:
> > C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
> > WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section
> > for DirProp
> > WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS
> > DirProperties.
> > WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> > CustomAction WriteIIS7ConfigChanges returned actual error code 1603
> > (note this may not be 100% accurate if translation happened inside
> > sandbox) Action ended 12:37:41: InstallFinalize. Return value 3.
> >
> > The relevant source looks like:
> >
> >  
> >
> >
> > > Directory="WebsiteFolder">
> >  
> >   > />
> >
> >  
> >  
> >
> >
> >   > Win64="yes">
> >
> > > Alias="[XHSAlias]" WebSite="TargetWebSite">
> >   > BasicAuthentication="yes" Index="yes" Read="yes"
> > WindowsAuthentication="yes" />
> >   > WebAppPool="XHSAppPool" />
> >
> > > Name="ApplicationPoolIdentity" />
> > > Identity="other" User="XHSAppPoolUser" ManagedPipelineMode="integrated"
> > ManagedRuntimeVersion="v4.0" />
> >  
> >
> >  
> >
> > I'm at a loss how to w

[WiX-users] Installing multiple applications

2012-02-01 Thread McKinnon, Chris

Hi,

I'm updating my install process and I'd like to hear suggestions on improving 
my install process.

My apps normally consist of a web site and a windows service.  The apps and 
installers are for "in-house" use only.  In the past, I've modified the install 
UI to allow to separate install locations for the web site and windows service. 
 I think I did it this way because that's how we used to manually install apps.

Now, I'm re-visiting this decision and I'd like to fix two install related 
"issues":
1.  Have one install location for the application.
2.  Move common files to a "Common" location.

Addressing #1 is fairly simple.  Use one install location and use subfolders 
for the different components:

[Install Directory]
[bin] <-- application DLLs
[Web Site] <-- Web Site files
[Windows Service] <-- Windows Service files

Both the Web Site's and Windows Service's DLLs are in the "bin" folder.  This 
introduces a new problem:  How do the .NET apps find the DLLs?  I used 
SysInternals "junction.exe" to create a junction to the bin folder in both the 
"Web Site" and "Windows Services" folders.  In the config files of both apps, I 
use a "runtime->probing" specification to tell the apps to look for the DLLs in 
a "bin" subfolder.  So, I end up with:

[Install Directory]
[bin] <-- application DLLs
[Web Site] <-- Web Site files
[bin] <-- Junction pointing back to top level "bin" folder
[Windows Service] <-- Windows Service files
[bin] <-- Junction pointing back to top level "bin" folder

This seems to work nicely.  I'm not particularly fond of calling "junction.exe" 
at the end of my install but it works.  I'd rather have a DLL call.  Since the 
DLL could be included as a binary.  I've been searching around for common 
solutions to this install problem but I haven't seen it addressed.

I'm wondering if there is a better solution?  I looked at using "codebase" but 
didn't like having to specify specific DLL information.  And I think it would 
be inappropriate to use the GAC as the DLLs are for a specific app (rather than 
DLLs that could be used by any app).

Thanks,

Chris McKinnon


The information contained in this e-mail is confidential and may contain 
privileged information. It is intended only for the person or persons named 
above. If you are not an intended recipient of this e-mail please be advised 
that any distribution or copying of this e-mail is prohibited. If you have 
received this e-mail in error, please notify us by return e-mail and delete all 
copies of the e-mail and any attachments.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install issue - wix2010.target line 761

2012-02-01 Thread Mark Sugrue

Thanks for the reply.

How do I set %WIX%? And what should I set it to?

Previously, I just installed WiX and compile worked fine. What might
have changed?

On Wed, Feb 1, 2012 at 18:05, Blair  wrote:
> I don't know. Is the %WIX% environment variable set?
>
> I use the HarvestDirectory items instead of the PreBuildEvent property to
> use the harvester in 3.5 myself.
>
> -Original Message-
> From: Mark Sugrue [mailto:mark.sug...@gmail.com]
> Sent: Wednesday, February 01, 2012 8:57 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Install issue - wix2010.target line 761
>
> I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same
> as the old machine. (both are x64 Win7 Pro)
>
> When I try to build the installer on the new machine, I get an odd error
> which I don't understand. Nothing on the web seems to match it.
>
> The error isn't in my code, its on line 761 of wix2010.targets
>
> The line is  Command="$(ExpandedPreBuildEvent)" />
>
> I haven't edited this file at all.
>
> The error I get is this:
>
> Error   3       The command ""%WIX%\bin\heat" dir
> "D:\Code\products\LE\bin\Debug\Help" -dr HelpFolder -cg HelpComponentGroup
> -var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out
> "D:\Code\products\LE\Setup\help.wxs.sample""
> exited with code 3.     C:\Program Files
> (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets        761     6
> Setup
>
> But the exact same code compiles fine on the old machine.
>
> Is there some setting I need to change maybe?
>
> 
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

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

[WiX-users] patch install error 2247 & 1636 while adding a new component to the patch.

2012-02-01 Thread Sandip Shahane

I am getting below error when  trying to install a patch that has added a new 
component (2 files). When looked from orca it appears to add the 2 files just 
fine. Also if I add the new files to existing component instead of adding a new 
component, it seems to be installing fine.

Additional information:

1.   I am using WIX 3 toolset to generate patch. Original MSI and the 
updated one is built using WIX 2.0

2.   We have another MSI that and we have added components via it's patch, 
that one seems to be working just fine. It's just this MSI that has the below 
issue.

3.   I also tried using WIX 3.5 to generate patch and that too is failing 
with same error.

What is the problem here and how do I fix it? Do I need to open a bug for this 
if this isn't already a known issue? Let me know if you need more info on this.

Patch Install error:
=== Verbose logging started: 2/1/2012  13:56:08  Build type: SHIP UNICODE 
5.00.7601.00  Calling process: C:\Windows\System32\msiexec.exe ===
MSI (c) (84:64) [13:56:08:703]: Font created.  Charset: Req=0, Ret=0, Font: 
Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (84:64) [13:56:08:704]: Font created.  Charset: Req=0, Ret=0, Font: 
Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (84:70) [13:56:08:737]: Resetting cached policy values
MSI (c) (84:70) [13:56:08:737]: Machine policy value 'Debug' is 0
MSI (c) (84:70) [13:56:08:737]: *** RunEngine:
   *** Product: {PRODUCT-CODE-GUID}
   *** Action:
   *** CommandLine: **
MSI (c) (84:70) [13:56:08:739]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (84:70) [13:56:08:845]: Cloaking enabled.
MSI (c) (84:70) [13:56:08:845]: Attempting to enable all disabled privileges 
before calling Install on Server
MSI (c) (84:70) [13:56:08:857]: End dialog not enabled
MSI (c) (84:70) [13:56:08:858]: Original package ==> 
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:858]: Package we're running from ==> 
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall Flags override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall VersionNT override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall ServicePackLevel override 
found.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: looking for appcompat database entry 
with ProductCode '{PRODUCT-CODE-GUID}'.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: no matching ProductCode found in 
database.
MSI (c) (84:70) [13:56:08:872]: MSCOREE not loaded loading copy from system32
MSI (c) (84:70) [13:56:08:880]: Original patch ==> C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:880]: Patch we're running from ==> 
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY: Verifying patch 
--> 'C:\acs\KB1234567-x64-ABC.msp' against software restriction policy
MSI (c) (84:70) [13:56:08:881]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY: 
C:\acs\KB1234567-x64-ABC.msp is not digitally signed
MSI (c) (84:70) [13:56:08:883]: SOFTWARE RESTRICTION POLICY: 
C:\acs\KB1234567-x64-ABC.msp is permitted to run at the 'unrestricted' 
authorization level.
MSI (c) (84:70) [13:56:08:884]: SequencePatches starts. Product code: 
{PRODUCT-CODE-GUID}, Product version: 6.1.7221.0, Upgrade code: 
{UPGRADE-CODE-GUID}, Product language 1033
MSI (c) (84:70) [13:56:08:884]: PATCH SEQUENCER: verifying the applicability of 
QFE patch C:\acs\KB1234567-x64-ABC.msp against product code: 
{PRODUCT-CODE-GUID}, product version: 6.1.7221.0, product language 1033 and 
upgrade code: {UPGRADE-CODE-GUID}
MSI (c) (84:70) [13:56:08:885]: PATCH SEQUENCER: QFE patch 
C:\acs\KB1234567-x64-ABC.msp is applicable.
MSI (c) (84:70) [13:56:08:887]: SequencePatches returns success.
MSI (c) (84:70) [13:56:08:887]: Final Patch Application Order:
MSI (c) (84:70) [13:56:08:887]: {E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} - 
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisablePatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableFlyWeightPatching' 
is 0
MSI (c) (84:70) [13:56:08:887]: Turning off patch optimization. 
{E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} patch is not authored to support it.
MSI (c) (84:70) [13:56:08:887]: Looking for patch transform: RTM.1
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Feature 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Error 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Binary 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2247 2:  3:  4:
DEBUG: Error 2247:  Database:  Transform stream read/write failure.
1: 2247 2:

Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

Hmm.  Rebuilt with the latest Wix 3.6, and I still get:

Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values
MSI (s) (44:24) [15:10:21:915]: Executing op: 
CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section for 
DirProp
WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS 
DirProperties.
WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox)
Action ended 15:10:22: InstallFinalize. Return value 3.

--
John M. Cooper

-Original Message-
From: John Cooper 
Sent: Wednesday, February 01, 2012 2:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get 
handlers section for DirProp

Wonderful.   Is there an assembly I can take from the Wix 3.6 build and replace 
in the 3.5?  I've got to stay with 3.5 until 3.6 goes RTM.
--
John M. Cooper

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, February 01, 2012 2:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get 
handlers section for DirProp

This sounds very much like a bug that was fixed in WiX v3.6...

On Wed, Feb 1, 2012 at 11:17 AM, John Cooper  wrote:

> Replying to myself:
>
> Commenting out the iis:WebDirProperties element results in a different
> error:
>
> Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and 
> Values MSI (s) (60:E0) [13:13:03:168]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> urce=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get httpErrors 
> section
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS web 
> svc ext.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 
> (note this may not be 100% accurate if translation happened inside
> sandbox) Action ended 13:13:06: InstallFinalize. Return value 3.
>
> --
> John M. Cooper
>
> -Original Message-
> From: John Cooper
> Sent: Wednesday, February 01, 2012 12:45 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed 
> get handlers section for DirProp
>
> I'm getting an install time error during IIS7 Configuration:
>  WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers for DirProp.
>
> This is with Wix 3.5 RTM.
>
> An extract of the verbose log looks like:
>
> Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and 
> Values MSI (s) (F4:74) [12:37:38:134]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> urce=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section 
> for DirProp
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS 
> DirProperties.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 
> (note this may not be 100% accurate if translation happened inside
> sandbox) Action ended 12:37:41: InstallFinalize. Return value 3.
>
> The relevant source looks like:
>
>  
>
>
> Directory="WebsiteFolder">
>  
>   />
>
>  
>  
>
>
>   Win64="yes">
>
> Alias="[XHSAlias]" WebSite="TargetWebSite">
>   BasicAuthentication="yes" Index="yes" Read="yes"
> WindowsAuthentication="yes" />
>   WebAppPool="XHSAppPool" />
>
> Name="ApplicationPoolIdentity" />
> Identity="other" User="XHSAppPoolUser" ManagedPipelineMode="integrated"
> ManagedRuntimeVersion="v4.0" />
>  
>
>  
>
> I'm at a loss how to work around this.
> --
> John Merryweather Cooper
> Build & Install Engineer - ESA
> Jack Henry & Associates, Inc.(r)
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
> NOTICE: This electronic mail message and any files transmitted with it 
> are intended e

[WiX-users] Negative LastSequence number for pyro-generated MSP

2012-02-01 Thread john.burak

Hi all,

We're using Torch/Pyro to create MSP patches for an installer originally
from InstallShield (haven't converted it to Wix yet) and we're ending up
with a negative number for the patch CAB's LastSequence number.  This seems
to cause a 2920 "source directory not specified" error during install.  This
doesn't happen for the installers that we've already converted to Wix.

- Wix 3.5
- MSI schema 301 (according to Orca)
- Windows Installer 5.0

Can anyone shed light on how that LastSequence number is being calculated,
or offer suggestions?

Thanks!

- John Burak

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Negative-LastSequence-number-for-pyro-generated-MSP-tp7244318p7244318.html
Sent from the wix-users mailing list archive at Nabble.com.

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

Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

Wonderful.   Is there an assembly I can take from the Wix 3.6 build and replace 
in the 3.5?  I've got to stay with 3.5 until 3.6 goes RTM.
--
John M. Cooper

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Wednesday, February 01, 2012 2:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get 
handlers section for DirProp

This sounds very much like a bug that was fixed in WiX v3.6...

On Wed, Feb 1, 2012 at 11:17 AM, John Cooper  wrote:

> Replying to myself:
>
> Commenting out the iis:WebDirProperties element results in a different
> error:
>
> Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and 
> Values MSI (s) (60:E0) [13:13:03:168]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> urce=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get httpErrors 
> section
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS web 
> svc ext.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 
> (note this may not be 100% accurate if translation happened inside 
> sandbox) Action ended 13:13:06: InstallFinalize. Return value 3.
>
> --
> John M. Cooper
>
> -Original Message-
> From: John Cooper
> Sent: Wednesday, February 01, 2012 12:45 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed 
> get handlers section for DirProp
>
> I'm getting an install time error during IIS7 Configuration:
>  WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers for DirProp.
>
> This is with Wix 3.5 RTM.
>
> An extract of the verbose log looks like:
>
> Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and 
> Values MSI (s) (F4:74) [12:37:38:134]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So
> urce=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section 
> for DirProp
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS 
> DirProperties.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 
> (note this may not be 100% accurate if translation happened inside 
> sandbox) Action ended 12:37:41: InstallFinalize. Return value 3.
>
> The relevant source looks like:
>
>  
>
>
> Directory="WebsiteFolder">
>  
>   />
>
>  
>  
>
>
>   Win64="yes">
>
> Alias="[XHSAlias]" WebSite="TargetWebSite">
>   BasicAuthentication="yes" Index="yes" Read="yes"
> WindowsAuthentication="yes" />
>   WebAppPool="XHSAppPool" />
>
> Name="ApplicationPoolIdentity" />
> Identity="other" User="XHSAppPoolUser" ManagedPipelineMode="integrated"
> ManagedRuntimeVersion="v4.0" />
>  
>
>  
>
> I'm at a loss how to work around this.
> --
> John Merryweather Cooper
> Build & Install Engineer - ESA
> Jack Henry & Associates, Inc.(r)
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
> NOTICE: This electronic mail message and any files transmitted with it 
> are intended exclusively for the individual or entity to which it is 
> addressed.
> The message, together with any attachment, may contain confidential 
> and/or privileged information.
> Any unauthorized review, use, printing, saving, copying, disclosure or 
> distribution is strictly prohibited. If you have received this message 
> in error, please immediately advise the sender by reply email and 
> delete all copies.
>
> --
>  Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft 
> developers is just $99.99! Visual Studio, SharePoint, SQL - plus 
> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you 
> subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 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

Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

This sounds very much like a bug that was fixed in WiX v3.6...

On Wed, Feb 1, 2012 at 11:17 AM, John Cooper  wrote:

> Replying to myself:
>
> Commenting out the iis:WebDirProperties element results in a different
> error:
>
> Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values
> MSI (s) (60:E0) [13:13:03:168]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get httpErrors section
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS web svc
> ext.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note
> this may not be 100% accurate if translation happened inside sandbox)
> Action ended 13:13:06: InstallFinalize. Return value 3.
>
> --
> John M. Cooper
>
> -Original Message-
> From: John Cooper
> Sent: Wednesday, February 01, 2012 12:45 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get
> handlers section for DirProp
>
> I'm getting an install time error during IIS7 Configuration:
>  WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers for DirProp.
>
> This is with Wix 3.5 RTM.
>
> An extract of the verbose log looks like:
>
> Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values
> MSI (s) (F4:74) [12:37:38:134]: Executing op:
> CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
> MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL:
> C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section for
> DirProp
> WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS
> DirProperties.
> WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
> CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note
> this may not be 100% accurate if translation happened inside sandbox)
> Action ended 12:37:41: InstallFinalize. Return value 3.
>
> The relevant source looks like:
>
>  
>
>
> Directory="WebsiteFolder">
>  
>   />
>
>  
>  
>
>
>   Win64="yes">
>
> Alias="[XHSAlias]" WebSite="TargetWebSite">
>   BasicAuthentication="yes" Index="yes" Read="yes"
> WindowsAuthentication="yes" />
>   WebAppPool="XHSAppPool" />
>
> Name="ApplicationPoolIdentity" />
> Identity="other" User="XHSAppPoolUser" ManagedPipelineMode="integrated"
> ManagedRuntimeVersion="v4.0" />
>  
>
>  
>
> I'm at a loss how to work around this.
> --
> John Merryweather Cooper
> Build & Install Engineer - ESA
> Jack Henry & Associates, Inc.(r)
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
> NOTICE: This electronic mail message and any files transmitted with it are
> intended exclusively for the individual or entity to which it is addressed.
> The message, together with any attachment, may contain confidential and/or
> privileged information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution is strictly prohibited. If you have received this message in
> error, please immediately advise the sender by reply email and delete all
> copies.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
>
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive onl

Re: [WiX-users] Bootstrapper logo in wrong location

UI design changed, documentation was not updated. Bug in the documentation.
Thanks.

On Wed, Feb 1, 2012 at 3:47 AM, Kyle Lee  wrote:

> Hi,
>
> The WIX manual says,
> "The WiX Standard Bootstrapper Application displays a generic logo in the
> bottom left corner of the user interface."
> 
>
> I used this last year (the version was 3.6.1608.0), and yes, the log showed
> up in the bottom left corner of the dialog.
> Now I am using v3.6.2221.0 and it doesn't behave that way any more.
> The logo is always in the top left corner and it only displays the square
> shape, so that if my image is rectangle, it is clipped.
>
> I strongly believe this is a regression.
> If not, can anyone point me what I am missing?
>
> TIA.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



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

Re: [WiX-users] Burn - Moving payload to Cache Directory

Yes, that does sound like a bug that was fixed post-Beta.

On Wed, Feb 1, 2012 at 9:46 AM, Romeo S.  wrote:

> It seems it has been fixed on latest build. I just reproduced it on the
> Beta
> but not in 3.6.2527.0
>
> Cheers,
> Romeo
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243773.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



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

Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

Replying to myself:

Commenting out the iis:WebDirProperties element results in a different error:

Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values
MSI (s) (60:E0) [13:13:03:168]: Executing op: 
CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges:  Error 0x80070057: Failed get httpErrors section
WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS web svc ext.
WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox)
Action ended 13:13:06: InstallFinalize. Return value 3.

--
John M. Cooper

-Original Message-
From: John Cooper 
Sent: Wednesday, February 01, 2012 12:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get 
handlers section for DirProp

I'm getting an install time error during IIS7 Configuration:  
WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers for DirProp.

This is with Wix 3.5 RTM.

An extract of the verbose log looks like:

Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI 
(s) (F4:74) [12:37:38:134]: Executing op: 
CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges:  Error 0x80070057: Failed get handlers section for 
DirProp
WriteIIS7ConfigChanges:  Error 0x80070057: Failed to configure IIS 
DirProperties.
WriteIIS7ConfigChanges:  Error 0x80070057: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this 
may not be 100% accurate if translation happened inside sandbox) Action ended 
12:37:41: InstallFinalize. Return value 3.

The relevant source looks like:

  



  
  

  
  


  


  
  



  

  

I'm at a loss how to work around this.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS  66227
Office:  913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com

NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


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

Re: [WiX-users] Patch building with Torch, all .NET assemblies "changed"

2012-02-01 Thread Brinkmeier, Doug

We are handling this scenario via automated query against a source control 
repository, rather than at a binary level of the compiled output.  We 
investigated compiled output comparison as well, and it just was not a feasible 
solution for us.

We handled this with a service account that checks-in the version # into the 
notes in SVN when a build is performed on our build server.  We keep our build 
server locked-down to contain our "binding" between the compiled output and the 
source code changes.  We use standard naming conventions (project 
 outputs .dll) to make it easy to see which .dlls 
have changed since release X.  It's not perfect, but it works for us.  The keys 
are locking-down the build server, using a service account, and keeping track 
of source-code to binary output mappings (or enforcing a naming convention to 
do this).  We are using SVN as source control and Jenkins as our build server.

Good luck!


-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: Thursday, January 26, 2012 3:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies 
"changed"

When I was at SCX (Microsoft), we went so far as to investigate tools to 
compare only the "code" parts of an assembly--but in the end, that proved too 
cumbersome and unreliable, and so we just lived with the diff's between build.

At ESA-JHA, a significant number of assemblies are checked into source control 
when they are updated using special, manual "promote" builds.  These assemblies 
are thus not rebuilt except when they change--reducing the diff's in builds.  
But, an all-up complete rebuild is also sacrificed by this technique.  There 
are always compromises.

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




-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Thursday, January 26, 2012 3:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies 
"changed"

My initial guess is that your assembly's versions are changing between builds.

I'm very interested in a proposed approach to this as we have a build that 
results in changed versions on every build. I haven't personally investigated 
an approach to handle this yet. I haven't had the time yet to do it.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail

> -Original Message-
> From: john.burak [mailto:john.bu...@telvent.com]
> Sent: Thursday, January 26, 2012 11:00 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Patch building with Torch, all .NET assemblies "changed"
> 
> We recently implemented patch building using Torch/Pyro.  We are 
> keeping the old MSI and totally rebuilding a new one for Torch to diff 
> with.  The problem is that Torch sees all of our .NET assemblies as 
> changed even though the source code only changed in a few.  We did 
> some digging and it turns out that if we recompile an assembly with 
> the same source code, the binary result (DLL or EXE) is different from 
> the first build.  Perhaps it's putting a date stamp inside.  Our guess 
> is that Torch is doing a binary comparison and sees the file as 
> changed.  We need a patch with only the few files who's source code has 
> changed.
> 
> So the question is, how do people handle this situation?  We could try 
> to change our build process so that we don't rebuild every project the 
> second time (let MSBuild pick just the changed ones), but then we won't get 
> "clean"
> builds and we won't detect circular references between assemblies 
> (developers sometimes accidentally do that).  We can limit the impact 
> by doing a non-clean build for only the patch.  This may be the only 
> option, but I wanted to get some opinions first.  Maybe there is something 
> I'm missing here.
> 
> Thanks for your input!
> 
> - John
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Patch-building-with-Torch-all-NET-assembl
> ies-
> changed-tp7227881p7227881.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
>  Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft 
> developers is just $99.99! Visual Studio, SharePoint, SQL - plus 
> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you 
> subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://l

[WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp

I'm getting an install time error during IIS7 Configuration:
WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp.

This is with Wix 3.5 RTM.

An extract of the verbose log looks like:

Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values
MSI (s) (F4:74) [12:37:38:134]: Executing op:
CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for
DirProp
WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS
DirProperties.
WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this
may not be 100% accurate if translation happened inside sandbox)
Action ended 12:37:41: InstallFinalize. Return value 3.

The relevant source looks like:

I'm at a loss how to work around this.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com

NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install issue - wix2010.target line 761

I don't know. Is the %WIX% environment variable set?

I use the HarvestDirectory items instead of the PreBuildEvent property to
use the harvester in 3.5 myself.

-Original Message-
From: Mark Sugrue [mailto:mark.sug...@gmail.com] 
Sent: Wednesday, February 01, 2012 8:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install issue - wix2010.target line 761

I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same
as the old machine. (both are x64 Win7 Pro)

When I try to build the installer on the new machine, I get an odd error
which I don't understand. Nothing on the web seems to match it.

The error isn't in my code, its on line 761 of wix2010.targets

The line is 

I haven't edited this file at all.

The error I get is this:

Error   3       The command ""%WIX%\bin\heat" dir
"D:\Code\products\LE\bin\Debug\Help" -dr HelpFolder -cg HelpComponentGroup
-var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out
"D:\Code\products\LE\Setup\help.wxs.sample""
exited with code 3.     C:\Program Files
(x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets        761     6      
Setup

But the exact same code compiles fine on the old machine.

Is there some setting I need to change maybe?


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


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

Re: [WiX-users] Burn - Moving payload to Cache Directory

2012-02-01 Thread Romeo S.

It seems it has been fixed on latest build. I just reproduced it on the Beta
but not in 3.6.2527.0

Cheers,
Romeo

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243773.html
Sent from the wix-users mailing list archive at Nabble.com.

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

Re: [WiX-users] Visual C++ 2010 Merge Module

That is what the "Common" Program Files directory was created for .
You use it similarly to the non-Common directory, except that components
shared between simultaneously installed products live there. Then there is
never any need to keep track of or even care about a COM object's
installation directory.

Do you build both Product A and Product B with the same (or at least
similar) builds of WiX? If so, your problem as you have designed it would
probably be easier to solve using WIXLIBs instead of MSMs.

Create a WixLib project (instead of a module) of Product A. Even better than
the registry search would be a component search to get the component's
installation directory, but a registry search can be used as well (as long
as you write the registry key). Place that search in the WixLib.

Create two WiX-MSI projects, one for A and the other for B. Both consume
(and depend on) the WixLib for A. The linker (which is not heavily involved
in the the incorporation of MSM content) will be able to arbitrate the
various actions needed between the different parts the installation much
more easily than the binder can, and you will also avoid the issues you are
seeing with trying to force the AppSearch from an MSM.

Blair

-Original Message-
From: Joost van Zoest [mailto:jzo...@siqura.com] 
Sent: Wednesday, February 01, 2012 5:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Visual C++ 2010 Merge Module

Hi Blair,

Thanks for your reply. Let me explain the reason why we're using the
registry search inside the MSM.
We have a product containing a COM object, let's call this product A. We
also have a product which is using the COM object of product A, let's call
this one product B. We've made both an installer and a MSM of product A. And
the installer of product B embeds the MSM of product A.
Then we released product B, and later decided to change the installation
directory for product A. When someone installs product B, the COM object is
registered in the old path. When he installs product A afterwards, the old
registration is overwritten with the new location of the product A binaries.
If he uninstalls product A, the registry gets corrupted because the COM
registration still points to the new location, while the binaries installed
by product B are located in the old location.

To overcome this problem, we wanted to let both the installer and MSM of
product A write a registry key containing the install directory. When either
the installer, or MSM, gets installed, it will first try to retrieve the
install directory from the registry to make sure it will install the
binaries to the same directory when the product is already installed. As it
seems, this registry search is not working very well inside the MSM.

Given our problem, does someone have an idea on how to deal with this?
We also thought about stopping using MSM's, but the disadvantage of
embedding the product A installer inside the product B installer is that
product A is not refcounted. So when product B gets uninstalled, it cannot
tell whether or not it should remove product A as well.

All ideas are appreciated! Thanks!


-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Tuesday, January 31, 2012 4:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Visual C++ 2010 Merge Module


Several action don't seem to be intended to be found in MSMs. Maybe
AppSearch is one of them.

Do you distribute your MSM publically? If not, I've got a couple of
ideas.
1) Run a couple of SQL queries against the MSM to remove them from the
two Module*Sequence tables. 2) Change from using MSMs and instead
generate/consume WixLibs instead.

If you do distribute MSMs publically then each idea I have has
limitations.

-Original Message-
From: Joost van Zoest [mailto:jzo...@siqura.com]
Sent: Tuesday, January 31, 2012 6:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Visual C++ 2010 Merge Module

I've validated my MSM in Orca. At first, I got a lot of ICE33 warnings
because of some COM registration logic. To rule out that this was
causing my problems, I removed this registration logic and validated the
MSM again. Now the validation completes, but ends with:
Execution   ERROR   There is a problem with this Windows Installer
package. A DLL required for this install to complete could not be run.
Contact your support personnel or package vendor.  

I'm using Orca with the darice.cub of WIX 3.6 BETA

Looking further in Orca, I saw 2 tables (ModuleInstallExecuteSequence
and
ModuleInstallUISequence) which both contained an action called AppSearch
with a Sequence of 50. I guess the actions of these tables are moved to
the InstallExecuteSequence and InstallUISequence tables when you embed
this merge module into an installer. So could this be the cause of the
warnings I see when I build my installer?

Somewhere in my merge module I perform a re

[WiX-users] Install issue - wix2010.target line 761

2012-02-01 Thread Mark Sugrue

I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything
the same as the old machine. (both are x64 Win7 Pro)

When I try to build the installer on the new machine, I get an odd
error which I don't understand. Nothing on the web seems to match it.

The error isn't in my code, its on line 761 of wix2010.targets

The line is 

I haven't edited this file at all.

The error I get is this:

Error   3       The command ""%WIX%\bin\heat" dir
"D:\Code\products\LE\bin\Debug\Help" -dr HelpFolder -cg
HelpComponentGroup -var var.HelpDir -srd -gg -sfrag -suid
-template:fragment -out "D:\Code\products\LE\Setup\help.wxs.sample""
exited with code 3.     C:\Program Files
(x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets        761     6       Setup

But the exact same code compiles fine on the old machine.

Is there some setting I need to change maybe?

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

Re: [WiX-users] How does Torch decide which files changed?!

If the only changes in your bug fix are files in the file table, that should
work. To rebuild your code you may consider using dark on your released MSI
to get your base WIXPDB and to get your starting point for your bug fix.

The REINSTALL property will be autoselected to be the smallest section of
already installed features that cover all of the database changes contained
in the patch if you don't override it (as you are proposing). Normally the
default value should suffice, unless you have a complex feature/component
tree or if you have files that don't lend themselves well to the file
versioning rules.

Your overridden value for REINSTALLMODE property will prevent application of
registry and shortcuts from the patched view. If you don't have a
requirement for the "a" flag, the default should suffice.

Blair

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] 
Sent: Wednesday, February 01, 2012 12:26 AM
To: wix-users@lists.sourceforge.net
Cc: alex...@qualisystems.com; rone...@qualisystems.com
Subject: Re: [WiX-users] How does Torch decide which files changed?!

Hi,
After all your help :) I think I have a solution to my problem, please let
me know what you think:
My product is already installed on customers machines, I didn't save the
wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I
didn't know I'll need them to issue a patch, I also don't have the product
Id since it's * (auto generated).

So, I need to rebuild my code and create the MSIs again with the same code
as the released product making sure I hard code the Original Product Id I
take from the released MSI.
Then I make my changes (fix the bug or whatever) and rebuild my code and
create the MSIs again MAKING SURE to use the same files.wxs created by the
previous HEAT harvest (so the GUIDS will be the same).

Now I have both wixpdb files without the change and with the change.
I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I
pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst
-v)

The customer needs to install the msp with this command:
MSIEXEC /update "\\tomer-c-d3\Share\patch.msp" REINSTALL=ALL REINSTALLMODE=a

It seems a bit cumbersome, will it work? :) Thanks again.

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, January 30, 2012 9:51 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How does Torch decide which files changed?!

One way to see what the transforms in a patch actually contain WRT any
particular MSI, open the MSI in Orca, then open the MSP file using the
Transform menu item "View a patch". It will highlight the database changes,
and in the case of files, you can look at the two file-related tables to see
which files it thinks have been changed.

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: Saturday, January 28, 2012 10:59 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How does Torch decide which files changed?!

One more thing, I opened the msp file with z7, there are only: exe dll (.net
assemblies) and one txt file!? there.

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, January 27, 2012 10:24 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How does Torch decide which files changed?!

Torch marks up the database changes. Including -p causes it to leave the
unchanged portions of the database intact so they will be present for Pyro
to use in its processing.

It is Pyro that looks at the two files and determines if they are the same
or not, and it "promotes" files that compare as different to be considered
as "changed" and thus be included with the other marked database changes.

If you use WIXOUT or WIXPDB files then fragment boundaries are considered in
the comparisons, so if you specify references to things to include in your
patch family/families, things that are not in any referenced fragments are
ignored (by design).

Look for the files you are concerned with in the WIXMST file. You should
find either paths or references to cabinet-ids for both the updated and the
previous versions of the files.

Blair

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: Thursday, January 26, 2012 7:19 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How does Torch decide which files changed?!

I'm creating a patch, I'm not sure that the patch includes all of my files
even though I'm passing the -p flag to the torch.exe.
Can someone please explain to me the logic that torch uses to determine what
files are included in the patch.
Thanks.



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

Re: [WiX-users] msp patch does not update one of files