Re: [WiX-users] DIFxApp does not properly rollback to the old driver when doing a major upgrade

[Thomas Svare]

I believe that's it.  We opened a case with the DIFXApp team on this issue last 
year and got a will not fix response but no real explanation.  Thank you!

Thanks,
Tom

-Original Message-
From: jjbean [mailto:jonks2...@yahoo.co.uk] 
Sent: Friday, July 01, 2011 3:27 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old driver 
when doing a major upgrade

I don't think there's much the DIFXApp team can do to make the lib
foolproof/robust.

I'm pretty sure that DIFXApp is simply a wrapper around the win32 setupapi
API.
I've used both for the last few years.

In many cases, I've found that even when using the win32 api directly, it's
not possible to rollback uninstalled drivers, the exact behavior is very
platform dependent. In many cases, the api returns "reboot required", at
which point there is no chance of reinstalling the driver in the same
session. This can be because the driver service was marked for deletion, so
SCM will deny recreating the service until after a reboot.

I'd be very surprised if DIFXApp can work around this.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/DIFxApp-does-not-properly-rollback-to-the-old-driver-when-doing-a-major-upgrade-tp5821359p6538903.html
Sent from the wix-users mailing list archive at Nabble.com.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unhandled exception in light

[Thomas Svare]

Hello,

I got about 6% better compression with 7-Zip compared to WinRAR but 
unfortunately my file is still too big to attach (40.3MB).  Is there another 
alternative to making the crash dump available?

The crash has been seen with Light.exe versions pre-release 3.5, 3.52519 and 
3.6.1706.

Thanks,
Tom

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Monday, June 06, 2011 8:49 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] unhandled exception in light

On 02-Jun-11 09:08, Thomas Svare wrote:
> I'm able to log a bug, 3310378, but I can't add my crash dump attachment.  
> I'm guessing that it is too large but I'm not getting any fail to add 
> information.  The file in question is 43MB.  Is there a files size limitation 
> for attachments?  Is there another way to make the file available?

Try compressing it with 7-Zip <http://www.7-zip.org/>. SourceForge has a 
size limit but I'm not sure what it is.

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


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unhandled exception in light

[Thomas Svare]

Hello,

I'm able to log a bug, 3310378, but I can't add my crash dump attachment.  I'm 
guessing that it is too large but I'm not getting any fail to add information.  
The file in question is 43MB.  Is there a files size limitation for 
attachments?  Is there another way to make the file available?

Thanks,
Tom

-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com] 
Sent: Tuesday, May 31, 2011 4:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] unhandled exception in light

http://wix.sourceforge.net/ -> right hand side below Support -> Bug
database (or directly
http://sourceforge.net/tracker/?group_id=105970&atid=642714 ). Then
please log in or register at sourceforge and you should be able to
submit it...

2011/5/31 Thomas Svare :
> Hello,
>
> I've done some cursory searching but I can't find how to submit a bug for 
> Wix.  Any pointers or links would be appreciated.
>
> Thanks,
> Tom
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Sunday, May 29, 2011 11:59 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] unhandled exception in light
>
> On 25-May-11 15:31, Thomas Svare wrote:
>> After several missed opportunities I've finally got a crash dump and was 
>> able to run a quick analysis.  Using Wix 3.6.1706.0 light crashes 
>> intermittently on our build machines.  This crash was also observed with 3.5 
>> release.  I'm continuing to look into this but was wondering if those 
>> familiar with the code might recognize the potential issue?  Below is the 
>> windbg analysis:
>
> Please file a bug with the dump and !analyze output. I've seen failures
> but never from the GC.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> --
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unhandled exception in light

[Thomas Svare]

Thanks for the below.  It seems I never click around enough before I ask 
questions, story of my life.  

Thanks,
Tom

-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com] 
Sent: Tuesday, May 31, 2011 4:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] unhandled exception in light

http://wix.sourceforge.net/ -> right hand side below Support -> Bug
database (or directly
http://sourceforge.net/tracker/?group_id=105970&atid=642714 ). Then
please log in or register at sourceforge and you should be able to
submit it...

2011/5/31 Thomas Svare :
> Hello,
>
> I've done some cursory searching but I can't find how to submit a bug for 
> Wix.  Any pointers or links would be appreciated.
>
> Thanks,
> Tom
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Sunday, May 29, 2011 11:59 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] unhandled exception in light
>
> On 25-May-11 15:31, Thomas Svare wrote:
>> After several missed opportunities I've finally got a crash dump and was 
>> able to run a quick analysis.  Using Wix 3.6.1706.0 light crashes 
>> intermittently on our build machines.  This crash was also observed with 3.5 
>> release.  I'm continuing to look into this but was wondering if those 
>> familiar with the code might recognize the potential issue?  Below is the 
>> windbg analysis:
>
> Please file a bug with the dump and !analyze output. I've seen failures
> but never from the GC.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> --
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unhandled exception in light

[Thomas Svare]

Hello,

I've done some cursory searching but I can't find how to submit a bug for Wix.  
Any pointers or links would be appreciated.

Thanks,
Tom

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Sunday, May 29, 2011 11:59 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] unhandled exception in light

On 25-May-11 15:31, Thomas Svare wrote:
> After several missed opportunities I've finally got a crash dump and was able 
> to run a quick analysis.  Using Wix 3.6.1706.0 light crashes intermittently 
> on our build machines.  This crash was also observed with 3.5 release.  I'm 
> continuing to look into this but was wondering if those familiar with the 
> code might recognize the potential issue?  Below is the windbg analysis:

Please file a bug with the dump and !analyze output. I've seen failures 
but never from the GC.

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


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] unhandled exception in light

[Thomas Svare]

l!CMsiRecord::_CMsiRecord
BUCKET_ID:  
APPLICATION_FAULT_SOFTWARE_NX_FAULT_INVALID_BAD_IP_msi!CMsiRecord::_CMsiRecord+19
WATSON_STAGEONE_URL:  
http://watson.microsoft.com/StageOne/light_exe/3_6_1706_0/4dc46411/unknown/0_0_0_0/bbb4/c005/74490001.htm?Retriage=1
Followup: MachineOwner



-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Sunday, April 24, 2011 7:32 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] unhandled exception in light

On 21-Apr-11 11:47, Thomas Svare wrote:
> Grasping at straws I set the number of threads to use during cab creation to 
> 1 but that did not help.  I'm at the point where I need to debug and I was 
> wondering if the Wix 3.5 symbols are available?  I did not see them on 
> SourceForge.  In the meantime, I've started trying to build the source.

No. Try swapping in a WiX v3.6 build; symbols are available for those.

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


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] unhandled exception in light

[Thomas Svare]

Hello,

I'm having an intermittent problem with light that seems to have started with 
Wix 3.5.  I'm now using the released version of 3.5 but this issue was observed 
on pre-release builds of 3.5.  During the build of a msi I'm getting the below 
unhandled exception events and error to stderr:

4/21/2001 7:07:45AM - .NET Runtime - Event ID 1026

Application: light.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
   at 
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(UInt32)
   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean)
   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize()

4/21/2001 7:07:46AM - Application Error - Event ID 1000

Faulting application name: light.exe, version: 3.5.2519.0, time stamp: 
0x4d371a87
Faulting module name: msi.dll, version: 5.0.7600.16385, time stamp: 0x4a5bda99
Exception code: 0xc005
Fault offset: 0x00018735
Faulting process id: 0x13b4
Faulting application start time: 0x01cc001406b438f0
Faulting application path: r:\sdks\Wix_3.5.2519.0\light.exe
Faulting module path: C:\Windows\system32\msi.dll
Report Id: 9585bb83-6c07-11e0-ad71-005056a55275


System.AccessViolationException was unhandled
  Message=Attempted to read or write protected memory. This is often an 
indication that other memory is corrupt.
  Source=wix
  StackTrace:
   at 
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(UInt32
 database)
   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean 
disposing)
   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize()
  InnerException:

Grasping at straws I set the number of threads to use during cab creation to 1 
but that did not help.  I'm at the point where I need to debug and I was 
wondering if the Wix 3.5 symbols are available?  I did not see them on 
SourceForge.  In the meantime, I've started trying to build the source.

If anyone has any ideas on what is happening I'd like to hear them.

Thanks,
Tom
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] issues with WiX 3.5 light

[Thomas Svare]

Hello,

 

We're currently using WiX 3.5.1902 but for the last couple of releases
we've intermittently been getting access violations in light with the
following information in the event log:

 

Application: light.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.AccessViolationException

Stack:

   at
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandl
e(UInt32)

   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean)

   at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize()

 

 

Faulting application name: light.exe, version: 3.5.1902.0, time stamp:
0x4c2e25bf

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x

Exception code: 0xc005

Fault offset: 0x4fe8

Faulting process id: 0x970

Faulting application start time: 0x01cb2037720b1c60

Faulting application path: r:\sdks\Wix_3.5.1902.0\light.exe

Faulting module path: unknown

Report Id: c5ede6f0-8c2a-11df-84d2-001d09fd6876

 

 

And from the popup

 

Problem signature:

  Problem Event Name:   BEX

  Application Name:light.exe

  Application Version: 3.5.1902.0

  Application Timestamp:4c2e25bf

  Fault Module Name: StackHash_0a9e

  Fault Module Version:  0.0.0.0

  Fault Module Timestamp: 

  Exception Offset: 4fe8

  Exception Code:  c005

  Exception Data:   0008

  OS Version:6.1.7600.2.0.0.274.10

  Locale ID:1033

  Additional Information 1:   0a9e

  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789

  Additional Information 3:   0a9e

  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

 

Read our privacy statement online:

  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

 

Has anyone else been seeing this problem with light?

 

Thanks,

Tom

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExisting Products failing with /qn upgrade

[Thomas Svare]

One thing to look at would be how FindRelatedProducts is scheduled in
the InstallUISequence and InstallExecuteSequence.  Also look at what the
ActionProperty in the Upgrade table is set to in both cases.

Thanks,
Tom

-Original Message-
From: James Poole [mailto:w...@slowcommotion.com] 
Sent: Friday, July 16, 2010 5:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RemoveExisting Products failing with /qn upgrade

Does any know why the RemoveExistingProducts action would fail when an
upgrade is run silently?

If I run in full UI mode, everything works as expected.  If I run the
upgrade with /qn, the RemoveExistingProducts does not work and I end up
with
both products installed on the system.

RemoveExistingProducts is scheduled right after InstallInitialize.

Verbose log says:


MSI (s) (B8:28) [03:53:57:096]: Doing action: RemoveExistingProducts
Action ended 3:53:57: InstallInitialize. Return value 1.
Action start 3:53:57: RemoveExistingProducts.
MSI (s) (B8:48) [03:53:57:128]: Resetting cached policy values
MSI (s) (B8:48) [03:53:57:128]: Machine policy value 'Debug' is 0
MSI (s) (B8:48) [03:53:57:128]: *** RunEngine:
   *** Product: 1
   *** Action:
   *** CommandLine: **
MSI (s) (B8:28) [03:53:57:128]: Ignoring failure to remove product
during upgrade - product already uninstalled.
MSI (s) (B8:28) [03:53:57:128]: Doing action: ca_LogUserInfo
Action ended 3:53:57: RemoveExistingProducts. Return value 1.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.0 error with .net 4

[Thomas Svare]

Rob,

Thanks for the quick response, it is much appreciated.  

Thanks,
Tom

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Wednesday, June 02, 2010 10:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.0 error with .net 4

WiX v3.5 supports NETFX 4.0. WiX v3.0 does not. IIRC, the fix is to add:

 

as the to the app.config for light.exe.

On Wed, Jun 2, 2010 at 4:31 PM, Thomas Svare
wrote:

> Hello,
>
>
>
> I'm helping with setting up a new build environment with VisualStudio
> 2010 and we're targeting .net 4.  The version of WiX in use is
3.0.5419.
> I'm getting the following light error on my assemblies that I didn't
get
> with .net 3.5:
>
>
>
> error LGHT0132 : The assembly file 'Data.dll' appears to be invalid.
> Please ensure this is a valid assembly file and that the user has the
> appropriate access rights to this file.  More information: HRESULT:
> 0x8013101b
>
>
>
> The component is specified as follows:
>
>
>
> Guid="8B9769B9-4FD7-435B-8B4D-668602EB07B1" SharedDllRefCount="yes"
> Win64="$(var.X_64)">
>
> KeyPath="yes" Assembly=".net" AssemblyApplication="data.d"
> Source="$(var.FILE_PATH)\Data.dll"/>
>
>
>
>
>
> I googled the error and only came up with a few hits that were helpful
> but did not solve the problem.  I saw there was a bug in WiX 3.5.
Does
> anyone have any insight to this issue?
>
>
>
> Thanks,
>
> Tom
>
>
>

--
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX 3.0 error with .net 4

[Thomas Svare]

Hello,

 

I'm helping with setting up a new build environment with VisualStudio
2010 and we're targeting .net 4.  The version of WiX in use is 3.0.5419.
I'm getting the following light error on my assemblies that I didn't get
with .net 3.5:

 

error LGHT0132 : The assembly file 'Data.dll' appears to be invalid.
Please ensure this is a valid assembly file and that the user has the
appropriate access rights to this file.  More information: HRESULT:
0x8013101b

 

The component is specified as follows:

 







 

I googled the error and only came up with a few hits that were helpful
but did not solve the problem.  I saw there was a bug in WiX 3.5.  Does
anyone have any insight to this issue?

 

Thanks,

Tom   

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall By Product/Upgrade Code

[Thomas Svare]

Hello,

You can use the Upgrade table and FindRelatedProducts action to get what
you're looking for.

Thanks,
Tom

-Original Message-
From: Clemmer, Everette [mailto:eclem...@rosettastone.com] 
Sent: Tuesday, April 13, 2010 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Uninstall By Product/Upgrade Code

Does WIX have any way to retrieve the product code of an installed
application, given its upgrade code?

Everette

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat

[Thomas Svare]

Thanks Bob.  We've got some dll's that support the current versions of
MS Exchange and we only build the 64 bit versions.  I've got all the
registration information but we're trying to write a sanity
check/automation tool to verify we've got everything.

Thanks,
Tom

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Saturday, April 10, 2010 9:14 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Heat

On 4/9/2010 12:46 PM, Thomas Svare wrote:
> SelfReg.  How do I harvest registration information from 64 bit dlls?
>

Heat doesn't support 64-bit DLLs. Use it on the 32-bit version; unless 
it's a horribly-written DLL, the self-reg info will be essentially the 
same, once it's put in a 64-bit component.

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



--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with - light.exe : error LGHT0204 : ICE03: Invalididentifier

[Thomas Svare]

How do you have you package Id set in your merge module?  It's used to
form the ModuleID for tables ModuleComponents and ModuleSignature and it
doesn't look right, it should just be a quid.

Thanks,
Tom

-Original Message-
From: Satish Muniyappa (3P) [mailto:satish.muniya...@citrix.com] 
Sent: Wednesday, April 07, 2010 6:06 PM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Help with - light.exe : error LGHT0204 : ICE03:
Invalididentifier

Hi,

I am trying to build a merge module.

And here is the error I see:
light.exe : error LGHT0204 : ICE03: Invalid identifier; Table:
ModuleComponents, Column: ModuleID, Key(s):
mod_ticket.so.FCD893BA_6892_46F6_9A13_037CB5C0AE89.XT
E Ticketing.FCD893BA_6892_46F6_9A13_037CB5C0AE89.0
light.exe : error LGHT0204 : ICE03: Invalid identifier; Table:
ModuleSignature, Column: ModuleID, Key(s):
Ticketing.FCD893BA_6892_46F6_9A13_037CB5C0AE89.0
light.exe : error LGHT0204 : ICE60: The file
mod_a_n.dll.8097A0CB_06C2_4AF9_842A_39CD923F7044 is Versioned. It cannot
be hashed

Any help to get around this will be great.

Thanks,
Satish M S


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Heat

[Thomas Svare]

Hello,

 

When I try to harvest registration information from a 64 bit dll Heat
v3.0.5419 is returning that the file does not support SelfReg and an
error code 193 for the file (invalid Win32 app).  The file does support
SelfReg.  How do I harvest registration information from 64 bit dlls?

 

Thanks,

Tom

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

Sorry about that just meant any install operation after the initial
install.  It sounds like WIX_INSTALLDIR is not being updated to the user
select install directory during patches/repair/uninstall.  If the
install directory is being saved in the registry or .ini file you can
use the RegistrySearch or IniFileSearch element to set a property.  Then
you could use that property to set WIX_INSTALLDIR based on whether or
not your product is installed.  

There's also a ComponentSearch element that may be helpful as well.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Monday, December 14, 2009 11:59 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


Sorry, I'm not familiar with the term "maintenance mode" and all that it
encompasses.  I can tell you that the WIX_INSTALLDIR is being defined in
the
actual code.  When running the installer it has a default location which
is
preset and shows up in the dialog.  When the user changes it they do it
while running the installer by modifying the text which should reset the
WIX_INSTALLDIR property during the installation.  If this could be
defined
as being set/defined in maintenance mode, than yes it is for user-chosen
directories.


Thomas Svare wrote:
> 
> Hello,
> 
> Is WIXUI_INSTALLDIR being set/defined in maintenance mode?
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Monday, December 14, 2009 10:28 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> Hey Tom,
> 
> I have the option for users to choose the installation directory from
a
> custom InstallDirDlg.wxs file, basically just copied with a different
> name,
> call it MyInstallDirDlg.wxs.  The user can either click a button and
> browse
> or type the location manually into an edit field.  The value gets set
to
> a
> property defined in my main installer .wxs file as WIXUI_INSTALLDIR.
> Then
> in a custom MyWixUI_InstallDir.wxs, I have it publish the
SetTargetPath
> event to value [WIXUI_INSTALLDIR].
> 
> By default the directory structure is put in as follows:
> 
> 
>   
> 
>Key="Software\IWARS\ResearchAndDevelopment\Uninstall">
> 
>   
>   ... components below ...
> 
>   
> 
> 
> 
> Thomas Svare wrote:
>> 
>> Hello,
>> 
>> How does the directory for the binaries and docs get set when the
user
>> chooses a non-default install directory?  It sounds like this isn't
>> happening in any maintenance operations.
>> 
>> Thanks,
>> Tom
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Friday, December 11, 2009 8:07 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> Hey Tom,
>> 
>> I managed to get a verbose log of a good and bad uninstall (seemed
the
>> easiest place to start.)  INSTALLDIR was set properly in both logs.
> The
>> issue with the uninstall prevents itself with only the data files
used
>> by
>> our application being removed.  This holds true for the other issues
> as
>> well, the data files don't seem to be causing a problem.  The binary
>> files
>> and documentation for our product remain behind.  In both logs their
>> directory data is also the same, which naturally means it works fine
>> when
>> installed to the default directory.
>> 
>> There isn't really any key difference between the binary files being
>> installed and the data files.  One difference being that all the
> binary
>> files are being installed under a single component (which I know is a
>> rule
>> violation but the ruling to do it this way is happening above me).  I
>> also
>> don't see how it could be contributing to this particular problem.
>> 
>> 
>> Thomas Svare wrote:
>>> 
>>> Hello,
>>> 
>>> Try looking at the property dump section of a verbose log and
compare
>>> the directory table entry values between a good default install and
a
>>> bad patch/repair/uninstall.  INSTALLDIR is has been an issue for me
> in
>>> the past.
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Thursday, December 10, 2009 3:50 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
di

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

Is WIXUI_INSTALLDIR being set/defined in maintenance mode?

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Monday, December 14, 2009 10:28 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


Hey Tom,

I have the option for users to choose the installation directory from a
custom InstallDirDlg.wxs file, basically just copied with a different
name,
call it MyInstallDirDlg.wxs.  The user can either click a button and
browse
or type the location manually into an edit field.  The value gets set to
a
property defined in my main installer .wxs file as WIXUI_INSTALLDIR.
Then
in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath
event to value [WIXUI_INSTALLDIR].

By default the directory structure is put in as follows:


  

  

  
  ... components below ...

  



Thomas Svare wrote:
> 
> Hello,
> 
> How does the directory for the binaries and docs get set when the user
> chooses a non-default install directory?  It sounds like this isn't
> happening in any maintenance operations.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Friday, December 11, 2009 8:07 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> Hey Tom,
> 
> I managed to get a verbose log of a good and bad uninstall (seemed the
> easiest place to start.)  INSTALLDIR was set properly in both logs.
The
> issue with the uninstall prevents itself with only the data files used
> by
> our application being removed.  This holds true for the other issues
as
> well, the data files don't seem to be causing a problem.  The binary
> files
> and documentation for our product remain behind.  In both logs their
> directory data is also the same, which naturally means it works fine
> when
> installed to the default directory.
> 
> There isn't really any key difference between the binary files being
> installed and the data files.  One difference being that all the
binary
> files are being installed under a single component (which I know is a
> rule
> violation but the ruling to do it this way is happening above me).  I
> also
> don't see how it could be contributing to this particular problem.
> 
> 
> Thomas Svare wrote:
>> 
>> Hello,
>> 
>> Try looking at the property dump section of a verbose log and compare
>> the directory table entry values between a good default install and a
>> bad patch/repair/uninstall.  INSTALLDIR is has been an issue for me
in
>> the past.
>> 
>> Thanks,
>> Tom
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Thursday, December 10, 2009 3:50 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> Thanks for the tip Tom, I'm looking into at least one discrepency
that
> I
>> saw
>> come up after the Orca/patch transform.  I'm not sure if it's causing
>> this
>> error or not but chances are it would have caused problems down the
>> road.  
>> 
>> The second issue you mentioned I was curious about as well.  Do you
> know
>> of
>> anything that could cause a property to be set by the UI and not by
>> repair
>> and uninstall?  I could see this happening with registry key entries
>> which
>> shouldn't be the case in my installer, but could you help me to
>> understand
>> what to look for with troublesome UI properties as well?
>> 
>> 
>> Thomas Svare wrote:
>>> 
>>> Hello,
>>> 
>>> You just open the msi with Orca then choose Transform->View Patch
and
>>> navigate to the msp and select OK and you'll see the changes in
Orca.
>>> 
>>> Since repairs and uninstalls are showing the problem it sounds like
>> some
>>> property is getting set by the UI that isn't being re-set during
>>> patch/repair/uninstall.
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Thursday, December 10, 2009 12:59 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
directories
>>> 
>>> 
>>> I definitely reviewed the tables for both my installer msi as well
as
>> my
>>> patch msp while trying to figure out this problem.  I've never heard
>> of
>>

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

How does the directory for the binaries and docs get set when the user
chooses a non-default install directory?  It sounds like this isn't
happening in any maintenance operations.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Friday, December 11, 2009 8:07 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


Hey Tom,

I managed to get a verbose log of a good and bad uninstall (seemed the
easiest place to start.)  INSTALLDIR was set properly in both logs.  The
issue with the uninstall prevents itself with only the data files used
by
our application being removed.  This holds true for the other issues as
well, the data files don't seem to be causing a problem.  The binary
files
and documentation for our product remain behind.  In both logs their
directory data is also the same, which naturally means it works fine
when
installed to the default directory.

There isn't really any key difference between the binary files being
installed and the data files.  One difference being that all the binary
files are being installed under a single component (which I know is a
rule
violation but the ruling to do it this way is happening above me).  I
also
don't see how it could be contributing to this particular problem.


Thomas Svare wrote:
> 
> Hello,
> 
> Try looking at the property dump section of a verbose log and compare
> the directory table entry values between a good default install and a
> bad patch/repair/uninstall.  INSTALLDIR is has been an issue for me in
> the past.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Thursday, December 10, 2009 3:50 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> Thanks for the tip Tom, I'm looking into at least one discrepency that
I
> saw
> come up after the Orca/patch transform.  I'm not sure if it's causing
> this
> error or not but chances are it would have caused problems down the
> road.  
> 
> The second issue you mentioned I was curious about as well.  Do you
know
> of
> anything that could cause a property to be set by the UI and not by
> repair
> and uninstall?  I could see this happening with registry key entries
> which
> shouldn't be the case in my installer, but could you help me to
> understand
> what to look for with troublesome UI properties as well?
> 
> 
> Thomas Svare wrote:
>> 
>> Hello,
>> 
>> You just open the msi with Orca then choose Transform->View Patch and
>> navigate to the msp and select OK and you'll see the changes in Orca.
>> 
>> Since repairs and uninstalls are showing the problem it sounds like
> some
>> property is getting set by the UI that isn't being re-set during
>> patch/repair/uninstall.
>> 
>> Thanks,
>> Tom
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Thursday, December 10, 2009 12:59 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> I definitely reviewed the tables for both my installer msi as well as
> my
>> patch msp while trying to figure out this problem.  I've never heard
> of
>> applying a patch using orca before though, I took at look but didn't
> see
>> an
>> obvious way of doing this.  Could you let me know how to use orca to
>> apply
>> the patch?  Also the issue extends beyond patching to include repairs
>> and
>> uninstalls so I think the problem runs deeper than just how the patch
> is
>> applied.
>> 
>> 
>> Thomas Svare wrote:
>>> 
>>> Hello,
>>> 
>>> You may have already tried this but sometimes opening the msi and
>>> applying the patch with Orca can point out things that are buried in
> a
>>> verbose log like removing a component from a feature during a patch
>> etc.
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Thursday, December 10, 2009 12:00 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
directories
>>> 
>>> 
>>> All of the components are listed as:
>>> 
>>> Installed: Local; Request: Local; Action: Local.
>>> 
>>> 
>>> Blair-2 wrote:
>>>> 
>>>> What does the log say about the component statuses?
>>>>

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

Try looking at the property dump section of a verbose log and compare
the directory table entry values between a good default install and a
bad patch/repair/uninstall.  INSTALLDIR is has been an issue for me in
the past.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Thursday, December 10, 2009 3:50 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


Thanks for the tip Tom, I'm looking into at least one discrepency that I
saw
come up after the Orca/patch transform.  I'm not sure if it's causing
this
error or not but chances are it would have caused problems down the
road.  

The second issue you mentioned I was curious about as well.  Do you know
of
anything that could cause a property to be set by the UI and not by
repair
and uninstall?  I could see this happening with registry key entries
which
shouldn't be the case in my installer, but could you help me to
understand
what to look for with troublesome UI properties as well?


Thomas Svare wrote:
> 
> Hello,
> 
> You just open the msi with Orca then choose Transform->View Patch and
> navigate to the msp and select OK and you'll see the changes in Orca.
> 
> Since repairs and uninstalls are showing the problem it sounds like
some
> property is getting set by the UI that isn't being re-set during
> patch/repair/uninstall.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Thursday, December 10, 2009 12:59 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> I definitely reviewed the tables for both my installer msi as well as
my
> patch msp while trying to figure out this problem.  I've never heard
of
> applying a patch using orca before though, I took at look but didn't
see
> an
> obvious way of doing this.  Could you let me know how to use orca to
> apply
> the patch?  Also the issue extends beyond patching to include repairs
> and
> uninstalls so I think the problem runs deeper than just how the patch
is
> applied.
> 
> 
> Thomas Svare wrote:
>> 
>> Hello,
>> 
>> You may have already tried this but sometimes opening the msi and
>> applying the patch with Orca can point out things that are buried in
a
>> verbose log like removing a component from a feature during a patch
> etc.
>> 
>> Thanks,
>> Tom
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Thursday, December 10, 2009 12:00 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> All of the components are listed as:
>> 
>> Installed: Local; Request: Local; Action: Local.
>> 
>> 
>> Blair-2 wrote:
>>> 
>>> What does the log say about the component statuses?
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Thursday, December 10, 2009 6:27 AM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
directories
>>> 
>>> 
>>> Hey Blair-2, I'd be happy to share a log of the installation but
>>> unfortunately I'm doing this for a company and I'm not allowed to
> post
>> the
>>> information for a log.  I've studied the logs myself during patching
>> and
>>> it
>>> looks like it doesn't recognize that the install path is different
>> from
>>> C:\Program Files\Appname\etc.  What it ends up outputting is a list
> of
>> the
>>> files being installed by the patch but each one specifies To be
>> installed;
>>> Won't patch; No existing file.
>>> 
>>> If you're interested in a particular portion of the log file I might
>> be
>>> able
>>> to show you by replacing the product and path information with
>> fictional
>>> data so you could see what might be the problem without my violating
>> my
>>> company's policies.
>>> 
>>> Thank for all your help so far!
>>> 
>>> 
>>> Blair-2 wrote:
>>>> 
>>>> The location that the components you are patching are already
>> installed.
>>>> 
>>>> Could you share a log that shows it not working in that
> circumstance?
>>>> 
>>>> -Original Message-
>>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>>> Sent: Wednesday, D

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

You just open the msi with Orca then choose Transform->View Patch and
navigate to the msp and select OK and you'll see the changes in Orca.

Since repairs and uninstalls are showing the problem it sounds like some
property is getting set by the UI that isn't being re-set during
patch/repair/uninstall.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Thursday, December 10, 2009 12:59 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


I definitely reviewed the tables for both my installer msi as well as my
patch msp while trying to figure out this problem.  I've never heard of
applying a patch using orca before though, I took at look but didn't see
an
obvious way of doing this.  Could you let me know how to use orca to
apply
the patch?  Also the issue extends beyond patching to include repairs
and
uninstalls so I think the problem runs deeper than just how the patch is
applied.


Thomas Svare wrote:
> 
> Hello,
> 
> You may have already tried this but sometimes opening the msi and
> applying the patch with Orca can point out things that are buried in a
> verbose log like removing a component from a feature during a patch
etc.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Thursday, December 10, 2009 12:00 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> All of the components are listed as:
> 
> Installed: Local; Request: Local; Action: Local.
> 
> 
> Blair-2 wrote:
>> 
>> What does the log say about the component statuses?
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Thursday, December 10, 2009 6:27 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> Hey Blair-2, I'd be happy to share a log of the installation but
>> unfortunately I'm doing this for a company and I'm not allowed to
post
> the
>> information for a log.  I've studied the logs myself during patching
> and
>> it
>> looks like it doesn't recognize that the install path is different
> from
>> C:\Program Files\Appname\etc.  What it ends up outputting is a list
of
> the
>> files being installed by the patch but each one specifies To be
> installed;
>> Won't patch; No existing file.
>> 
>> If you're interested in a particular portion of the log file I might
> be
>> able
>> to show you by replacing the product and path information with
> fictional
>> data so you could see what might be the problem without my violating
> my
>> company's policies.
>> 
>> Thank for all your help so far!
>> 
>> 
>> Blair-2 wrote:
>>> 
>>> The location that the components you are patching are already
> installed.
>>> 
>>> Could you share a log that shows it not working in that
circumstance?
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Wednesday, December 09, 2009 1:55 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: Re: [WiX-users] Patching problems with alternate
directories
>>> 
>>> 
>>> When you refer to the "currently installed location", are you
> referring
>>> to
>>> the location that my product installs to by default or the location
>>> selected
>>> by the user.  If the latter, then the patch should be installing to
> that
>>> location.
>>> 
>>> 
>>> Blair-2 wrote:
>>>> 
>>>> Are your patches MSP files performing either small updates or minor
>>>> upgrades? If so, the patch application won't let you patch anywhere
>>>> other
>>>> than the currently installed location since the keypath of the
>>>> components
>>>> can't be changed without a major upgrade.
>>>> 
>>>> -Original Message-
>>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>>> Sent: Wednesday, December 02, 2009 1:12 PM
>>>> To: wix-users@lists.sourceforge.net
>>>> Subject: [WiX-users] Patching problems with alternate directories
>>>> 
>>>> 
>>>> I've been having an issue with my WiX patch which I haven't been
> able to
>>>> find
>>>> any information for.  The company I work for wants to give users
the
>>>> freedo

Re: [WiX-users] Patching problems with alternate directories

[Thomas Svare]

Hello,

You may have already tried this but sometimes opening the msi and
applying the patch with Orca can point out things that are buried in a
verbose log like removing a component from a feature during a patch etc.

Thanks,
Tom

-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com] 
Sent: Thursday, December 10, 2009 12:00 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories


All of the components are listed as:

Installed: Local; Request: Local; Action: Local.


Blair-2 wrote:
> 
> What does the log say about the component statuses?
> 
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com] 
> Sent: Thursday, December 10, 2009 6:27 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
> 
> 
> Hey Blair-2, I'd be happy to share a log of the installation but
> unfortunately I'm doing this for a company and I'm not allowed to post
the
> information for a log.  I've studied the logs myself during patching
and
> it
> looks like it doesn't recognize that the install path is different
from
> C:\Program Files\Appname\etc.  What it ends up outputting is a list of
the
> files being installed by the patch but each one specifies To be
installed;
> Won't patch; No existing file.
> 
> If you're interested in a particular portion of the log file I might
be
> able
> to show you by replacing the product and path information with
fictional
> data so you could see what might be the problem without my violating
my
> company's policies.
> 
> Thank for all your help so far!
> 
> 
> Blair-2 wrote:
>> 
>> The location that the components you are patching are already
installed.
>> 
>> Could you share a log that shows it not working in that circumstance?
>> 
>> -Original Message-
>> From: XorPtr [mailto:reaper4...@gmail.com] 
>> Sent: Wednesday, December 09, 2009 1:55 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: Re: [WiX-users] Patching problems with alternate directories
>> 
>> 
>> When you refer to the "currently installed location", are you
referring
>> to
>> the location that my product installs to by default or the location
>> selected
>> by the user.  If the latter, then the patch should be installing to
that
>> location.
>> 
>> 
>> Blair-2 wrote:
>>> 
>>> Are your patches MSP files performing either small updates or minor
>>> upgrades? If so, the patch application won't let you patch anywhere
>>> other
>>> than the currently installed location since the keypath of the
>>> components
>>> can't be changed without a major upgrade.
>>> 
>>> -Original Message-
>>> From: XorPtr [mailto:reaper4...@gmail.com] 
>>> Sent: Wednesday, December 02, 2009 1:12 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: [WiX-users] Patching problems with alternate directories
>>> 
>>> 
>>> I've been having an issue with my WiX patch which I haven't been
able to
>>> find
>>> any information for.  The company I work for wants to give users the
>>> freedom
>>> to install our product in a directory of their choice.  We've given
the
>>> installer a default directory which can be changed at install time
by
>>> the
>>> user.  This has worked fine up until attempting to patch the
package.  I
>>> successfully made a patch which patches the package without problem
if
>>> it's
>>> installed to the default location, however if users choose to
install
>>> the
>>> product in an alternate location and then patch the patch fails
because
>>> it's
>>> still trying to change files on the default location.  Any ideas on
how
>>> I
>>> can dynamically set up the patch install location based on where the
>>> user
>>> installs our product?  Thanks in advance.
>>> 
>>> Big Jim.
>>> -- 
>>> View this message in context:
>>>
>>
>
http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102
386p
>>> 4102386.html
>>> Sent from the wix-users mailing list archive at Nabble.com.
>>> 
>>>
>>
>


>>> --
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing. 
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>> 
>>> 
>>>
>>
>


>> --
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing. 
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>> 

Re: [WiX-users] CA types

[Thomas Svare]

Thanks.  I should have thought of that.  This is really an awesome user
board!

Thanks,
Tom

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Thursday, October 08, 2009 11:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CA types

When I get stumped with how WiX maps to Wi, I use dark on a simple
package to see what it authors.

--- On Thu, 10/8/09, Thomas Svare  wrote:

> From: Thomas Svare 
> Subject: [WiX-users] CA types
> To: "General discussion for Windows Installer XML toolset."

> Date: Thursday, October 8, 2009, 10:27 AM
> Hello,
> 
>  
> 
> I'm trying to get a CA type of 3585 set for one of my
> custom actions
> with Wix 3.0.5419 and I'm not having much luck.
> 
>  
> 
> It's
> 
>  
> 
> msidbCustomActionTypeDll
> 
> msidbCustomActionTypeOncePerProcess
> 
> msidbCustomActionTypeInScript
> 
> msidbCustomActionTypeNoImpersonate
> 
>  
> 
> Any ideas?
> 
>  
> 
> Thanks,
> 
> Tom
> 
>

--
> Come build with us! The BlackBerry(R) Developer Conference
> in SF, CA
> is the only developer event you need to attend this year.
> Jumpstart your
> developing skills, take BlackBerry mobile applications to
> market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009.
> Register now!
> http://p.sf.net/sfu/devconference
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 


  


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] CA types

[Thomas Svare]

Hello,

 

I'm trying to get a CA type of 3585 set for one of my custom actions
with Wix 3.0.5419 and I'm not having much luck.

 

It's

 

msidbCustomActionTypeDll

msidbCustomActionTypeOncePerProcess

msidbCustomActionTypeInScript

msidbCustomActionTypeNoImpersonate

 

Any ideas?

 

Thanks,

Tom

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Multiple Driver Packages

[Thomas Svare]

I had the same situation and once I put the .inf, .sys and supporting
dlls into different directories it worked fine.

Thanks,
Tom

-Original Message-
From: Jeremy Farrell [mailto:jfarr...@pillardata.com] 
Sent: Friday, September 04, 2009 1:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Driver Packages

> From: Slide [mailto:slide.o@gmail.com] 
> 
> I have two drivers that I need to install, I currently have 
> two inf files for them. Apparently DIFXAPP doesn't support
> this as I get the following error:
> 
> ...
> DIFXAPP: ERROR: more than one driver package found in 'C:\Program
> Files\MYAPP\'
> DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
> DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
> Action ended 20:52:22: InstallFinalize. Return value 3.
> 
> Do I have to combine the two drivers into a single inf file?

Just based on the error message, it looks like putting the different
packages in different directories would work.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] install two services implemented in one executable.

[Thomas Svare]

Hello,

Are you providing a unique name for each serviceinstall element?

Thanks,
Tom

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com] 
Sent: Thursday, July 09, 2009 10:48 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] install two services implemented in one executable.

Hi,

I have an executable which implements two NT services.

Running "InstallUtil myservices.exe" can install and start both
services.

How can I install it in WIX using ServiceInstall?

I tried putting two ServiceInstall elements in one Component but they
seems to install the same service (the first service found I guess).


Thanks
Lian

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,

vendors submitting new applications to BlackBerry App World(TM) will
have
the opportunity to enter the BlackBerry Developer Challenge. See full
prize  
details at: http://p.sf.net/sfu/Challenge
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: Web Service

[Thomas Svare]

Hello,

We need to do the below for the localservice account

httpcfg set urlacl -u http://+:80/foo -a D:(A;;GX;;;sid)

Where sid is the correct account.

Thanks,
Tom

-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org] 
Sent: Wednesday, July 08, 2009 6:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] FW: Web Service

What do you mean "grant permissions for specific port"?  Firewall
exception?

Thomas Svare wrote:
> Hello,
>
> Sorry for the spam on this issue.  I've got a beta deadline coming up
so
> I'll probably go with InstallUtil and use the intaller class in the
exe
> but if anyone has any ideas on this I would very much like to hear
them.
>
> Thanks,
> Tom
>
> -Original Message-
> From: Thomas Svare [mailto:thomas_sv...@symantec.com]
> Sent: Monday, July 06, 2009 12:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Web Service
>
> Hello,
>
>
>
> I've got to install a web service running as NT
AUTHORITY\LocalService.
> I'm able to do this but I also have to grant permissions for
> LocalService on a specific port.  Is there a way to do this through
WiX?
>
>
>
>
> I've searched the archives and did not come up with anything but I'm
> probably not using a good search query.
>
>
>
> Thanks,
>
> Tom
>
>

> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited
time,
> vendors submitting new applications to BlackBerry App World(TM) will
have
> the opportunity to enter the BlackBerry Developer Challenge. See full
prize
> details at: http://p.sf.net/sfu/blackberry
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,

vendors submitting new applications to BlackBerry App World(TM) will
have
the opportunity to enter the BlackBerry Developer Challenge. See full
prize  
details at: http://p.sf.net/sfu/Challenge
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FW: Web Service

[Thomas Svare]

Hello,

Sorry for the spam on this issue.  I've got a beta deadline coming up so
I'll probably go with InstallUtil and use the intaller class in the exe
but if anyone has any ideas on this I would very much like to hear them.

Thanks,
Tom

-Original Message-----
From: Thomas Svare [mailto:thomas_sv...@symantec.com] 
Sent: Monday, July 06, 2009 12:32 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Web Service

Hello,

 

I've got to install a web service running as NT AUTHORITY\LocalService.
I'm able to do this but I also have to grant permissions for
LocalService on a specific port.  Is there a way to do this through WiX?


 

I've searched the archives and did not come up with anything but I'm
probably not using a good search query.

 

Thanks,

Tom


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Web Service

[Thomas Svare]

Hello,

 

I've got to install a web service running as NT AUTHORITY\LocalService.
I'm able to do this but I also have to grant permissions for
LocalService on a specific port.  Is there a way to do this through WiX?


 

I've searched the archives and did not come up with anything but I'm
probably not using a good search query.

 

Thanks,

Tom

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] application event logs

[Thomas Svare]

Hello,

 

We're trying to track down a build hang issue and during the course of
the investigation the application event logs have been reviewed.  We're
seeing information application events with each msi build (standard
candle and light build) that states the following:

 

Product:  FileSearch - Installation completed successfully.

 

Or

 

Product:  FileSearch - Installation operation completed successfully.

 

The source of the event is MsiIntaller.  I'm pretty sure this is just
the completion msi build.  Could someone verify this? 

 

Thanks,

Tom

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 4.5

[Thomas Svare]

Perfect.

Thank you.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Nannenga
Sent: Monday, September 15, 2008 1:35 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.5

Reference:
http://robmensching.com/blog/archive/2007/09/03/Windows-Installer-4.5-an
d-the-WiX-toolset.aspx


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Monday, September 15, 2008 7:53 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.5

Hello,



I've got somewhat of a 'read the manual' question that has probably been
addressed sometime in the recent past.  I downloaded the Wix3.0 but had
problems displaying the pages and ran some cursory queries against the
archives and didn't find anything so I'll throw this out there.



Will Wix 3.0 have support for the new tables, table column additions,
properties etc. that will be in Windows Installer 4.5?



Thanks,

Tom


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Windows Installer 4.5

[Thomas Svare]

Profitable, Home Business Ideas Money Making Online Internet
Great Work from Home Opportunity. Earn up to $5000per month
Earn money on the computer with internet from home without investment

More details; http://xrl.us/bkygk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"opportunities at home" group.
To post to this group, send email to opportunities-at-home@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/opportunities-at-home?hl=en
-~--~~~~--~~--~--~---

[WiX-users] COM registration

[Thomas Svare]

Hello,

 

I'm using Wix 2.0.5805 and the following code:

 

















 

Everything is technically working properly but I've been asked to
provide a work-around for a UI issue.  The problem I'm dealing with is
the default registry entry for InprocServer32 is being written using the
short file and path name.  Is there a way to force the default registry
entry for InprocServer32 to be written with the long file and path name?

 

Thanks,

Tom

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with empty directory

[Thomas Svare]

I believe you have to define the directory as you are doing then use the
 element in a component that is
installed.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Rerick
Sent: Wednesday, March 05, 2008 11:30 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with empty directory

 

I used Paraffin to create a Fragment containing files & directories that
need to be installed. One of the directories is empty but needs to show
up on the target computer. The empty directory is in the Paraffin
generated Fragment. When I build the MSI file and run it, the empty
directory does not get created in the INSTALLDIR. I am using WiX version
3.0.3725. I can't find any options for either candle or light that would
keep empty directories. Is there a way to keep the empty directory &
have it created on the target machine?

 

Thanks for any help.

 

Mike Rerick

Sr. Software Engineer - Professional Services

   http://www.iwsinc.com/> 

 

9200 S.E. Sunnybrook Blvd., Suite 170

Clackamas, OR   97015

Phone: (503) 353-8068Fax: (503) 353-8065

 



The information contained in this transmission contains potentially
privileged, export controlled and/or confidential information of
Imageware Systems, Inc. or its customers or partners. It is intended
only to be read by the person(s) named above and for no other purpose.
You are hereby notified that any dissemination, distribution,
duplication of this communication or use of its contents for any purpose
not authorized expressly by Imageware Systems, Inc. is strictly
prohibited and could lead to both civil and/or criminal penalties. If
you are not the intended recipient, you are prohibited to review the
contents herein and please contact the sender by reply e-mail and
destroy all copies of the original message. To reply to our e-mail
administrator directly, please send an e-mail to [EMAIL PROTECTED]

<>-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Assembly=".net" attribute in the tag

[Thomas Svare]

It needs to be the file id of the application file.

 

Thanks,

Tom

 



From: Don Tasanasanta (Volt) [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 07, 2008 4:51 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Assembly=".net" attribute in the  tag

 

What value should be assigned to the AssemblyApplication attribute? 

 

From: Thomas Svare [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 07, 2008 1:46 PM
To: Don Tasanasanta (Volt); wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Assembly=".net" attribute in the  tag

 

Don,

 

I can't answer your first question but the answer to your second
question (What if you don't want your assembly added to the GAC?) is you
need to use the attribute AssemblyApplication to have it installed
outside the GAC.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta (Volt)
Sent: Thursday, February 07, 2008 4:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Assembly=".net" attribute in the  tag

 

What exactly does the Assembly=".net" attribute in the  tag do? 

 

WiX help says:

Specifies if this File is a Win32 Assembly or .NET Assembly that needs
to be installed into the Global Assembly Cache. If the value is '.net'
or 'win32', this file must also be the key path of the Component. This
attribute's value should be one of the following: .net , no , win32 

 

Does this mean that if you mark an assembly as ".net" that install will
try and add that assembly to the GAC? What if you don't want your
assembly added to the GAC? 

 

What is the default value for this attribute?

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Assembly=".net" attribute in the tag

[Thomas Svare]

Don,

 

I can't answer your first question but the answer to your second
question (What if you don't want your assembly added to the GAC?) is you
need to use the attribute AssemblyApplication to have it installed
outside the GAC.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta (Volt)
Sent: Thursday, February 07, 2008 4:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Assembly=".net" attribute in the  tag

 

What exactly does the Assembly=".net" attribute in the  tag do? 

 

WiX help says:

Specifies if this File is a Win32 Assembly or .NET Assembly that needs
to be installed into the Global Assembly Cache. If the value is '.net'
or 'win32', this file must also be the key path of the Component. This
attribute's value should be one of the following: .net , no , win32 

 

Does this mean that if you mark an assembly as ".net" that install will
try and add that assembly to the GAC? What if you don't want your
assembly added to the GAC? 

 

What is the default value for this attribute?

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module Custom Actions

[Thomas Svare]

Mike,

 

Thanks that works great.  Not quite sure why I just didn't try that
first.

 

Thanks

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Thursday, January 24, 2008 5:31 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module Custom Actions

 

Use . WiX generates ModuleInstallExecuteSequence
table entries if you're building a merge module.

 

-- 

Mike Dimmick

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: 24 January 2008 22:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Merge Module Custom Actions

 

Hello,

 

I've got a few merge modules generated with Wix that have custom actions
included in them.  I'd like to populate the ModuleInstallExecuteSequence
table to generically schedule them.  Any ideas on accomplishing this?  I
looked through all the children of Module element and I'm not seeing
anything that can get me there.

 

Thanks,

Tom

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Merge Module Custom Actions

[Thomas Svare]

Hello,

 

I've got a few merge modules generated with Wix that have custom actions
included in them.  I'd like to populate the ModuleInstallExecuteSequence
table to generically schedule them.  Any ideas on accomplishing this?  I
looked through all the children of Module element and I'm not seeing
anything that can get me there.

 

Thanks,

Tom

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating User Environment Variable through Group Policy

[Thomas Svare]

Vince,

There's a way to do it through group policy but I can't remember how off
the top of my head.  Do a search on voicewarmup and you'll find the
registry entries you can set before the installation.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho
Sent: Tuesday, July 31, 2007 3:51 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Creating User Environment Variable through
Group Policy


Thanks Tom. How do I produce a log file from the Active Directory
install?
Since I can't specify arguments for the MSI execution (e.g. /l*vx
log.txt).

Cheers,
Vince



Thomas Svare wrote:
> 
> Vince,
> 
> A diff between verbose logs for a user initiated install and the
active
> directory install would probably point out the issue.  With the active
> directory install you don't have UI and I believe the entire install
> runs as local system.
> 
> Thanks,
> Tom
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Ho
> Sent: Tuesday, July 31, 2007 3:21 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Creating User Environment Variable through Group
> Policy
> 
> 
> Hi,
> 
> I'm trying to deploy my installer package through Group Policy from
> Windows
> Server 2003 to Windows XP clients. The software is being distributed
> through
> "Computer Configuration" and "assigned" to the clients computers (as
> opposed
> to "published").
> 
> The setup installed all the files, system registry keys, and desktop
> shortcuts. However, the user environment variables are not written
> (system
> ones are created though). Local machine install (running MSI directly
on
> the
> XP machines) did not have this problem.
> 
> Did I neglect to set certain properties to enable writing to user env
> vars?
> How do I guarentee that user environment variables are set properly?
> 
> Thanks,
> Vince
> -- 
> View this message in context:
>
http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P
> olicy-tf4194953.html#a11930339
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
>

> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
>

-
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context:
http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P
olicy-tf4194953.html#a11931242
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating User Environment Variable through Group Policy

[Thomas Svare]

Vince,

A diff between verbose logs for a user initiated install and the active
directory install would probably point out the issue.  With the active
directory install you don't have UI and I believe the entire install
runs as local system.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent Ho
Sent: Tuesday, July 31, 2007 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating User Environment Variable through Group
Policy


Hi,

I'm trying to deploy my installer package through Group Policy from
Windows
Server 2003 to Windows XP clients. The software is being distributed
through
"Computer Configuration" and "assigned" to the clients computers (as
opposed
to "published").

The setup installed all the files, system registry keys, and desktop
shortcuts. However, the user environment variables are not written
(system
ones are created though). Local machine install (running MSI directly on
the
XP machines) did not have this problem.

Did I neglect to set certain properties to enable writing to user env
vars?
How do I guarentee that user environment variables are set properly?

Thanks,
Vince
-- 
View this message in context:
http://www.nabble.com/Creating-User-Environment-Variable-through-Group-P
olicy-tf4194953.html#a11930339
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] msiexec question

[Thomas Svare]

Hello,

 

This is almost certainly an msi related issue but I thought I'd see if
anyone has run into the same problem.

 

We use Wix to author 8 merge modules and use InstallShield for the main
installation (soon to be entirely Wix).  Sometime in the last week we've
started getting the following error message when installing from CD or
ISO:

 

Disk full: Out of disk space - Volume: 'D:'; required space: 250,000 KB;
available space: 0 KB.  

 

Something has changed and we're checking the source directory for the
available space to install instead of the target.  When this is CD or
ISO it won't have the space needed.  I've compared a verbose log from
the last known good install and a recent one and the only apparent
difference is when msi changes the OutOfDiskSpace and OutOfRbDiskSpace
properties from 0 to 1 which results in the error message.  I've also
exported all the msi tables from the last known good and a recent msi
and diff'ed them but again nothing obvious stands out.

 

What property change would cause this?  Any pointers or suggestions
would be greatly appreciated.

 

Thanks,

Tom

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista registry removal issue

[Thomas Svare]

Bob,

 

I'm glad the hear that but it brings up another question.  Will an
application be MS logo compliant if the uninstall leaves
HKEY_CURRENT_USER entries around after uninstall?

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Saturday, July 07, 2007 12:40 AM
To: Thomas Svare
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Vista registry removal issue

 

Thomas Svare wrote: 

I'm trying to remove HKEY_CURRENT_USER entries created by the
application on uninstall.  Unfortunately, going through HKEY_USERS
doesn't work on Vista like it does on XP.  Each user is not enumerated
in HKEY_USER on Vista like it is on XP (or so it seems).  The only place
that I've found with the entries on Vista is NTUSER.dat.


It's not supported (on either OS). It usually works on XP but will fail
in some circumstances (like roaming profiles).



-- 
sig://boB
http://joyofsetup.com/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Vista registry removal issue

[Thomas Svare]

Hello,

 

I'm trying to remove HKEY_CURRENT_USER entries created by the
application on uninstall.  Unfortunately, going through HKEY_USERS
doesn't work on Vista like it does on XP.  Each user is not enumerated
in HKEY_USER on Vista like it is on XP (or so it seems).  The only place
that I've found with the entries on Vista is NTUSER.dat.

 

I've done some searching on the list and web and I haven't been able to
come up with a solution.  Any pointers on how I can remove
HKEY_CURRENT_USER entries on Vista during uninstall would be
appreciated.

 

Thanks,

Tom

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing both X64 and X86 problems.

[Thomas Svare]

I've used Wix include files fairly successfully to do what you describe
below.  I have a main install file (wxs) for i386, AMD64 and IA64 and a
Wix include (wxi) containing the common files.  I'm able to pass in
variables for Win64 and Source at build time.  You could also use
fragments to get the same thing done but I think there may be a bit more
to manage that way.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Magus
Sent: Tuesday, May 22, 2007 4:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing both X64 and X86 problems.


My first quesiton is, can I install both x64 and x86 with the same
installer.
IF so, if I specify Program files, does it know which program files
directory to put the files into?
I shouldn't have my x64 applicaiton installing to the Program Files(x86)
directory, but the data between the x86 and x64 is the same data, so the
only thing different between the two is the executables, (2
executables(x86,
x64) sharing the same data files).
Would it be simplier to make two different installers or is there an
easy
way to share this information between them.
-- 
View this message in context:
http://www.nabble.com/Installing-both-X64-and-X86-problems.-tf3800346.ht
ml#a10752179
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Modules

[Thomas Svare]

Your files may be installing just not where you are expecting them to.
Take a look at a verbose log and you'll know for sure.

 

One of the potential problems is the "Name" you've specified for the
CommonFilesFolder is missing the space.  I believe you can leave the
name off altogether since the directory is specified with a system
folder property.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Carl
Quirion
Sent: Monday, April 23, 2007 4:30 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Merge Modules

 

I want to include third party dependencies in my setup.
Those dependencies are OCX/DLLs (of the COM kind).

Ive read that the proper way to do it is to get the merge modules made
by the maker of the 3rd party, however, this is not available for most
of my components. 
So, i went ahead and decided to create my own. I can compile (candle,
light) them without a problem. I can add them to a feature of my main
setup and compile, again, without a problem.

However, when i install my application, it doesn't add them. 
By the way, im trying to install to the "Common files" directory.

This is my module


http://schemas.microsoft.com/wix/2006/wi
 ">

 


 



/* Type lib, along with class id, interfaces and
such */

/* A bunch of RegistryValue here */





 


My main setup file:
in my Product tag:


   


 
Inside my Feature tag:

  

Please help, as i cant figure out what im doing wrong. :( 

-- 
Carl Quirion
[EMAIL PROTECTED] 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FW: merge modules

[Thomas Svare]

Hello,

 

Please disregard the below.  It helps to look at the help once in a
while.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Friday, April 06, 2007 2:21 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] merge modules

 

Hello,

 

I'm in the process of converting our merge modules from Install Shield
to Wix.  Ideally, I'd like convert the main installations to Wix as well
and just use fragments but time does not permit this.

 

I'm running into the following issue:

 

Install Shield merge modules do not append the merge module guid to
public properties when used in conditions.  Wix merge modules are
appending the merge module guid to public properties when I use them in
conditions and this is causing me some problems.  

 

I'm assuming we've just been using the side effect of an Install Shield
bug for quite a while.

 

So my question is:

 

Is there anyway to suppress appending the merge module guid to
conditions in the Component table, InstallExecuteSequence etc. with Wix?

 

Thanks,

Tom

 

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] merge modules

[Thomas Svare]

Hello,

 

I'm in the process of converting our merge modules from Install Shield
to Wix.  Ideally, I'd like convert the main installations to Wix as well
and just use fragments but time does not permit this.

 

I'm running into the following issue:

 

Install Shield merge modules do not append the merge module guid to
public properties when used in conditions.  Wix merge modules are
appending the merge module guid to public properties when I use them in
conditions and this is causing me some problems.  

 

I'm assuming we've just been using the side effect of an Install Shield
bug for quite a while.

 

So my question is:

 

Is there anyway to suppress appending the merge module guid to
conditions in the Component table, InstallExecuteSequence etc. with Wix?

 

Thanks,

Tom

 

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: Directories/Merge Modules

[Thomas Svare]

Rob,

 

I'm in an unusual position in that I have more than a couple days to get
this done so I'll get the files out of there.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 10:45 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

 

I believe that but why are you putting stuff in the Windows directory?
If you're not part of Windows don't freakin' put stuff in the Windows
directory (unless some Windows API puts stuff in the Windows directory,
like installing assemblies to GAC).  And I mean that in the nicest
sense.  

 

 

From: Thomas Svare [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 5:50 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

 

Rob,

 

There have been some maintenance/uninstall issues with needing physical
media that have be avoided by putting UI type dll's there.  I'll find
out the entire history tomorrow and post.  

 

I'm very interested to see if this is necessary or what the recommended
course is for the situation.

 

Thanks,
Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

 

You really should not be writing to the Installer directory.  Why are
you doing that?

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules

 

Hello,

 

I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know.  In fact, I made the change so I could search my
verbose log a little easier.

 

I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.

 



 

This solved my problem.  I'm not sure why.  I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that.  I'd be interested to know what the issue was.

 

Thanks,

Tom



From: Thomas Svare 
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

 

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: Directories/Merge Modules

[Thomas Svare]

Rob,

 

There have been some maintenance/uninstall issues with needing physical
media that have be avoided by putting UI type dll's there.  I'll find
out the entire history tomorrow and post.  

 

I'm very interested to see if this is necessary or what the recommended
course is for the situation.

 

Thanks,
Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

 

You really should not be writing to the Installer directory.  Why are
you doing that?

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules

 

Hello,

 

I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know.  In fact, I made the change so I could search my
verbose log a little easier.

 

I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.

 



 

This solved my problem.  I'm not sure why.  I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that.  I'd be interested to know what the issue was.

 

Thanks,

Tom

____

From: Thomas Svare 
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

 

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FW: Directories/Merge Modules

[Thomas Svare]

Hello,

 

I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know.  In fact, I made the change so I could search my
verbose log a little easier.

 

I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.

 



 

This solved my problem.  I'm not sure why.  I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that.  I'd be interested to know what the issue was.

 

Thanks,

Tom

________

From: Thomas Svare 
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

 

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Directories/Merge Modules

[Thomas Svare]

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 4.0 msi schema

[Thomas Svare]

Hello,

 

Mostly for informational/research purposes.  I know it's documented but
I'd like to get a look at things.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 4:48 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: Re: [WiX-users] Windows Installer 4.0 msi schema

 

Why do you want all MSI tables?  EnsureTable will get the table you
specify.  It isn't intended to add all tables though.

 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 15, 2007 2:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I looked at the command line options and I hope I didn't overlook the
obvious.

 

Is there a way to have Wix create an msi with all the tables in the
schema even though they may be empty?

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 5:09 PM
To: Mike Dimmick; Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Windows Installer 4.0 msi schema

 

Although, if it is a standard MSI table you shouldn't need CustomTable
at all (if you do, it's a bug in the WiX toolset ).

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Wednesday, March 14, 2007 2:48 PM
To: 'Thomas Svare'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

The PatchCertificates element is supported in WiX v3.0, which generates
MsiPatchCertificate table entries.

 

If you need a table that isn't supported by WiX, you can use the
 element.

 

-- 

Mike Dimmick

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: 14 March 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I'm not sure if I'm phrasing this correctly but I'll throw it out there
anyway...

 

Is there any way with Wix to pick up new tables in the Windows Installer
4.0 msi schema?  I'm particularly interested in the MSIPatchCertificate
table.

 

Thanks,

Tom

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 4.0 msi schema

[Thomas Svare]

Hello,

 

I looked at the command line options and I hope I didn't overlook the
obvious.

 

Is there a way to have Wix create an msi with all the tables in the
schema even though they may be empty?

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 5:09 PM
To: Mike Dimmick; Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Windows Installer 4.0 msi schema

 

Although, if it is a standard MSI table you shouldn't need CustomTable
at all (if you do, it's a bug in the WiX toolset ).

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Wednesday, March 14, 2007 2:48 PM
To: 'Thomas Svare'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

The PatchCertificates element is supported in WiX v3.0, which generates
MsiPatchCertificate table entries.

 

If you need a table that isn't supported by WiX, you can use the
 element.

 

-- 

Mike Dimmick

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: 14 March 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I'm not sure if I'm phrasing this correctly but I'll throw it out there
anyway...

 

Is there any way with Wix to pick up new tables in the Windows Installer
4.0 msi schema?  I'm particularly interested in the MSIPatchCertificate
table.

 

Thanks,

Tom

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 4.0 msi schema

[Thomas Svare]

Mike, Rob,

 

Thank you both.  I should have thought of v3.0 but I just can't stop
using v2.0 for quick test purposes.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 5:09 PM
To: Mike Dimmick; Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Windows Installer 4.0 msi schema

 

Although, if it is a standard MSI table you shouldn't need CustomTable
at all (if you do, it's a bug in the WiX toolset ).

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Wednesday, March 14, 2007 2:48 PM
To: 'Thomas Svare'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

The PatchCertificates element is supported in WiX v3.0, which generates
MsiPatchCertificate table entries.

 

If you need a table that isn't supported by WiX, you can use the
 element.

 

-- 

Mike Dimmick

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: 14 March 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I'm not sure if I'm phrasing this correctly but I'll throw it out there
anyway...

 

Is there any way with Wix to pick up new tables in the Windows Installer
4.0 msi schema?  I'm particularly interested in the MSIPatchCertificate
table.

 

Thanks,

Tom

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using InstallShield msm files causes an error

[Thomas Svare]

You should be able to set the sequence of the offending custom action
from the msm in main WiX project I think.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Geoff
Finger
Sent: Wednesday, March 14, 2007 4:21 PM
To: wix-users@lists.sourceforge.net
Cc: Thomas Svare
Subject: Re: [WiX-users] Using InstallShield msm files causes an error

Yeah, changing the sequence of ResolveSource from 525 to 1025 fixed it,
thanks!

Is there a way to override the sequence of an item in a Merge Module
when you reference it, or am I going to have to run Orca and fix it
manually every time I recompile?

On 3/14/07, Thomas Svare <[EMAIL PROTECTED]> wrote:
> That should work.  If you have any custom actions in your msm verify
> that the sequencing is after the cost standard actions.
>
> Thanks,
> Tom
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Geoff
> Finger
> Sent: Wednesday, March 14, 2007 1:04 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Using InstallShield msm files causes an error
>
> I'm trying to include a merge module from an older project that was
> made when we were using InstallShield to create our installations.
>
> When I try including it in my Wix project it compiles fine but when
> running it I get the error:
>
> Action start 16:32:36: ResolveSource.
> MSI (c) (EC:E0) [16:32:36:124]: Note: 1: 2732 2: 0
> DEBUG: Error 2732:  Directory Manager not initialized.
> The installer has encountered an unexpected error installing this
> package. This may indicate a problem with this package. The error code
> is 2732. The arguments are: 0, ,
>
> I tried using dark to decompile the msm file and recompiled it
> directly into a new Wix merge module, and that seems to work fine. So
> if necessary I can just do that instead, but it would be preferable to
> get the original msm working.
>
> Is there something extra I need to do in order to get InstallShield
> merge modules to work with Wix? Or are the two just fundamentally
> incompatible?
>
> (I tried searching the list archives for any info on this but I keep
> getting "500 - Internal Server Error")
>


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Windows Installer 4.0 msi schema

[Thomas Svare]

Hello,

 

I'm not sure if I'm phrasing this correctly but I'll throw it out there
anyway...

 

Is there any way with Wix to pick up new tables in the Windows Installer
4.0 msi schema?  I'm particularly interested in the MSIPatchCertificate
table.

 

Thanks,

Tom

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using InstallShield msm files causes an error

[Thomas Svare]

That should work.  If you have any custom actions in your msm verify
that the sequencing is after the cost standard actions.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Geoff
Finger
Sent: Wednesday, March 14, 2007 1:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using InstallShield msm files causes an error

I'm trying to include a merge module from an older project that was
made when we were using InstallShield to create our installations.

When I try including it in my Wix project it compiles fine but when
running it I get the error:

Action start 16:32:36: ResolveSource.
MSI (c) (EC:E0) [16:32:36:124]: Note: 1: 2732 2: 0
DEBUG: Error 2732:  Directory Manager not initialized.
The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2732. The arguments are: 0, ,

I tried using dark to decompile the msm file and recompiled it
directly into a new Wix merge module, and that seems to work fine. So
if necessary I can just do that instead, but it would be preferable to
get the original msm working.

Is there something extra I need to do in order to get InstallShield
merge modules to work with Wix? Or are the two just fundamentally
incompatible?

(I tried searching the list archives for any info on this but I keep
getting "500 - Internal Server Error")


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Reusable properties?

[Thomas Svare]

Robert,

 

One way that you can accomplish the below is an include file (NOTE
includes are generally frowned upon).

 

As an example you could set a property with respect to a directory
search in the include 

 



http://schemas.microsoft.com/wix/2003/01/wi";>









 

Then use the include where you need it

 



 

There is probably a fragment way to do this that would be more
appropriate.  I'll be interested to see myself.

 

Thanks,

Tom



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yexley,
Robert (LNG-CON)
Sent: Monday, March 12, 2007 2:24 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reusable properties?

 

Hey everyone,

 

Just getting my feet wet with WiX. I've been working my way through the
documentation and the online tutorial the past few days, but so far I've
not been able to figure out if WiX has the ability to create anything
like a global, reusable property, and if so, how are they applied? For
example, what I would like to do, is create a property whose value can
be referenced from various other places within the installer source file
(.wxs). So, something like the following...

 





 













 

__

// YEX //

 

// Bob Yexley

// Contractor / Software Engineer [Extreme Consulting]

// LexisNexis - Risk & Information Analytics Group (RIAG)

// 937.865.6800 ext. 58655

// [EMAIL PROTECTED]

 

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] shortcut Start in:

[Thomas Svare]

Bob,

 

Thanks for the kindly response.  So far I'm batting 2 for 3 on typo
error type questions to the list.  More than a little embarrassing.

 

Thanks,

Tom

 



From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 06, 2007 11:29 AM
To: Thomas Svare
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] shortcut Start in:

 

Thomas Svare wrote: 

How do I populate the Start In field of a shortcut?


Use the Shortcut/@WorkingDirectory attribute.



-- 
sig://boB
http://bobs.org
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] shortcut Start in:

[Thomas Svare]

Hello,

 

I apologize if the answer to this is well documented.  I quickly
searched the user list and looked at the help.

 

How do I populate the Start In field of a shortcut?

 

Thanks,

Tom

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] stock dialog bitmaps

[Thomas Svare]

Matthew,

 

Thanks, that did it.  

 

My search through the src for bannrbmp.bmp must have been malformed.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Rowan
Sent: Wednesday, January 24, 2007 6:45 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] stock dialog bitmaps

 

Hi Tom,

The WixUI_Common is declared in the Common.wxs file. At the start of
that fragment the Binary references to the Bitmaps are declared. So it
sounds like you are not including Common.wxs, however, I would have
thought you would have gotten an error if they weren't included. Hope
this helps. 

Regards,

-Matthew Rowan

On 1/25/07, Thomas Svare < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote: 



Hello,

 

I forgot to mention that if I run light on my wxs with the stock
libraries the bitmaps show up. 

 

Thanks,

Tom

 





From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] ] On Behalf Of Thomas
Svare
Sent: Wednesday, January 24, 2007 4:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] stock dialog bitmaps

 

Hello,

 

I've got a problem similar to an issue addressed earlier today.
I reviewed the tutorial but I'm still running into problems. 

 

I'm using 2.4611 and I'm removing the license agreement dialog
from WixUI_InstallDir.wxs.  Candle and Lit build my new library just
fine but when I try to Light my wxs referencing the new library I get: 

 

D:\temp\src\ui\wixui\installdir\WixUI_InstallDir.wxs : error
LGHT0112 : Unresolved reference to symbol 'UI:WixUI_Common' in section
'Fragment:'. 

 

When I comment the  from
WixUI_InstallDir.wxs and rebuild everything works fine except the
bitmaps no longer show up on the dialogs. 

 

I tried a quick search of the list and didn't come up with
anything.  Does anyone have any ideas? 

 

Thanks,

Tom







-
Take Surveys. Earn Cash. Influence the Future of IT 
Join SourceForge.net's Techsay panel and you'll get the chance
to share your
opinions on IT & business topics through brief surveys - and
earn cash

http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance
to share your 
opinions on IT & business topics through brief surveys - and
earn cash

http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V

___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users 





 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FW: stock dialog bitmaps

[Thomas Svare]

Hello,

 

I forgot to mention that if I run light on my wxs with the stock
libraries the bitmaps show up.

 

Thanks,

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Wednesday, January 24, 2007 4:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] stock dialog bitmaps

 

Hello,

 

I've got a problem similar to an issue addressed earlier today.  I
reviewed the tutorial but I'm still running into problems.

 

I'm using 2.4611 and I'm removing the license agreement dialog from
WixUI_InstallDir.wxs.  Candle and Lit build my new library just fine but
when I try to Light my wxs referencing the new library I get:

 

D:\temp\src\ui\wixui\installdir\WixUI_InstallDir.wxs : error LGHT0112 :
Unresolved reference to symbol 'UI:WixUI_Common' in section 'Fragment:'.

 

When I comment the  from WixUI_InstallDir.wxs
and rebuild everything works fine except the bitmaps no longer show up
on the dialogs.

 

I tried a quick search of the list and didn't come up with anything.
Does anyone have any ideas?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] stock dialog bitmaps

[Thomas Svare]

Hello,

 

I've got a problem similar to an issue addressed earlier today.  I
reviewed the tutorial but I'm still running into problems.

 

I'm using 2.4611 and I'm removing the license agreement dialog from
WixUI_InstallDir.wxs.  Candle and Lit build my new library just fine but
when I try to Light my wxs referencing the new library I get:

 

D:\temp\src\ui\wixui\installdir\WixUI_InstallDir.wxs : error LGHT0112 :
Unresolved reference to symbol 'UI:WixUI_Common' in section 'Fragment:'.

 

When I comment the  from WixUI_InstallDir.wxs
and rebuild everything works fine except the bitmaps no longer show up
on the dialogs.

 

I tried a quick search of the list and didn't come up with anything.
Does anyone have any ideas?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] volatile registry key

[Thomas Svare]

Rob,

 

That makes sense.  The volatile registry creation is currently in a CA
of a merge module I'm trying to convert to Wix.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 21, 2006 11:49 AM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] volatile registry key

 

You don't want to declare a registry key in setup then (there is no
support for volatile keys, for the reasons I mentioned below).  Instead,
it seems like you need a CustomAction to create a temporary marker.  The
WiX toolset has a function in the CustomAction Library that is used to
communicate a reboot is required from the deferred CustomAction to the
immediate CustomAction by using an Atom.  

 

You can see the code in wix\src\ca\wcautil\wcawrap.cpp -
WcaDeferredActionRequiresReboot().

 

From: Thomas Svare [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 21, 2006 08:44
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] volatile registry key

 

Hello,

 

One of our features installs a kernel driver and we don't want
maintenance to be performed or the application to run unless a reboot is
done.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 21, 2006 11:34 AM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] volatile registry key

 

Why would setup create a volatile key?  My understanding is that when
the registry hive is unloaded (usually on a reboot) the key would be
lost.  Your setup would be "broken" after every reboot and a repair
would be in order.

 

What's the scenario?

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, December 21, 2006 08:29
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] volatile registry key

 

Hello,

 

Sorry if this is in the user list archive or tutorial, my quick search
did not come up with anything.

 

Is there a way to create a volatile registry key with Wix?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] volatile registry key

[Thomas Svare]

Hello,

 

One of our features installs a kernel driver and we don't want
maintenance to be performed or the application to run unless a reboot is
done.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 21, 2006 11:34 AM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] volatile registry key

 

Why would setup create a volatile key?  My understanding is that when
the registry hive is unloaded (usually on a reboot) the key would be
lost.  Your setup would be "broken" after every reboot and a repair
would be in order.

 

What's the scenario?

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, December 21, 2006 08:29
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] volatile registry key

 

Hello,

 

Sorry if this is in the user list archive or tutorial, my quick search
did not come up with anything.

 

Is there a way to create a volatile registry key with Wix?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] volatile registry key

[Thomas Svare]

Hello,

 

Sorry if this is in the user list archive or tutorial, my quick search
did not come up with anything.

 

Is there a way to create a volatile registry key with Wix?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix and Drivers

[Thomas Svare]

Friedrich,

The below works for me using Difx:













Then you need to include the path to the appropriate DIFxApp.wixlib in
your light and that should work.  I'm using an older, 2x version of Wix
but this should be fine with 3.

Thanks,
Tom

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Friedrich
Dominicus
Sent: Thursday, December 14, 2006 7:20 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix and Drivers

Rob Hamflett <[EMAIL PROTECTED]> writes:

> You probably want the DIFxApp framework, which is supported in WiX.
Try looking here:
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/DevIns
t_d/hh/DevInst_d/difxapp_b5f94034-5f86-4603-869d-bd64df80b946.xml.asp

thanks I found it also, but as written I do not get the example
really. So I asked for a few other things. However I've installed it
all have printed it and will see whether it can give me answers to the
stuff I do not understand

Regards
Friedrich


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] conditional install

[Thomas Svare]

Bob,

 

Thanks.  You were absolutely right, MsiNTProductType does the job fine.


 

Thanks,

Tom

 



From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 13, 2006 12:37 PM
To: Thomas Svare
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] conditional install

 

Thomas Svare wrote: 

The new problem I'm running into is MsiNtProductType is not defined when
the action InstallFiles runs so MsiNtProductType acts as a logical false
when my components' condition is evaluated.  I know this is more of a
Windows Installer question but I was wondering if anyone has any
thoughts on getting around this type of issue?


Double-check your spelling. The "t" is capitalized. Property names are
case-sensitive.




-- 
sig://boB
http://bobs.org
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] conditional install

[Thomas Svare]

Hello,

 

I need to support Longhorn Server and not Vista.  The exe in question is
generally a server side component however it has to be installed on XP
and Win2k (non server).  The decision has been made to not support Vista
at this point.

 

The MsiNtProductType property looks exactly like what I need.  On Vista
it evaluates to 1 and Longhorn it evaluates to 3 (at least on the Vista
and Longhorn install types I've tried).  

 

The new problem I'm running into is MsiNtProductType is not defined when
the action InstallFiles runs so MsiNtProductType acts as a logical false
when my components' condition is evaluated.  I know this is more of a
Windows Installer question but I was wondering if anyone has any
thoughts on getting around this type of issue?

 

Thanks,

Tom

 



From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Saturday, December 09, 2006 4:47 PM
To: Thomas Svare
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] conditional install

 

Thomas Svare wrote: 

I've got to install a component on Windows 2000 and greater with the
exception of Vista.  The component needs to install on Longhorn.  I know
Longhorn isn't completed yet and is subject to change but I have to try
to make it work with what's available today.  The following condition
works great but excludes Longhorn:

 

VersionNT < 600


You mean you want to support Vista but exclude Longhorn Server? If so,
take a look at the MsiNTProductType  property in the MSI SDK doc. You
can check a verbose log to see the value MSI sets on Longhorn Server?




-- 
sig://boB
http://bobs.org
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] conditional install

[Thomas Svare]

Hello,

 

I've got to install a component on Windows 2000 and greater with the
exception of Vista.  The component needs to install on Longhorn.  I know
Longhorn isn't completed yet and is subject to change but I have to try
to make it work with what's available today.  The following condition
works great but excludes Longhorn:

 

VersionNT < 600

 

Any thought/recommendations on how I could get this job done?

 

Thanks,

Tom

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Directory reassignment problem

[Thomas Svare]

Don,

 

I had this problem with a 32 bit component in a 64 bit merge module.
The 32 bit component needed to go in 

 

Program Files (x86)\MyCompany\MyProduct 

 

I've never fully understood why I had this problem but the issue was
happening because I was using all uppercase Directory Id's.  Once I
switched to a mixed case Directory Id's the files installed fine.  I
stumbled upon the problem looking at a verbose log.  I believe it has
something to do when properties are evaluated during the InstallUI and
InstallExecute sequences.

 

I'll be interested to hear other thoughts and explanations.

 

Tom

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta
Sent: Thursday, December 07, 2006 3:48 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Directory reassignment problem

 

My install has a very large directory structure in which the root folder
is defined by the user. If the user doesn't change the default root
directory then everything works fine but if the default is changed then
the install creates a root folder in the new location but only the files
directly under the root folder are installed there; all the folders
under the root end up installed in the default location.

 



  





   

 

 

(in another wxs file)

 



 

  

  

 

(and series of other directory Id's)

 



 

In the UI the value of WEBSITE is changed to somewhere else but DIR1,
and all other folders declared under the WEBSITE DirectoryRef, still
reflect the default location. 

 

Is this the expected behavior? And if so... how might I all the
subsequent directories to follow WEBSITE to what ever value it contains?

 



 

Don Tasanasanta

VIACK Corporation

Redmond Washington

425-605-7423

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users