wix-devs — Windows Installer XML toolset developer mailing list

[WiX-devs] WiX Online Meeting #53

[Rob M. <ro...@fi...>]

Next WiX Online meeting will be: January 22nd, 2015 @10:00AM PST

Agenda items:

*       Triage
*       WiX v3.9 R2 Release

.........................................................................................................................................
--> Join Lync Meeting<https://meet.lync.com/firegiant/rob/QK85PW8J>

Help<http://go.microsoft.com/fwlink/?LinkId=389737>

[!OC([1033])!]
.........................................................................................................................................

Re: [WiX-devs] Fw: Problems with Wix and MSBuild32 but not MSBuild64

[David J R. <dj...@ra...>]

All,

I did resolve this by adding  loadFromRemoteSources to MSBuild.exe.config.

Dave




From:	David J Ryan <dj...@ra...>
To:	wix...@li...
Date:	01/21/2015 06:20 PM
Subject:	[WiX-devs] Fw: Problems with Wix and MSBuild32 but not
            MSBuild64



All,

I'm having a problem with integrating Wix with MSBuild32 with the latest
msbuild tools 12.0. MSBuild crashes with the following exception only with
the 32-bit version of msbuild. The 64-bit version does not do this.

I have followed the instructions at the website Integrating WiX Projects
Into Daily Builds according to this pattern. First I copied the
wix39-binaries.zip to a folder directly under the root of our source tree $
(SourceCodeControlRoot)\wix\3.9. I then had to make a copy of the sdk
folder and put it at this location $(SourceCodeControlRoot)\wix\sdk.
I set the environment variables and everything works great with msbuild64
but crashes each time with msbuild32.


<PropertyGroup>
     <WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
     <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
     <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>

Thanks,
Dave

  Correlator -> C:\workspace\TIP\Deliverables\Correlator.root\Correlator
\CorrelatorProcessor\bin\x64\Release\CorrelatorProcessor.exe
  DataTransferAgentGui -> C:\workspace\TIP\Deliverables
\DataTransferAgentGui.root\DataTransferAgentGui\DataTransferAgentGui\bin
\x64\Release\DataTransferAgentGui.exe
  Could not load file or assembly 'file:///c:\workspace\TIP\deliverables
\wix\3.9\candle.exe' or one of its dependencies. Operation is not
supported. (Exception from HRESULT: 0x80131515)
     at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName
(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly
reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.InternalLoadFrom(String
assemblyFile, Evidence securityEvidence, Byte[] hashValue,
AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean
suppressSecurityChecks, StackCrawlMark& stackMark)
     at System.Reflection.Assembly.LoadFrom(String assemblyFile)
     at
Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread
(Object parameters)


Unhandled Exception: System.IO.FileLoadException: Could not load file or
assembly 'file:///c:\workspace\TIP\deliverables\wix\3.9\candle.exe' or one
of its dependencies. Operation is not supported. (Exception from HRESULT:
0x80131515) ---> System.NotSupportedException: An attempt was made to load
an assembly from a network location which would have caused the assembly to
be sandboxed in previous versions of the .NET Framework. This release of
the .NET Framework does not enable CAS policy by default, so this load may
be dangerous. If this load is not intended to sandbox the assembly, please
enable the loadFromRemoteSources switch. See
http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
   --- End of inner exception stack trace ---
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName
(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly
reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String
assemblyFile, Evidence securityEvidence, Byte[] hashValue,
AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean
suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at
Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread
(Object parameters)
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart(Object obj)


      Regards,
                                        
                                        
                                        
       David J Ryan           CCNA      
       Principal                        
       Systems Engineer                 
       ENGINEERING                      
       HTMS System                      
       Engineering - SE                 
       Network Centric                  
       Systems                          
       Raytheon Company                 
                                        

      ------------------------------------------------------------------------------

      New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
      GigeNET is offering a free month of service with a new server in
      Ashburn.
      Choose from 2 high performing configs, both with 100TB of bandwidth.
      Higher redundancy.Lower latency.Increased capacity.Completely
      compliant.
      http://p.sf.net/sfu/gigenet
      _______________________________________________
      WiX-devs mailing list
      WiX...@li...
      https://lists.sourceforge.net/lists/listinfo/wix-devs

[WiX-devs] Fw: Problems with Wix and MSBuild32 but not MSBuild64

[David J R. <dj...@ra...>]

All,

I'm having a problem with integrating Wix with MSBuild32 with the latest
msbuild tools 12.0. MSBuild crashes with the following exception only with
the 32-bit version of msbuild. The 64-bit version does not do this.

I have followed the instructions at the website Integrating WiX Projects
Into Daily Builds according to this pattern. First I copied the
wix39-binaries.zip to a folder directly under the root of our source tree $
(SourceCodeControlRoot)\wix\3.9. I then had to make a copy of the sdk
folder and put it at this location $(SourceCodeControlRoot)\wix\sdk.
I set the environment variables and everything works great with msbuild64
but crashes each time with msbuild32.


<PropertyGroup>
      <WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
      <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
      <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>

Thanks,
Dave

  Correlator -> C:\workspace\TIP\Deliverables\Correlator.root\Correlator
\CorrelatorProcessor\bin\x64\Release\CorrelatorProcessor.exe
  DataTransferAgentGui -> C:\workspace\TIP\Deliverables
\DataTransferAgentGui.root\DataTransferAgentGui\DataTransferAgentGui\bin
\x64\Release\DataTransferAgentGui.exe
  Could not load file or assembly 'file:///c:\workspace\TIP\deliverables
\wix\3.9\candle.exe' or one of its dependencies. Operation is not
supported. (Exception from HRESULT: 0x80131515)
     at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName
(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly
reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
     at System.Reflection.RuntimeAssembly.InternalLoadFrom(String
assemblyFile, Evidence securityEvidence, Byte[] hashValue,
AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean
suppressSecurityChecks, StackCrawlMark& stackMark)
     at System.Reflection.Assembly.LoadFrom(String assemblyFile)
     at
Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread
(Object parameters)

Unhandled Exception: System.IO.FileLoadException: Could not load file or
assembly 'file:///c:\workspace\TIP\deliverables\wix\3.9\candle.exe' or one
of its dependencies. Operation is not supported. (Exception from HRESULT:
0x80131515) ---> System.NotSupportedException: An attempt was made to load
an assembly from a network location which would have caused the assembly to
be sandboxed in previous versions of the .NET Framework. This release of
the .NET Framework does not enable CAS policy by default, so this load may
be dangerous. If this load is not intended to sandbox the assembly, please
enable the loadFromRemoteSources switch. See
http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
   --- End of inner exception stack trace ---
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName
(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly
reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String
assemblyFile, Evidence securityEvidence, Byte[] hashValue,
AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean
suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at
Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread
(Object parameters)
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart(Object obj)



Regards,
                                   
                                   
                                   
  David J Ryan           CCNA      
  Principal Systems                
  Engineer                         
  ENGINEERING                      
  HTMS System                      
  Engineering - SE                 
  Network Centric                  
  Systems                          
  Raytheon Company                 
                                   

[WiX-devs] Fw: MSBuild and Wix

[David J R. <dj...@ra...>]

All,

I"m trying to get Wix to work as in a build server capacity, however it
seems that I cannot get this to happen successfully unless Wix is installer
with Visual Studio. I followed all the instructions to deploy Wix in source
control but when I uninstall Wix it always fails with the following errors.
This is a customs action DLL that is trying to compile. Wix binaries and
SDK are copied and referenced as: I did get past a previous error by adding
an entry to the MSBuild.exec.config file but now I'm left with this error.

<PropertyGroup>
      <WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
      <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
      <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>


  CmosImageProcessor11 -> C:\workspace\TIP\Deliverables
\CmosImageProcessor11\bin\x64\Release\CmosImageProcessor.exe
  ProcessMonitor -> C:\workspace\TIP\Deliverables\ProcessMonitor.root
\ProcessMonitor\ProcessMonitor\bin\x64\Release\ProcessMonitor.exe
  CmosImageProcessor04 -> C:\workspace\TIP\Deliverables
\CmosImageProcessor04\bin\x64\Release\CmosImageProcessor.exe
  PositiveListHandler -> C:\workspace\TIP\Deliverables
\PositiveListHandler.root\PositiveListHandler\PositiveListHandler\bin\x64
\Release\Raytheon.Highways.PositiveListHandler.dll
  CmosImageProcessor12 -> C:\workspace\TIP\Deliverables
\CmosImageProcessor12\bin\x64\Release\CmosImageProcessor.exe
C:\Program Files (x86)\MSBuild\12.0\bin
\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could
not resolve this reference. Could not locate the assembly
"Microsoft.Deployment.WindowsInstaller". Check to make sure the assembly
exists on disk. If this reference is required by your code, you may get
compilation errors. [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(21,17): error CS0234: The type or namespace name
'Deployment' does not exist in the namespace 'Microsoft' (are you missing
an assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(33,61): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(33,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(113,54): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(113,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(158,55): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(158,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(203,54): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(203,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(219,57): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(219,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(246,60): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(246,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(271,58): error CS0246: The type or namespace name 'Session'
could not be found (are you missing a using directive or an assembly
reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(271,23): error CS0246: The type or namespace name
'ActionResult' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(32,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(32,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(112,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(112,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(157,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(157,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(202,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(202,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(218,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(218,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(245,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(245,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
CustomAction.cs(270,10): error CS0246: The type or namespace name
'CustomAction' could not be found (are you missing a using directive or an
assembly reference?) [C:\workspace\TIP\Deliverables\SecurityActions
\SecurityActions.csproj]
CustomAction.cs(270,10): error CS0246: The type or namespace name
'CustomActionAttribute' could not be found (are you missing a using
directive or an assembly reference?) [C:\workspace\TIP\Deliverables
\SecurityActions\SecurityActions.csproj]
  .NETFramework,Version=v4.5.AssemblyAttributes.cpp
     Creating library C:\workspace\TIP\Deliverables\ARImageProcessing
\ARImageProcessing\x64\Release\ARImageProcessing.lib and object
C:\workspace\TIP\Deliverables\ARImageProcessing\ARImageProcessing\x64
\Release\ARImageProcessing.exp
  Generating code
  TipManagementService.BusinessLogic -> C:\workspace\TIP\Deliverables
\TipManagementServices.root\TipManagementServices\TipManagementService
\Source\Business Logic\TipManagementService.BusinessLogic\bin\x64\Release
\Raytheon.Highways.TipManagementService.BusinessLogic.dll
  Finished generating code


Regards,
                                   
                                   
                                   
  David J Ryan           CCNA      
  Principal Systems                
  Engineer                         
  ENGINEERING                      
  HTMS System                      
  Engineering - SE                 
  Network Centric                  
  Systems                          
  Raytheon Company                 
                                   



+1 714.446.2126   (office)
+1 714.276.4648   (cell)
789-2126   (tie line)
dj...@ra...

1801 Hughes Drive
Fullerton, CA 92833 USA
www.raytheon.com

Follow Raytheon On
Twitter YouTube Facebook LinkedIn

Raytheon Sustainability

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this
message in error, please so advise the sender by reply e-mail and delete
this message. Thank you for your cooperation.

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Rob M. <ro...@fi...>]

Isn't this what we're discussing? Different ways to solve the patching problem? I totally agree we haven't hit consensus. We've worked our way to a big question, the "higher level model" in Bob's words, of how to make patching really work, instead of the disconnected set of tools we use today. I suggested we maybe should consider the MSBuild targets to get there and I think Bob agreed that's a good place to start...

Sorry if the process takes a little bit to get there. Patching is both one of the hardest parts of the Windows Installer and the least developed in the WiX toolset. I expect we still have quite a bit of ground to cover to get to an answer.  Do you agree?

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

From: Tunney, Stephen [mailto:Ste...@nu...]
Sent: Wednesday, January 21, 2015 9:29 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Ok, so I need some way to meet a consensus here as to the "plan" between you two since you are the primary stakeholders in all of this.  I'm just a squirrel with a nut!


1)      Create new tools that does the extraction, remove this functionality completely from Dark and Melt

2)      Consolidate extraction functionality into ONLY ONE of the two tools (ie. Dark could extract, Melt would update wixpdbs accordingly ONLY for an MSI, MSM functionality would not change)

3)      Have common code that both tools call in DTF

4)      Do nothing :(


From: Bob Arnson [mailto:bo...@jo...]
Sent: January-20-15 3:24 PM
To: wix...@li...<mailto:wix...@li...>
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 20-Jan-15 14:54, Stephen Tunney wrote:
I think one less executable would be a good thing.  Less code to maintain, etc. etc.
Adding modes makes more complicated code and the only thing you've saved is the "shell" work in having an additional project.

--

sig://boB

http://joyofsetup.com/

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Tunney, S. <Ste...@nu...>]

Ok, so I need some way to meet a consensus here as to the "plan" between you two since you are the primary stakeholders in all of this.  I'm just a squirrel with a nut!


1)      Create new tools that does the extraction, remove this functionality completely from Dark and Melt

2)      Consolidate extraction functionality into ONLY ONE of the two tools (ie. Dark could extract, Melt would update wixpdbs accordingly ONLY for an MSI, MSM functionality would not change)

3)      Have common code that both tools call in DTF

4)      Do nothing :(


From: Bob Arnson [mailto:bo...@jo...]
Sent: January-20-15 3:24 PM
To: wix...@li...
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 20-Jan-15 14:54, Stephen Tunney wrote:

I think one less executable would be a good thing.  Less code to maintain, etc. etc.
Adding modes makes more complicated code and the only thing you've saved is the "shell" work in having an additional project.


--

sig://boB

http://joyofsetup.com/

Re: [WiX-devs] 4632 - Use ETW for logging and additional tracing

[Rob M. <ro...@fi...>]

Honestly, the way the numbers are going… I don’t know when we drop support for XP SP3. <sigh/>

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

From: Sean Hall [mailto:r.s...@gm...]
Sent: Tuesday, January 20, 2015 8:15 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] 4632 - Use ETW for logging and additional tracing

I was reading through the issue here<http://wixtoolset.org/issues/4632/> and the WIP<http://wixtoolset.org/development/wips/4632-use-etw-for-logging/> and it sounds like the goal is to use EventWrite<https://msdn.microsoft.com/library/windows/desktop/aa363752.aspx> as the foundation for logging in 4.x.  As noted in the WIP, EventWrite was introduced in Vista/2008.

Are we planning on dropping support for XP in 4.x?  Does that mean we should bump up to .NET 4.5?

If we're still releasing v4.0 in the next few months, I don't think XP has been end of lifed for long enough to do that.

[WiX-devs] 4632 - Use ETW for logging and additional tracing

[Sean H. <r.s...@gm...>]

I was reading through the issue here <http://wixtoolset.org/issues/4632/> and
the WIP <http://wixtoolset.org/development/wips/4632-use-etw-for-logging/> and
it sounds like the goal is to use EventWrite
<https://msdn.microsoft.com/library/windows/desktop/aa363752.aspx> as the
foundation for logging in 4.x.  As noted in the WIP, EventWrite was
introduced in Vista/2008.

Are we planning on dropping support for XP in 4.x?  Does that mean we
should bump up to .NET 4.5?

If we're still releasing v4.0 in the next few months, I don't think XP has
been end of lifed for long enough to do that.

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Bob A. <bo...@jo...>]

On 20-Jan-15 14:54, Stephen Tunney wrote:
> I think one less executable would be a good thing.  Less code to 
> maintain, etc. etc.
Adding modes makes more complicated code and the only thing you've saved 
is the "shell" work in having an additional project.

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

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Bob A. <bo...@jo...>]

On 20-Jan-15 14:19, Rob Mensching wrote:
> We have light and lit today because C/C++ has link.exe/lib.exe. If someone wanted to argue that we should get rid of lit.exe and just make light.exe the tool that outputs build stuff, I could see that. Lit *is* different because it doesn't do linking or binding which makes it different beastie...
I'd rather have more, smaller tools than bigger tools with confusing modes.

> Okay. What do you mean "higher-level model"? We need to do lots of work in the build .targets alone to span builds and such to support patching but I'm not sure that's what you'd mean by "higher-level model".
Maybe that's it. It's not clear to me how to fit together the 
torch+torch+torch+pyro model with what Melt does today. If it's all 
input into a set of targets that coordinates it all, maybe that works. 
That's not something the targets really do today (apart from the whole 
loc thing).

But even then, I assume the targets would still wrap executables, so 
getting that right is a good thing.

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

Re: [WiX-devs] Issue #4206 - Firewall port list or range not possible #132

[Norbert S. <nor...@on...>]

Somehow this mail came not through to the mailing list the first time:

 

Any number between 1 and 65535 is valid or any range by these numbers seperated by hyphen or any combination of these seperated by comma.

Is validation necessary? I have only seen this validation where only specific words are allowed.

 

E.g. registry extension doesn't check the parameters.

Also the current firewall port code doesn't check if the number is between 1 and 65535.

 

From: Rob Mensching [mailto:ro...@fi...] 
Sent: Sunday, January 4, 2015 02:50 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Issue #4206 - Firewall port list or range not possible #132

 

Left my one comment. Is there really no validation of the port list required?

 

_______________________________________________________________

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

 

From: Norbert Schulze [mailto:nor...@on...] 
Sent: Thursday, December 11, 2014 11:42 AM
To: 'WiX toolset developer mailing list'
Subject: [WiX-devs] Issue #4206 - Firewall port list or range not possible #132

 

Is there any chance that my pull request will be included in wix3 and wix4 in the near future?

 

 <https://github.com/wixtoolset/wix3/pull/132> https://github.com/wixtoolset/wix3/pull/132

 

Regards, Norbert

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Stephen T. <ste...@gm...>]

Ok, just from the emails I'm seeing a pattern here of a design smell.
WiX has two tools that "deconstruct a database".  Dark generates source
code and a flat folder structure.  Melt updates an existing wixpdb and a
tiered folder structure.

Perhaps I'm barking up the wrong tree.  I dunno.  I just think that it
would be *really* nice to have one tool (dark, melt, or a new tool) that
generates the folder structure AND one or both of the other two pieces of
functionality.

The issue I have with moving ONLY the database extraction to one of the two
tools is now we have a disconnect between how the Files/Binary/Icon folders
land on disk and how the wixpdb or wxs (melt or dark respectively) gets
updated.

Dark could do ALL three of these things.  I don't think that anyone would
complain about Dark being able to handle deconstructing a WiX generated
installer.  It was mentioned that it is intended to be used when moving
from an alien (ahem, InstallShiteld) but what if someone lost the original
WiX source for an installer?  Dark is awesome BTW.

It just seems to me like this is a three-sided pyramid of functionality and
we have two tools that do the base (differently) and then they each take
care of one of the two sides on their own.
I think one less executable would be a good thing.  Less code to maintain,
etc. etc.

I love stirring the pot.  This is fun :)

On Tue Jan 20 2015 at 14:20:11 Rob Mensching <ro...@fi...> wrote:

> We have light and lit today because C/C++ has link.exe/lib.exe. If someone
> wanted to argue that we should get rid of lit.exe and just make light.exe
> the tool that outputs build stuff, I could see that. Lit *is* different
> because it doesn't do linking or binding which makes it different beastie...
>
> Okay. What do you mean "higher-level model"? We need to do lots of work in
> the build .targets alone to span builds and such to support patching but
> I'm not sure that's what you'd mean by "higher-level model".
>
> _______________________________________________________________
>  FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
> -----Original Message-----
> From: Bob Arnson [mailto:bo...@jo...]
> Sent: Tuesday, January 20, 2015 10:46 AM
> To: wix...@li...
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> On 19-Jan-15 16:13, Rob Mensching wrote:
> > I'm really not at all excited about *another* tool in v4.
> Why do we have Light and Lit? :)
> > I guess that's where I'd like to see this in v4 (or later if it can't
> make v4): patching should operate off the standard build output: msi,
> external cabs/files, and .wixpdb. If we can't patch from that, we should
> enhance what we're outputting to patch it.
> The current model seems like a bad fit for magicking the .wixpdbs. I think
> we need a higher-level model to squeeze that in. I'm not at all opposed to
> that, fwiw. :)
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------
> ------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------
> ------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Rob M. <ro...@fi...>]

We have light and lit today because C/C++ has link.exe/lib.exe. If someone wanted to argue that we should get rid of lit.exe and just make light.exe the tool that outputs build stuff, I could see that. Lit *is* different because it doesn't do linking or binding which makes it different beastie...

Okay. What do you mean "higher-level model"? We need to do lots of work in the build .targets alone to span builds and such to support patching but I'm not sure that's what you'd mean by "higher-level model".

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

-----Original Message-----
From: Bob Arnson [mailto:bo...@jo...] 
Sent: Tuesday, January 20, 2015 10:46 AM
To: wix...@li...
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 19-Jan-15 16:13, Rob Mensching wrote:
> I'm really not at all excited about *another* tool in v4.
Why do we have Light and Lit? :)
> I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.
The current model seems like a bad fit for magicking the .wixpdbs. I think we need a higher-level model to squeeze that in. I'm not at all opposed to that, fwiw. :)

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


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Bob A. <bo...@jo...>]

On 19-Jan-15 16:13, Rob Mensching wrote:
> I'm really not at all excited about *another* tool in v4.
Why do we have Light and Lit? :)
> I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.
The current model seems like a bad fit for magicking the .wixpdbs. I 
think we need a higher-level model to squeeze that in. I'm not at all 
opposed to that, fwiw. :)

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

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Rob M. <ro...@fi...>]

The purpose of the tools today are:


1.       dark.exe – decompile stuff back into source code. The ideal is perfectly round trippable source code but we’ve been lazy with bundles since no one really needs to round trip a bundle today. Of course, round tripping MSIs/MSMs is very important when converting from one MSI/MSM creation technology to the WiX toolset.


2.       melt.exe – make unpatchable stuff patchable. It started by transforming Merge Modules into .wixlibs because Merge Modules are not patchable but .wixlibs are. Later melt.exe was taught to update paths in .wixpdbs for those that did not use bind paths everywhere.

IMHO, those two tools serve different purposes today. They certainly share code underneath (pulling files out of the “MergeModule.CABinet”, for example) but I’m not sure that makes them the same tool.

For example, if you did “dark.exe foo.wixpdb –o output” today, I’d expect an “output” folder to be created with a bunch of .wxs code that I could compile with candle.exe. And today, “dark.exe foo.msm –o output” creates a bunch of .wxs files in the “output” folder... it does not create a .wixlib the way melt.exe does.

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

From: Stephen Tunney [mailto:ste...@gm...]
Sent: Monday, January 19, 2015 4:19 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching


I think at the end of the day we need to consolidate functionality as we have two tools that do the exact same thing (more or less).

Dark should be defined as a tool that deconstructs a database (msi or msm) into a wxs + exportable tables.  If this is the case then melt's functionality should be truncated to limit it to modifying the wixpdb.  Or melt essentially gets dropped and that wixpdb modification is put into dark if the wixpdb is supplied.

Having two tools that essentially do the same thing makes little sense and confuses patching which is what we want to get away from.

Stephen

On Mon, 19 Jan 2015 16:14 Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote:
I'm really not at all excited about *another* tool in v4. I'd much rather we be able to use the MSI and the cabs as the source without having to preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best place for it but you only use it to optimize the process. Otherwise, the patch unbinder stuff can just use the original build output.

I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.

Having to think ahead makes in so many different ways makes patching terribly unapproachable.

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

-----Original Message-----
From: Tunney, Stephen [mailto:Ste...@nu...<mailto:Ste...@nu...>]
Sent: Monday, January 5, 2015 8:01 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [bo...@jo...<mailto:bo...@jo...>]
Sent: January 5, 2015 10:51 PM
To: wix...@li...<mailto:wix...@li...>
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt extracts to a source tree, which makes it easier to update. Plus Melt does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was who had that idea, I certainly can't remember.) It mixes two very different things. Adding the functionality to Dark is a little better but not by much. (Dark is *mostly* about decompiling; extraction is something else tacked on.) I think it would make it easier to discover the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:
> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [bo...@jo...<mailto:bo...@jo...>]
> Sent: January 5, 2015 6:51 PM
> To: wix...@li...<mailto:wix...@li...>
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch> -xb (extract binaries,
>> does not get squashed by -sextract and uses old path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update
> their scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...<mailto:WiX...@li...>
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...<mailto:WiX...@li...>
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

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


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

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

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
WiX...@li...<mailto:WiX...@li...>
https://lists.sourceforge.net/lists/listinfo/wix-devs

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Sean H. <r.s...@gm...>]

10:00 AM Pacific or 3:00 PM Pacific works for me

On Mon, Jan 19, 2015 at 3:09 PM, Rob Mensching <ro...@fi...> wrote:

>  An hour earlier won’t help much. It’d have to be probably 3 hours
> earlier (6:00 AM PST) to have any hope of not being interrupted by life
> here. <smile/>
>
>
>
> However, it seems like many are interested in taking it back an hour
> (10:00 AM PST). That’s the time we had two weeks ago.
>
>
>
> Just for discussion, what about Tuesday 3:00 PM PST?  That’s a very
> different time slot and probably hits east coasters at a poor time.
> Thoughts?
>
>
>
> _______________________________________________________________
>
> FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
>
>
> *From:* Hoover, Jacob [mailto:Jac...@gr...]
> *Sent:* Monday, January 19, 2015 7:44 AM
> *To:* WiX toolset developer mailing list
> *Subject:* Re: [WiX-devs] WiX Online Meeting time in 2015?
>
>
>
> An hour earlier or later would be fine by me (if that helps at all).
>
>
>
>
>
> *From:* Rob Mensching [mailto:ro...@fi... <ro...@fi...>]
> *Sent:* Sunday, January 18, 2015 1:53 AM
> *To:* WiX toolset developer mailing list
> *Subject:* [WiX-devs] WiX Online Meeting time in 2015?
>
>
>
> Greetings,
>
>
>
> Last year our weekly meeting was regularly scheduled at 9:00 AM PST on
> Thursdays. Due to changes in life, 9:00 AM PST is turning out to be very
> challenging for me to attend regularly. Thus I’d like to move the meeting
> time to another timeslot.
>
>
>
> Of course, no time slot can be perfect but we’d like to accommodate as
> many people as possible. So, does anyone have suggestions or
> anti-suggestions (time that will never work)?
>
>
>
> _______________________________________________________________
>
> FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Stephen T. <ste...@gm...>]

I think at the end of the day we need to consolidate functionality as we
have two tools that do the exact same thing (more or less).

Dark should be defined as a tool that deconstructs a database (msi or msm)
into a wxs + exportable tables.  If this is the case then melt's
functionality should be truncated to limit it to modifying the wixpdb.  Or
melt essentially gets dropped and that wixpdb modification is put into dark
if the wixpdb is supplied.

Having two tools that essentially do the same thing makes little sense and
confuses patching which is what we want to get away from.

Stephen

On Mon, 19 Jan 2015 16:14 Rob Mensching <ro...@fi...> wrote:

> I'm really not at all excited about *another* tool in v4. I'd much rather
> we be able to use the MSI and the cabs as the source without having to
> preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe
> is the best place for it but you only use it to optimize the process.
> Otherwise, the patch unbinder stuff can just use the original build output.
>
> I guess that's where I'd like to see this in v4 (or later if it can't make
> v4): patching should operate off the standard build output: msi, external
> cabs/files, and .wixpdb. If we can't patch from that, we should enhance
> what we're outputting to patch it.
>
> Having to think ahead makes in so many different ways makes patching
> terribly unapproachable.
>
> _______________________________________________________________
>  FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
> -----Original Message-----
> From: Tunney, Stephen [mailto:Ste...@nu...]
> Sent: Monday, January 5, 2015 8:01 PM
> To: WiX toolset developer mailing list
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> Also, I would say that we should do the *least* amount of work in v3 (ie.
> adding a simple switch to melt).
>
> I could work on newtool.exe in v4 in my spare time.
> ________________________________________
> From: Bob Arnson [bo...@jo...]
> Sent: January 5, 2015 10:51 PM
> To: wix...@li...
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> Dark extracts to a flat list of files named after their ids. Melt extracts
> to a source tree, which makes it easier to update. Plus Melt does the
> .wixpdb updating.
>
> Putting the extraction/updating in Melt was a bad idea. (Whoever it was
> who had that idea, I certainly can't remember.) It mixes two very different
> things. Adding the functionality to Dark is a little better but not by
> much. (Dark is *mostly* about decompiling; extraction is something else
> tacked on.) I think it would make it easier to discover the patching
> benefits if it were its own tool.
>
> To be honest, if you wanted to do that for v4, it could start in v3:
> Leave Melt.exe alone, copy the extraction/updating code to NewTool, add
> the Binary extraction, and merge it (almost) as-is to v4.
>
> The only downside: It will take significant research, discussion, and
> heated debate to come up with a new tool name...
>
> On 05-Jan-15 22:21, Tunney, Stephen wrote:
> > Quick side question for 4.x
> >
> > Why do we have melt AND dark?  The two of you seem to want them to act
> the same, don't they really do the same thing (decompile a MS* database)?
> Melt updates/generates a .wixpdb as well which is the only real difference
> I can see.
> >
> > Should it be considered to merge the two tools together perhaps?  Just a
> thought exercise perhaps but the questions you two both raised have put a
> smell in my nose.
> > Stephen
> > ________________________________________
> > From: Bob Arnson [bo...@jo...]
> > Sent: January 5, 2015 6:51 PM
> > To: wix...@li...
> > Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> > table for patching
> >
> > On 03-Jan-15 20:36, Stephen Tunney wrote:
> >> Ok, so here's my pitch:
> >>
> >> v3.x would get a couple of new flags
> >> -xn (extract in new directory format) <patch> -xb (extract binaries,
> >> does not get squashed by -sextract and uses old path format) <path>
> > Do we need both? I like -xn -- subdirectories for files and binaries a
> > la Dark, right? That provides binaries and prompts users to update
> > their scripts and/or existing melt output.
> >
> > --
> > sig://boB
> > http://joyofsetup.com/
> >
> >
> > ----------------------------------------------------------------------
> > -------- Dive into the World of Parallel Programming! The Go Parallel
> > Website, sponsored by Intel and developed in partnership with Slashdot
> > Media, is your hub for all things parallel software development, from
> > weekly thought leadership blogs to news, videos, case studies,
> > tutorials and more. Take a look and join the conversation now.
> > http://goparallel.sourceforge.net
> > _______________________________________________
> > WiX-devs mailing list
> > WiX...@li...
> > https://lists.sourceforge.net/lists/listinfo/wix-devs
> >
> > ----------------------------------------------------------------------
> > -------- Dive into the World of Parallel Programming! The Go Parallel
> > Website, sponsored by Intel and developed in partnership with Slashdot
> > Media, is your hub for all things parallel software development, from
> > weekly thought leadership blogs to news, videos, case studies,
> > tutorials and more. Take a look and join the conversation now.
> > http://goparallel.sourceforge.net
> > _______________________________________________
> > WiX-devs mailing list
> > WiX...@li...
> > https://lists.sourceforge.net/lists/listinfo/wix-devs
> >
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------
> ------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

[Rob M. <ro...@fi...>]

I'm really not at all excited about *another* tool in v4. I'd much rather we be able to use the MSI and the cabs as the source without having to preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best place for it but you only use it to optimize the process. Otherwise, the patch unbinder stuff can just use the original build output.

I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.

Having to think ahead makes in so many different ways makes patching terribly unapproachable.

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

-----Original Message-----
From: Tunney, Stephen [mailto:Ste...@nu...] 
Sent: Monday, January 5, 2015 8:01 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [bo...@jo...]
Sent: January 5, 2015 10:51 PM
To: wix...@li...
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt extracts to a source tree, which makes it easier to update. Plus Melt does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was who had that idea, I certainly can't remember.) It mixes two very different things. Adding the functionality to Dark is a little better but not by much. (Dark is *mostly* about decompiling; extraction is something else tacked on.) I think it would make it easier to discover the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:
> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [bo...@jo...]
> Sent: January 5, 2015 6:51 PM
> To: wix...@li...
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary 
> table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch> -xb (extract binaries, 
>> does not get squashed by -sextract and uses old path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a 
> la Dark, right? That provides binaries and prompts users to update 
> their scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel 
> Website, sponsored by Intel and developed in partnership with Slashdot 
> Media, is your hub for all things parallel software development, from 
> weekly thought leadership blogs to news, videos, case studies, 
> tutorials and more. Take a look and join the conversation now. 
> http://goparallel.sourceforge.net 
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel 
> Website, sponsored by Intel and developed in partnership with Slashdot 
> Media, is your hub for all things parallel software development, from 
> weekly thought leadership blogs to news, videos, case studies, 
> tutorials and more. Take a look and join the conversation now. 
> http://goparallel.sourceforge.net 
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

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


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

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

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Rob M. <ro...@fi...>]

An hour earlier won't help much. It'd have to be probably 3 hours earlier (6:00 AM PST) to have any hope of not being interrupted by life here. <smile/>

However, it seems like many are interested in taking it back an hour (10:00 AM PST). That's the time we had two weeks ago.

Just for discussion, what about Tuesday 3:00 PM PST?  That's a very different time slot and probably hits east coasters at a poor time. Thoughts?

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

From: Hoover, Jacob [mailto:Jac...@gr...]
Sent: Monday, January 19, 2015 7:44 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WiX Online Meeting time in 2015?

An hour earlier or later would be fine by me (if that helps at all).


From: Rob Mensching [mailto:ro...@fi...]
Sent: Sunday, January 18, 2015 1:53 AM
To: WiX toolset developer mailing list
Subject: [WiX-devs] WiX Online Meeting time in 2015?

Greetings,

Last year our weekly meeting was regularly scheduled at 9:00 AM PST on Thursdays. Due to changes in life, 9:00 AM PST is turning out to be very challenging for me to attend regularly. Thus I'd like to move the meeting time to another timeslot.

Of course, no time slot can be perfect but we'd like to accommodate as many people as possible. So, does anyone have suggestions or anti-suggestions (time that will never work)?

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

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Hoover, J. <Jac...@gr...>]

An hour earlier or later would be fine by me (if that helps at all).


From: Rob Mensching [mailto:ro...@fi...]
Sent: Sunday, January 18, 2015 1:53 AM
To: WiX toolset developer mailing list
Subject: [WiX-devs] WiX Online Meeting time in 2015?

Greetings,

Last year our weekly meeting was regularly scheduled at 9:00 AM PST on Thursdays. Due to changes in life, 9:00 AM PST is turning out to be very challenging for me to attend regularly. Thus I'd like to move the meeting time to another timeslot.

Of course, no time slot can be perfect but we'd like to accommodate as many people as possible. So, does anyone have suggestions or anti-suggestions (time that will never work)?

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

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Bob A. <bo...@jo...>]

On 18-Jan-15 02:52, Rob Mensching wrote:
> Last year our weekly meeting was regularly scheduled at 9:00 AM PST on 
> Thursdays. Due to changes in life, 9:00 AM PST is turning out to be 
> very challenging for me to attend regularly. Thus I’d like to move the 
> meeting time to another timeslot.
0800?

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

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Heath S. <he...@ou...>]

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Bruce C. <br...@cr...>]

On 1/18/2015 3:33 PM, Neil Sleightholm wrote:
>
> What time zone? GMT sounds good Jbut I guess that is not what you mean.
>

Looks like PST from Heath's email headers :)

Date: Sun, 18 Jan 2015 08:53:29 -0800


-- 
Bruce

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Neil S. <ne...@x2...>]

What time zone? GMT sounds good ☺ but I guess that is not what you mean.

From: Heath Stewart [mailto:he...@ou...]
Sent: 18 January 2015 16:53
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WiX Online Meeting time in 2015?

10:00 would allow me to attend and hopefully isn't to bad for our friends overseas.

Sent from my Windows Phone
________________________________
From: Rob Mensching<mailto:ro...@fi...>
Sent: ‎1/‎17/‎2015 11:54 PM
To: WiX toolset developer mailing list<mailto:wix...@li...>
Subject: [WiX-devs] WiX Online Meeting time in 2015?

Greetings,



Last year our weekly meeting was regularly scheduled at 9:00 AM PST on Thursdays. Due to changes in life, 9:00 AM PST is turning out to be very challenging for me to attend regularly. Thus I’d like to move the meeting time to another timeslot.



Of course, no time slot can be perfect but we’d like to accommodate as many people as possible. So, does anyone have suggestions or anti-suggestions (time that will never work)?



_______________________________________________________________

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

Re: [WiX-devs] WiX Online Meeting time in 2015?

[Heath S. <he...@ou...>]

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet