date:20100721

heat.exe /? or http://wix.sourceforge.net/manual-wix3/heat.htm or
http://www.tramontana.co.hu/wix/lesson6.php#6.1 might be good places to
start.

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: vijay chander [mailto:vijaychander2...@gmail.com] 
Sent: 21 July 2010 04:51
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Registering COM DLLs using HEAT Tool.

Hi All,

I have read that we can register dlls using heat tool, just by using
.wxs file which will be generated by heat tool.
So can anyone tell me how to register a COM DLL using HEAT Tool?
With Regards,
Vijay

--
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-users] Installing a windows service based on user give account

2010-07-21 Thread Stelios Kyprou

I do this because when you try and add the localsystem account as: NT 
AUTHORITY\SYSTEM, it will not check the Local System account 
radiobutton under the Log On tab in the service properties.
It will instead select the This account: radiobutton and add NT 
AUTHORITY\SYSTEM as the username.
So what i do, is when the user selects what account to use in a dialog, 
i do the simple logic:
if (Local System is selected)
{
SERVICEACCOUNTFULLNAME = LocalSystem
}
else
{
SERVICEACCOUNTFULLNAME = [WINDOWSDOMAIN]\[WINDOWSUSERNAME]
}

where WINDOWSDOMAIN and WINDOWSUSERNAME are edit boxes in that dialog 
with these properties.
This way, i tackle both cases.
-When i add as account LocalSystem, it actually selects the Local 
System account radiobutton under the Log On tab in the service 
properties.
-When i add as account [WINDOWSDOMAIN]\[WINDOWSUSERNAME] then the user 
account is added in the selected This account: radiobutton under the 
Log On tab in the service properties.

This is the only way i found to handle this situation without having to 
define 2 components, which i didn't like as a solution, don't ask me why 
:P I don't know either :)

John Bergman wrote:
 Can I ask why you are using SERVICEACCOUNTFULLNAME as a parameter, rather 
 than doing something like this?

 CustomAction Id='SetPermissionableUser' Property='PermissionableUser' 
 Value='[WINDOWSDOMAIN]\[WINDOWSUSERNAME]' /

 -Original Message-
 From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] 
 Sent: Tuesday, July 20, 2010 4:20 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] [Wix-users] Installing a windows service based on 
 user give account

 Or i realised i can use Account and give it LocalSystem. This way you can 
 have one component for both.
 In case anyone is wondering, you can do the following:

 Component Id='ServiceExeComponent' Guid='YOUR-GUID'
   SharedDllRefCount='no' KeyPath='no' NeverOverwrite='no' Permanent='no' 
 Transitive='no'
   Win64='yes' Location='either' Directory=INSTALLLOCATION
   File Id=A_Executable KeyPath=yes Checksum=yes 
 Source=$(var.A_FilesDir)\ALM_GC.exe /
   
   util:User Id=UpdateUserLogonAsService UpdateIfExists=yes 
 CreateUser=no Name=[WINDOWSDOMAIN]\[WINDOWSUSERNAME]
  LogonAsService=yes/
   
   ServiceInstall Id='ServiceInstall' DisplayName='Liquidity Bot' 
 Description='Liquidity Bot' Name='ALM_Bot'
 ErrorControl='normal' Type='ownProcess' Start='auto' Vital='yes' 
 Account='[SERVICEACCOUNTFULLNAME]' Password='[WINDOWSPASSWORD]' 
 Interactive='no'/
  
   ServiceControl Id='A_ServiceControl' Name='ALM'
 Start='install' Stop='both' Remove='uninstall' Wait='yes'/
 /Component

 I have 4 properties:
 WINDOWSDOMAIN
 WINDOWSPASSWORD
 WINDOWSUSERNAME
 SERVICEACCOUNTFULLNAME

 SERVICEACCOUNTFULLNAME
  is the combination of :[WINDOWSDOMAIN]\[WINDOWSUSERNAME] if we have a user 
 account. If we have a builtin account, SERVICEACCOUNTFULLNAME
 is: LocalSystem (for example)
 In case of a builtin account, the Password attribute is disregarded

 Bob Arnson wrote:
   
 On 7/19/2010 12:04 PM, Stelios Kyprou wrote:
   
 
 I know that i can make that happen if i don't provide Account and 
 Password in the ServiceInstall tag, but then again it depends on what 
 the user chooses to run the service as in a dialog.

 
   
 Use two components with conditions based on the dialog properties.

   
 

 --
 Stelios Kyprou
 Systems Engineer
 Formicary - delivering quality financial technology solutions(TM) 
 www.formicary.net


 
 This message is confidential and may be privileged. It is intended solely for
 the named addressee. If you are not the intended recipient, please inform us.
 Any unauthorised dissemination, distribution or copying hereof is prohibited.

 Formicary Limited registered office in England and Wales, address 1 Taillar
 Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number
 747644304, does not guarantee that the integrity of this communication has 
 been
 maintained nor that this communication is free of viruses, interceptions or
 interference.
 

 --
 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

Re: [WiX-users] How do I use bootstraper ???? need example

This link may be of use to you
http://catb.org/~esr/faqs/smart-questions.html#before 

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Bhaumik Barot [mailto:bhaumik...@gmail.com] 
Sent: 21 July 2010 03:19
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How do I use bootstraper  need example

I have 3rd party exe which is a msi and also I have my app.msi. I can
not call msi within msi .

How do I use bootstarpper in my .wixproj ? Any example would help a lot.

--
Bhaumik Barot

--
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] Upgrade in per-user folder generates double entriesin Add/Remove programs

2010-07-21 Thread David Louis

Thanks guys!

On Wed, Jul 21, 2010 at 11:54 AM, Pally Sandher pally.sand...@iesve.com wrote:
 You'd need a per-machine installation to do that anyway (see 
 http://msdn.microsoft.com/en-us/library/aa370882.aspx)

 The How to guide at 
 http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm works 
 pretty well as long as your package has ALLUSERS set to 1.

 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with the Virtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No. 
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow 
 G20 0SP
 Email Disclaimer

 -Original Message-
 From: David Louis [mailto:clientlo...@gmail.com]
 Sent: 21 July 2010 10:03
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Upgrade in per-user folder generates double 
 entriesin Add/Remove programs

 Thanks Blair.

 I set ALLUSERS to 1 in order to install to c:\program files by default in 
 both setups.

 Anyway you're right: I actually don't need a per-user installation.
 What I'm looking for is an option to make the program available in the All 
 users start menu.


 On Tue, Jul 20, 2010 at 8:17 PM, Blair os...@live.com wrote:
 Was the value of ALLUSERS property different between the two installations?
 Per-machine installations and per-user installations are basically in
 separate worlds for Windows Installer and shell components such as
 ARP show a combined view of both worlds.

 Most programs tend to be either per-user or per-machine, and most of
 the time you probably don't want to give the user a choice.

 -Original Message-
 From: David Louis [mailto:clientlo...@gmail.com]
 Sent: Tuesday, July 20, 2010 10:35 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Upgrade in per-user folder generates double
 entries in Add/Remove programs

 Hi,

 I modified the WixUI_Advanced sample to prevent downgrading by adding
 these lines:

   Upgrade Id=UPGRADE_CODE_UID
     UpgradeVersion OnlyDetect=yes Minimum=$(var.PRODUCTVERSION)
 Property=NEWERVERSIONDETECTED IncludeMinimum=no /
     UpgradeVersion OnlyDetect=no Maximum=$(var.PRODUCTVERSION)
 Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no /
   /Upgrade
   Condition Message=A later version of [ProductName] is already
 installed. Setup will now exit.
     NOT NEWERVERSIONDETECTED OR Installed
   /Condition

   Of course, UPGRADE_CODE_UID is the same UID than the product's
 UpgradeCode property.

   This works well as long as I install to the per-machine folder.
   Installing to the per-user folder generates a second entry in add /
 remove programs instead of upgrading the product.

 Any hints?

 --
 --
 --
 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


 --
 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


--
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] The DirProperty in RemoveFile table must be a property name in Directory table?

Why don't you try  resolve your linking errors when trying to build
wix-contrib instead of trying to reinvent the wheel  failing?

Also why are you storing user specific data under the installation
directory instead of somewhere like My Documents or CommonAppData as per
Microsoft's platform guidelines?

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Elfe Xu [mailto:elf...@microsoft.com] 
Sent: 21 July 2010 04:29
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] The DirProperty in RemoveFile table must be a
property name in Directory table?


I've changed the property name to all up cases, but still failed :(
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirPro
perty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5
317922p5319532.html
Sent from the wix-users mailing list archive at Nabble.com.


--
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

[WiX-users] WiX 3.5 C# Custom Action Project

2010-07-21 Thread ramyaragu

Hi All,

I get the following error when trying to run VS2010 Custom Action Project
with Wix 3.5.

Invoking remote custom action. DLL: C:\Windows\Installer\MSI24A2.tmp,
Entrypoint: ValidateSerialNumberKey

Generating random cookie.

Created Custom Action Server with PID 1224 (0x4C8).

Running as a service.

Hello, I'm your 32bit Impersonated custom action server.

SFXCA: Extracting custom action to temporary directory:
C:\Windows\Installer\MSI24A2.tmp-\

SFXCA: Binding to CLR version v2.0.50727

Error: could not load custom action class CustomAction from assembly X

System.BadImageFormatException: Could not load file or assembly 'X' or one
of its dependencies. This assembly is built by a runtime newer than the
currently loaded runtime and cannot be loaded.

File name: 'X'

at System.Reflection.Assembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark
stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark
stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark stackMark, Boolean
forIntrospection)

at System.Reflection.Assembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark stackMark, Boolean
forIntrospection)

at System.AppDomain.Load(String assemblyString)

at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session
session, String assemblyName, String className, String methodName)

WRN: Assembly binding logging is turned OFF.

To enable assembly bind failure logging, set the registry value (DWORD) to
1.

Note: There is some performance penalty associated with assembly bind
failure logging.

To turn this feature off, remove the registry value .

Action ended 0:05:31: ValidateSerialNumber. Return value 3.

Action ended 0:05:31: INSTALL. Return value 3.

I am confused as to why it should bind to CLR 2.0 when i am using the target
framework as .Net 4.0

So,I modified the MakeSFXCA config file the following way:

startup useLegacyV2RuntimeActivationPolicy=false
supportedRuntime version=v4.0 /
!-- supportedRuntime version=v2.0.50727 / --
/startup

Then,it throws the following error:

SFXCA: Extracting custom action to temporary directory:
C:\WINDOWS\Installer\MSI15.tmp-\ SFXCA: Failed to get requested CLR info.
Error code 0x80131700 SFXCA: Ensure that the proper version of the .NET
Framework is installed, or that there is a matching supportedRuntime element
in CustomAction.config.

Could some please help me with this?

Thanks,
Ramya

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Custom-Action-Project-tp5320937p5320937.html
Sent from the wix-users mailing list archive at Nabble.com.

--
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.5 C# Custom Action Project

2010-07-21 Thread Stelios Kyprou

You're propably using a 64 bit dll while using the 32 bit SFXCA. You 
should point to the 64 bit version of SFXCA.
in my machine for example, C:\Program Files (x86)\Windows Installer XML 
v3.5\SDK\x64\sfxca.dll
rather than C:\Program Files (x86)\Windows Installer XML 
v3.5\SDK\x86\sfxca.dll

When you use the 64 bit, logging will say

Hello, I'm your 64bit Impersonated custom action server.

rather than 

Hello, I'm your 32bit Impersonated custom action server.


At least this is how i fixed this problem when i came across it
Hope it helps,
Stelios


ramyaragu wrote:
 Hi All,

 I get the following error when trying to run VS2010 Custom Action Project
 with Wix 3.5.

 Invoking remote custom action. DLL: C:\Windows\Installer\MSI24A2.tmp,
 Entrypoint: ValidateSerialNumberKey

 Generating random cookie.

  Created Custom Action Server with PID 1224 (0x4C8).

  Running as a service.

 Hello, I'm your 32bit Impersonated custom action server.

 SFXCA: Extracting custom action to temporary directory:
 C:\Windows\Installer\MSI24A2.tmp-\

 SFXCA: Binding to CLR version v2.0.50727



 Error: could not load custom action class CustomAction from assembly X

 System.BadImageFormatException: Could not load file or assembly 'X' or one
 of its dependencies. This assembly is built by a runtime newer than the
 currently loaded runtime and cannot be loaded.

 File name: 'X'

at System.Reflection.Assembly._nLoad(AssemblyName fileName, String
 codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark
 stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
 codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark
 stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
 Evidence assemblySecurity, StackCrawlMark stackMark, Boolean
 forIntrospection)

at System.Reflection.Assembly.InternalLoad(String assemblyString,
 Evidence assemblySecurity, StackCrawlMark stackMark, Boolean
 forIntrospection)

at System.AppDomain.Load(String assemblyString)

at
 Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session
 session, String assemblyName, String className, String methodName)

  

 WRN: Assembly binding logging is turned OFF.

 To enable assembly bind failure logging, set the registry value  (DWORD) to
 1.

 Note: There is some performance penalty associated with assembly bind
 failure logging.

 To turn this feature off, remove the registry value .

  

 Action ended 0:05:31: ValidateSerialNumber. Return value 3.

 Action ended 0:05:31: INSTALL. Return value 3.


 I am confused as to why it should bind to CLR 2.0 when i am using the target
 framework as .Net 4.0

 So,I modified the MakeSFXCA config file the following way:


 startup useLegacyV2RuntimeActivationPolicy=false
 supportedRuntime version=v4.0 /
 !-- supportedRuntime version=v2.0.50727 / --
 /startup

 Then,it throws the following error:

 SFXCA: Extracting custom action to temporary directory:
 C:\WINDOWS\Installer\MSI15.tmp-\ SFXCA: Failed to get requested CLR info.
 Error code 0x80131700 SFXCA: Ensure that the proper version of the .NET
 Framework is installed, or that there is a matching supportedRuntime element
 in CustomAction.config. 


 Could some please help me with this?

 Thanks,
 Ramya



   

-- 
Stelios Kyprou
Systems Engineer
Formicary - delivering quality financial technology solutions(TM)
www.formicary.net



This message is confidential and may be privileged. It is intended solely for
the named addressee. If you are not the intended recipient, please inform us.
Any unauthorised dissemination, distribution or copying hereof is prohibited.

Formicary Limited registered office in England and Wales, address 1 Taillar
Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number
747644304, does not guarantee that the integrity of this communication has been
maintained nor that this communication is free of viruses, interceptions or
interference.


--
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] Passing Values from the ProductModule to a MergeModule

2010-07-21 Thread bpackard


I think you can simplify what you have:

Property Id=SERVICEUSER SuppressModularization=yes/
Property Id=SERVICEPASSWORD SuppressModularization=yes/

Directory Id=TARGETDIR Name=SourceDir
   Directory Id=MergeRedirectFolder

Component Id=ServiceInstaller Guid=* DiskId=1
  ServiceInstall Id=ServiceInstaller Name=XPedientServiceHost 
  Start=auto ErrorControl=normal
Type=ownProcess
  Account=[SERVICEUSER]
Password=[SERVICEPASSWORD]
  /ServiceInstall
/Component

  /Directory
   /Directory

Then simply pass in on the command line SERVICEUSER and SERVICEPASSWORD. You
should not need the custom actions and multiple properties for the same
elements. You may need to mark the properties as secure to get them to the
execute sequence.

As for using the module configuration, I didn't find it trivial. Here is an
example that reparents an entry in the merge module's directory table with a
property from the msi:

in the merge module you would have:

Configuration Name=SMPRODNAME Format=Key Type=Identifier
DefaultValue=SMPRODNAME
   Description=Start Menu Path DisplayName=Start Menu
Folder/
Substitution Table=Directory Column=Directory_Parent Row=SMHelp
Value=[=SMPRODNAME]/

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=SMHelp Name=Help Documentation ShortName=HELPDOC
/
   ...
/Directory

The configuration updates the directory table changing the parent of the
SMHelp to be the SMPRODNAME property. This happens when the merge module is
imported by the msi. The SMPRODNAME property does not have to be defined
anywhere in the merge module.

hope this helps

-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Values-from-the-ProductModule-to-a-MergeModule-tp5318970p5321075.html
Sent from the wix-users mailing list archive at Nabble.com.

--
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

[WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20 property 
after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome dialog, if 
the .NET Framework 2.0 is not installed, a dialog appears with a link to the 
website to install the .NET framework.  When ok is clicked, it takes the user 
back to the welcome dialog.  I would then like for the user to be able to 
continue the installation after they have installed the .net framework by 
clicking the next button.  But, when the next button is clicked, the dialog box 
with the link still comes up.  If I cancel the current installation session and 
run a new one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time the 
next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
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] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer


-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.  Thank you.


--
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] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is 32-bit or 
64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.  Thank you.

--
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
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.

--
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] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer


-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.  Thank you.


--
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
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer.  Thank you.

Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Thanks.  I have been looking on google for several days and I've also looked 
into dotNetInstaller.  I had a bootstrapper working on a 32-bit system but 
there was an error on a 64-bit system.  Based on my research on google, it 
sounded as though the dotNetInstaller didn't work on a 64-bit system and I was 
unable to find another bootstrapper that would.  I was looking for a work 
around, but since you thought that the work around wouldn't work, I was 
wondering if you knew of any bootstrappers that would work on both 32-bit and 
64-bit OS because I could not find any information about one during my 
research.  If you are not aware of one, that's fine.  I am just trying to 
figure out a solution.

Another option I have is using something like:

Condition Message=[Message]PROPERTY/Condition

Is there any way that I can add a push button to the message box that shows up 
that links to the website to install the .NET framework.  I have been searching 
for an answer to this question, but am unable to find one.

I also looked into doing something like this:

Condition Message=Setup requires .NET 2.0.  Please visit 
http://msdn.microsoft.com/en-us/netframework/aa731542.aspx and 
install.PROPERTY/Condition

Then, the user could click on the link and be taken to the website.  The 
information I found stated this was not supported, but it was from a long time 
ago, so I was just wondering if support has been added for this.

Thanks for your help.  I have been struggling to find a solution for this issue 
for several days now and your help is much appreciated.

Katelyn

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer


-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 15:15
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

My setup is that, when the next button is pressed on the welcome
dialog, if the .NET Framework 2.0 is not installed, a dialog appears
with a link to the website to install the .NET framework.  When ok is
clicked, it takes the user back to the welcome dialog.  I would then
like for the user to be able to continue the installation after they
have installed the .net framework by clicking the next button.  But,
when the next button is clicked, the dialog box with the link still
comes up.  If I cancel the current installation session and run a new
one, the application is installed successfully.

So, is it possible to re-evaluate the NETFRAMEWORK20 property each time
the next button is pressed?  What is the recommended way to do so?

Thanks,
Katelyn

Note: The information contained in this message may be privileged and

Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

2010-07-21 Thread Nick Ramirez

Apparently, there's hyperlink support with MSI 5.0. Bob Arnson blogs about it
here:

http://www.joyofsetup.com/2009/01/17/msi-v50-features-in-wix-v30/

Going back to your earlier question, about re-evaluating whether .NET is
installed, the reason you're getting the same result even after .NET has
been installed is that the check is done early in the install sequence
during the AppSearch action. So, even if the condition changes, the check
has already been made and the property set. I don't think there's a way to
call that check again, either, once it's run once.

I think you're on the right track looking for a bootstrapper. That would
give you the functionality to do the check, install if needed, and then
continue on. I'm not sure which bootstrapper is the best to use. Hopefully
Burn will be out soon.

In the meantime, you may just decide to stick with your launch condition and
exit if the prerequisite isn't met. The message might just be descriptive
and tell the user that they'll need to relaunch the installer.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-evaluate-NETFRAMEWORK20-Property-tp5321265p5321865.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] Passing Values from the ProductModule to a MergeModule

2010-07-21 Thread John Bergman

Even after simplifying, the data was not passed to the merge module.  

I am working on the configuration/substitution nodes now. 

Any idea what the table name would be for the substitution for what I am trying 
to do?  

-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com] 
Sent: Wednesday, July 21, 2010 8:34 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Passing Values from the ProductModule to a MergeModule


I think you can simplify what you have:

Property Id=SERVICEUSER SuppressModularization=yes/
Property Id=SERVICEPASSWORD SuppressModularization=yes/

Directory Id=TARGETDIR Name=SourceDir
   Directory Id=MergeRedirectFolder

Component Id=ServiceInstaller Guid=* DiskId=1
  ServiceInstall Id=ServiceInstaller Name=XPedientServiceHost 
  Start=auto ErrorControl=normal
Type=ownProcess
  Account=[SERVICEUSER]
Password=[SERVICEPASSWORD]
  /ServiceInstall
/Component

  /Directory
   /Directory

Then simply pass in on the command line SERVICEUSER and SERVICEPASSWORD. You 
should not need the custom actions and multiple properties for the same 
elements. You may need to mark the properties as secure to get them to the 
execute sequence.

As for using the module configuration, I didn't find it trivial. Here is an 
example that reparents an entry in the merge module's directory table with a 
property from the msi:

in the merge module you would have:

Configuration Name=SMPRODNAME Format=Key Type=Identifier
DefaultValue=SMPRODNAME
   Description=Start Menu Path DisplayName=Start Menu 
Folder/
Substitution Table=Directory Column=Directory_Parent Row=SMHelp
Value=[=SMPRODNAME]/

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=SMHelp Name=Help Documentation ShortName=HELPDOC
/
   ...
/Directory

The configuration updates the directory table changing the parent of the SMHelp 
to be the SMPRODNAME property. This happens when the merge module is imported 
by the msi. The SMPRODNAME property does not have to be defined anywhere in the 
merge module.

hope this helps

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Values-from-the-ProductModule-to-a-MergeModule-tp5318970p5321075.html
Sent from the wix-users mailing list archive at Nabble.com.

--
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] Re-evaluate NETFRAMEWORK20 Property

dotnetinstaller works perfectly fine on x64 platforms. I use it to do
exactly what you're trying to achieve which is why I suggested looking
at it yourself.

You can't use hyperlinks in Windows Installer dialogs unless you
specifically target Windows Installer v5 which is only available on
Windows 7/Server 2008 R2, in which case you'd need to use a bootstrapper
to sequence it before your package anyway if there was a redistributable
available for it (there isn't currently  it's unlikely there ever will
be at this point).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 17:02
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Thanks.  I have been looking on google for several days and I've also
looked into dotNetInstaller.  I had a bootstrapper working on a 32-bit
system but there was an error on a 64-bit system.  Based on my research
on google, it sounded as though the dotNetInstaller didn't work on a
64-bit system and I was unable to find another bootstrapper that would.
I was looking for a work around, but since you thought that the work
around wouldn't work, I was wondering if you knew of any bootstrappers
that would work on both 32-bit and 64-bit OS because I could not find
any information about one during my research.  If you are not aware of
one, that's fine.  I am just trying to figure out a solution.

Another option I have is using something like:

Condition Message=[Message]PROPERTY/Condition

Is there any way that I can add a push button to the message box that
shows up that links to the website to install the .NET framework.  I
have been searching for an answer to this question, but am unable to
find one.

I also looked into doing something like this:

Condition Message=Setup requires .NET 2.0.  Please visit
http://msdn.microsoft.com/en-us/netframework/aa731542.aspx and
install.PROPERTY/Condition

Then, the user could click on the link and be taken to the website.  The
information I found stated this was not supported, but it was from a
long time ago, so I was just wondering if support has been added for
this.

Thanks for your help.  I have been struggling to find a solution for
this issue for several days now and your help is much appreciated.

Katelyn

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer


-Original Message-
From:

Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

 I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.

The NetFramework detection properties are all implemented via
RegistrySearch. I don't know of a good way to reevaluate them.



--
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] product id during upgrades

MergeModules don't have a ProductCode. modu...@id is a value that identifies
the module to enable modularization of properties, directories, and whatnot
for the contents of merge modules in MSIs.

You can't influence (except in a negative way) upgrade types from a merge
module. Those are 100% defined in the MSI.

-Original Message-
From: subrat agasti [mailto:subrat.w...@gmail.com] 
Sent: Tuesday, July 20, 2010 10:12 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] product id during upgrades

This applys to merge module also?

On Tue, Jul 20, 2010 at 6:30 PM, Peter Shirtcliffe
pshirtcli...@sdl.comwrote:

 You dont need to use * for product code, as long as you do change the
 product code by hand when you make a major upgrade. To make a minor
 upgrade the produce code must remain constant anyway.
 http://msdn.microsoft.com/en-us/library/aa370579%28VS.85%29.aspx

 You must change the package code every time you make any change to an
 installer, even if the wix source stays the same and only one of the
 installed files is different. Using * means you dont ever need to worry
 about it.

 -Original Message-
 From: subrat agasti [mailto:subrat.w...@gmail.com]
 Sent: 20 July 2010 13:35
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] product id during upgrades

 Hi,

 Is it necessary to have * as product id to be able to make upgrades?Do
 i need to change the package code and product code all the time to do a
 major upgrade?

 Regards,
 Subrat Agasti
 
 --
 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
 /pre
 BR style=font-size:4px;
 a href = http://www.sdl.com;img
src=http://www.sdl.com/images/emaillogo_150dpi-01.png; alt=
 www.sdl.com border=0//a
 BR
 font face=arial  size=2 a href = http://www.sdl.com;
 style=color:005740; font-weight: boldwww.sdl.com/a
 BR
 BR
 font face=arial  size=1 color=#736F6E
 bSDL PLC confidential, all rights reserved./b
 If you are not the intended recipient of this mail SDL requests and
 requires that you delete it without acting upon or copying any of its
 contents, and we further request that you advise us.BR
 SDL PLC is a public limited company registered in England and Wales.
  Registered number: 02675207.BR
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
 7DY, UK.
 /font






--
 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


--
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] Upgrade in per-user folder generates double entries in Add/Remove programs

The directory ProgramMenuFolder is defined as the All-Users Start menu when
ALLUSERS is 1.

http://msdn.microsoft.com/library/aa370882.aspx

-Original Message-
From: David Louis [mailto:clientlo...@gmail.com] 
Sent: Wednesday, July 21, 2010 2:03 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade in per-user folder generates double entries
in Add/Remove programs

Thanks Blair.

I set ALLUSERS to 1 in order to install to c:\program files by default
in both setups.

Anyway you're right: I actually don't need a per-user installation.
What I'm looking for is an option to make the program available in the
All users start menu.

On Tue, Jul 20, 2010 at 8:17 PM, Blair os...@live.com wrote:
 Was the value of ALLUSERS property different between the two
installations?
 Per-machine installations and per-user installations are basically in
 separate worlds for Windows Installer and shell components such as ARP
 show a combined view of both worlds.

 Most programs tend to be either per-user or per-machine, and most of the
 time you probably don't want to give the user a choice.

 -Original Message-
 From: David Louis [mailto:clientlo...@gmail.com]
 Sent: Tuesday, July 20, 2010 10:35 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Upgrade in per-user folder generates double entries
in
 Add/Remove programs

 Hi,

 I modified the WixUI_Advanced sample to prevent downgrading by adding
 these lines:

   Upgrade Id=UPGRADE_CODE_UID
     UpgradeVersion OnlyDetect=yes Minimum=$(var.PRODUCTVERSION)
 Property=NEWERVERSIONDETECTED IncludeMinimum=no /
     UpgradeVersion OnlyDetect=no Maximum=$(var.PRODUCTVERSION)
 Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no /
   /Upgrade
   Condition Message=A later version of [ProductName] is already
 installed. Setup will now exit.
     NOT NEWERVERSIONDETECTED OR Installed
   /Condition

   Of course, UPGRADE_CODE_UID is the same UID than the product's
 UpgradeCode property.

   This works well as long as I install to the per-machine folder.
   Installing to the per-user folder generates a second entry in add /
 remove programs instead of upgrading the product.

 Any hints?

 --
 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

--
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] Passing Values from the ProductModule to a MergeModule

I assume Property

-Original Message-
From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] 
Sent: Wednesday, July 21, 2010 9:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Passing Values from the ProductModule to a
MergeModule

Even after simplifying, the data was not passed to the merge module.  

I am working on the configuration/substitution nodes now. 

Any idea what the table name would be for the substitution for what I am
trying to do?  

-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com] 
Sent: Wednesday, July 21, 2010 8:34 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Passing Values from the ProductModule to a
MergeModule

I think you can simplify what you have:

Property Id=SERVICEUSER SuppressModularization=yes/
Property Id=SERVICEPASSWORD SuppressModularization=yes/

Directory Id=TARGETDIR Name=SourceDir
   Directory Id=MergeRedirectFolder

Component Id=ServiceInstaller Guid=* DiskId=1
  ServiceInstall Id=ServiceInstaller Name=XPedientServiceHost 
  Start=auto ErrorControl=normal
Type=ownProcess
  Account=[SERVICEUSER]
Password=[SERVICEPASSWORD]
  /ServiceInstall
/Component

  /Directory
   /Directory

Then simply pass in on the command line SERVICEUSER and SERVICEPASSWORD. You
should not need the custom actions and multiple properties for the same
elements. You may need to mark the properties as secure to get them to the
execute sequence.

As for using the module configuration, I didn't find it trivial. Here is an
example that reparents an entry in the merge module's directory table with a
property from the msi:

in the merge module you would have:

Configuration Name=SMPRODNAME Format=Key Type=Identifier
DefaultValue=SMPRODNAME
   Description=Start Menu Path DisplayName=Start Menu
Folder/
Substitution Table=Directory Column=Directory_Parent Row=SMHelp
Value=[=SMPRODNAME]/

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=SMHelp Name=Help Documentation ShortName=HELPDOC
/
   ...
/Directory

The configuration updates the directory table changing the parent of the
SMHelp to be the SMPRODNAME property. This happens when the merge module is
imported by the msi. The SMPRODNAME property does not have to be defined
anywhere in the merge module.

hope this helps

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Values
-from-the-ProductModule-to-a-MergeModule-tp5318970p5321075.html
Sent from the wix-users mailing list archive at Nabble.com.

--
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

--
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] Re-evaluate NETFRAMEWORK20 Property

Thanks for all of your responses.  If I can't get the bootstrapper up and 
running, then I am just going to go with a descriptive message.

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, July 21, 2010 11:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

dotnetinstaller works perfectly fine on x64 platforms. I use it to do
exactly what you're trying to achieve which is why I suggested looking
at it yourself.

You can't use hyperlinks in Windows Installer dialogs unless you
specifically target Windows Installer v5 which is only available on
Windows 7/Server 2008 R2, in which case you'd need to use a bootstrapper
to sequence it before your package anyway if there was a redistributable
available for it (there isn't currently  it's unlikely there ever will
be at this point).

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: 21 July 2010 17:02
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Thanks.  I have been looking on google for several days and I've also
looked into dotNetInstaller.  I had a bootstrapper working on a 32-bit
system but there was an error on a 64-bit system.  Based on my research
on google, it sounded as though the dotNetInstaller didn't work on a
64-bit system and I was unable to find another bootstrapper that would.
I was looking for a work around, but since you thought that the work
around wouldn't work, I was wondering if you knew of any bootstrappers
that would work on both 32-bit and 64-bit OS because I could not find
any information about one during my research.  If you are not aware of
one, that's fine.  I am just trying to figure out a solution.

Another option I have is using something like:

Condition Message=[Message]PROPERTY/Condition

Is there any way that I can add a push button to the message box that
shows up that links to the website to install the .NET framework.  I
have been searching for an answer to this question, but am unable to
find one.

I also looked into doing something like this:

Condition Message=Setup requires .NET 2.0.  Please visit
http://msdn.microsoft.com/en-us/netframework/aa731542.aspx and
install.PROPERTY/Condition

Then, the user could click on the link and be taken to the website.  The
information I found stated this was not supported, but it was from a
long time ago, so I was just wondering if support has been added for
this.

Thanks for your help.  I have been struggling to find a solution for
this issue for several days now and your help is much appreciated.

Katelyn

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer

-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent: 21 July 2010 16:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

Is there a bootstrapper that I can use that will detect if the OS is
32-bit or 64-bit and then install the correct .NET Framework?

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Re-evaluate NETFRAMEWORK20 Property

I doubt it's possible without modifying the WiXNetFxExtension code.

Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous  highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).

dotnetinstaller exists for this very function. See
http://dotnetinstaller.codeplex.com/ (other bootstrappers are available
e.g. Visual Studio 2005 bootstrapper).

Palbinder Sandher
Software

Re: [WiX-users] Passing Values from the ProductModule to a MergeModule - Solved (plus a question for clarification)

2010-07-21 Thread John Bergman

That is what I thought, but I was still having problems.  I have resolve the 
issue for what I need, (at least for now).

In the main product module, you need to declare the properties as follows:

Property Id=DOMAIN SuppressModularization=yes Secure=yes /
Property Id=USER SuppressModularization=yes Secure=yes /
Property Id=PASSWORD SuppressModularization=yes Secure=yes /

Then, in the Merge Module you have to set it up to receive the configuration, 
and map it to the properties, this is what I have in my merge module

Configuration Name=DOMAIN Format=Key Type=Identifier 
DefaultValue=DOMAIN Description=Service Domain DisplayName=Service 
Domain/
Configuration Name=USER Format=Key Type=Identifier 
DefaultValue=USER Description=Service User DisplayName=Service User/
Configuration Name=PASSWORD Format=Key Type=Identifier 
DefaultValue=PASSWORD Description=Service Password DisplayName=Service 
Password/

I was able to use the values in my service installer as follows:

  !-- Install the service --
  ServiceInstall
Id='ServiceInstaller'
Type='ownProcess'
Vital=yes
Name=XPedientServiceHost
DisplayName=My Service
Description=My Service
Start=auto
Account=[DOMAIN]\[USER]
Password=[PASSWORD]
ErrorControl=normal
Interactive=no 
ServiceDependency Id=Eventlog /
util:ServiceConfig FirstFailureActionType=restart 
SecondFailureActionType=restart ThirdFailureActionType=restart/
  /ServiceInstall

You also have to declare the properties

Property Id=DOMAIN SuppressModularization=yes Secure=yes /
Property Id=USER SuppressModularization=yes Secure=yes /
Property Id=PASSWORD SuppressModularization=yes Secure=yes /


What I was unable to get working is the code that combines the Domain\User in a 
custom action, I suppose this has to do with the  ordering if the CA,

Property Id=PermissionableUser Value=user/
CustomAction Id='SetPermissionableUser' Property='PermissionableUser' 
Value='[DOMAIN]\[USER]' /


InstallExecuteSequence 
  Custom Action='SetPermissionableUser' After='LaunchConditions'/Custom
/InstallExecuteSequence

Can someone comment as to when the CA should execute to have access to the 
imported properties?  The location above does not work because the values are 
still initialized.

(Also, Thanks to everyone that provided pointers, this would be a good 
candidate for the WiX Wiki or tutorial, should someone care to add it).  I 
pruned the rest of the conversation so that this message is uncluttered.

--
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

[WiX-users] Wcalog does not log

2010-07-21 Thread Fangren


I have a custom action that does not log no matter what method is used to
turn logging on.  Even though it executes correctly.  I can see the property
being set in the log and the custom action begin and end.

Code example (made generic):

extern C UINT __stdcall MyCustomAction(MSIHANDLE install)
{
CUSTOM_ACTION_BEGIN
{
HRESULT hr = ::WcaInitialize(install, MyCustomAction);
if (FAILED(hr))
{
return ERROR_INSTALL_FAILURE;
}

::WcaLog(LOGMSG_STANDARD, Establishing MyCustomAction);

std::wstring info = GenerateInfo();
SaveMsiProperty(install, LREGISTEREDINFO, info);

::WcaLog(LOGMSG_VERBOSE, Info is %S, info);

return ::WcaFinalize(ERROR_SUCCESS);
}
CUSTOM_ACTION_END
}


Based on research it appears there is a bug in wcautil that prevent deferred
custom actions from logging.  Looking into this I found the following:

http://www.joyofsetup.com/2008/07/15/verbose-logging-from-wcautil/
In the comments is the mention of a bug being created in 2008.

I did find a similar bug on SouceForge: ID 1845036.
https://sourceforge.net/tracker/index.php?func=detailaid=1845036group_id=105970atid=642714

This bug was closed because they weren't sure how to reproduce it.  I have
been able to consistently reproduce this through use of deferred custom
actions.  Logging works as expected in my non-deferred custom actions.

Does anyone know if this has been fixed yet?  If not is there a method to
re-open the bug or should I submit a new one?

I did try this in a 3.5 based build and the same problem still existed.


-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wcalog-does-not-log-tp5322711p5322711.html
Sent from the wix-users mailing list archive at Nabble.com.

--
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

[WiX-users] Can environment variables be expanded in a WXL file?

2010-07-21 Thread Sharat Janapareddy

I am trying to use some environment variables in a WXL file where I store the 
localized strings for my MSPs. However, they don't seem to be resolved! 
Assuming 'Var' is my environment variable, I tried $(env.Var), just the 
env.Var, etc. but none of them worked. Is this even possible? If so, please 
share the syntax for it.

Thanks,

Sharat Janapareddy
~ 40269

--
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

[WiX-users] Upgrading from other setup program to WiX/MSI

Hi,

Today I began creating my first WiX project. Until now I used 
SetupSpecialist but as I am facing serious problems with it I want to 
use WiX in future.

This is my first big question: On clients' computers there will be an 
old instance of my program (with SetupSpecialist) installed. Even worse: 
My new version requires the setup to be run as administrator.

However, the old versions might be installed as normal users.

What is the best way to handle this situation?

Thank you.

Regards,
Luke


--
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

[WiX-users] Automatically include arbitrary files

Hi,

My setup project consists of a bunch of static files (application, 
DLL), a huge databasefile and a vast amount of PDF files. The PDF files 
are very volatile, they change from update to update (some are removed, 
some are added but no of them are changed).

As they are many files I would really prefer to add them automatically.

I looked at the include-directive from the preprocessor but I can't find 
out how to automate.

I looked at fragments and played around with heat. In general, this 
would work. heat generates a wxs file containing a list of all pdf 
files. However, I have all of them to add to the Feature-List in my 
main file as ComponentRef-element!

Isn't there a way to include the whole fragment and/or directory?

Even if this would work, I still have to manually add/remove the items 
in the pdfs.wxs.

It would be really great if I could just put the current PDFs in the 
diretory pdfs and all of them are just added to the MSI.

However, if I run heat multiple times I clearly get different GUIDs for 
the PDFs on each call.

Does it matter when the GUIDs of the files change? Especially for the 
update?

Is there any chance to automate this process consistently?

Best Regards,
Luke


--
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] Registering COM DLLs using HEAT Tool.

Dear Pally,

I have the same problem. BIG HINT for all users!

When you get

heat.exe : warning HEAT5150 : Could not harvest data from a file that 
was expected to be a SelfReg
DLL: TestProtocol.dll. If this file does not support SelfReg you can
ignore this warning. Otherwise, this error detail may be helpful to 
diagnose the failure: Exception of type 'System.Exception' was thrown..

then probably you should try again as administrator!
And make sure the DLL is not yet registered!

But I have an important question: heat generates all entries with

   Action=write

Wouldn't it be better to use

   Action='createAndRemoveOnUninstall'

?

Regards,
Luke



Am 21.07.2010 11:24, schrieb Pally Sandher:
 heat.exe /? or http://wix.sourceforge.net/manual-wix3/heat.htm or
 http://www.tramontana.co.hu/wix/lesson6.php#6.1 might be good places to
 start.

 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with theVirtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No.
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park,
 Glasgow G20 0SP
 Email Disclaimer

 -Original Message-
 From: vijay chander [mailto:vijaychander2...@gmail.com]
 Sent: 21 July 2010 04:51
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Registering COM DLLs using HEAT Tool.

 Hi All,

 I have read that we can register dlls using heat tool, just by using
 .wxs file which will be generated by heat tool.
 So can anyone tell me how to register a COM DLL using HEAT Tool?
 With Regards,
 Vijay
 
 --
 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



--
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] .NET Framework 2.0 Bootstrapper

2010-07-21 Thread Chad Petersen

Here's a link for XP 64-bit and Windows 2003 x64 .NET 2.0
Redistributable Package

http://www.microsoft.com/downloads/details.aspx?familyid=B44A-ACF8-4
FA1-AFFB-40E78D788B00displaylang=en



-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
Sent: Tuesday, July 20, 2010 12:57 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] .NET Framework 2.0 Bootstrapper

A quick follow up question - 
Dotnetfx is for 32-bit os.  What is for 64-bit os and where can I
download it?

Thanks,
Katelyn

-Original Message-
From: Daniel Moody [mailto:dani...@gibbscam.com] 
Sent: Tuesday, July 20, 2010 1:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] .NET Framework 2.0 Bootstrapper

Katelyn,

I had the same issue myself.  In my case (on a 64-bit OS), the .bin
files
were installed in the Program Files (x86) folder rather than Program
Files.  I didn't copy any files around that I can recall.  I used the
following Path statement:
Path=C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\ /

Everything else is identical to what you have.

Hopefully this might be helpful.

Daniel Moody | QA Engineer | Gibbs and Associates

Phone: 805-523-0004
Email: dani...@gibbscam.com

www.GibbsCAM.com

-Original Message-
Message: 6
Date: Tue, 20 Jul 2010 13:48:56 -0400
From: Thode, Katelyn katelyn.th...@guidancesoftware.com
Subject: [WiX-users] .NET Framework 2.0 Bootstrapper
To: wix-users@lists.sourceforge.net
wix-users@lists.sourceforge.net
Message-ID:

0fb074876ea3344bacf850c6c47681df0bd18...@postva.guidancesoftware.com
Content-Type: text/plain; charset=us-ascii

I am trying to use Microsoft Visual Studio 2005's bootstrapper to
install
the .NET Framework 2.0 if necessary.  Based on documentation I have
found, I
have the following in my .wixproj file:

  ItemGroup
BootstrapperFile Include=Microsoft.Net.Framework.2.0
  ProductName.NET Framework 2.0/ProductName
/BootstrapperFile
  /ItemGroup
  !--Target Name=BeforeBuild
  /Target--
  Target Name=AfterBuild
GenerateBootstrapper ApplicationFile=$(TargetFileName)
  ApplicationName=Tableau Disk Manager
  BootstrapperItems=@(BootstrapperFile)
  ComponentsLocation=Relative
  CopyComponents=True
  OutputPath=$(OutputPath)
  Path=C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx/

When I try to build the project, I get the following error messages:
warning MSB3155: Item 'Microsoft.Net.Framework.2.0' could not be located
in
'C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx'.
error MSB3147: Could not find required file 'setup.bin' in 'C:\Program
Files\Microsoft
SDKs\Windows\v7.0A\Bootstrapper\Packages\dotnetfx\Engine'.

I copied the dotnetfx folder into the Packages folder per documentation
I
found online.  I am struggling to find any information as to what I am
doing
wrong and any help would be appreciated.

Thanks,
Katelyn




--
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
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible 
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by replying to the 
message and deleting it from your computer.  Thank you.



--
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] Can environment variables be expanded in a WXL file?

No. The preprocessor runs as part of loading the WXS files in the candle
tool, and WXL files are not even accessed until either the light tool or the
lit tool, which don't use the preprocessor.

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Wednesday, July 21, 2010 1:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Can environment variables be expanded in a WXL file?

I am trying to use some environment variables in a WXL file where I store
the localized strings for my MSPs. However, they don't seem to be resolved!
Assuming 'Var' is my environment variable, I tried $(env.Var), just the
env.Var, etc. but none of them worked. Is this even possible? If so, please
share the syntax for it.

Thanks,

Sharat Janapareddy
~ 40269

--
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] Automatically include arbitrary files

In your settings for heat, you should use automatic component guids (they
come out as Guid=*) and you should setup a component group for your PDF
files (then you can simply refer to them from your feature using the
ComponentGroupRef element). 

-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at] 
Sent: Wednesday, July 21, 2010 1:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Automatically include arbitrary files

Hi,

My setup project consists of a bunch of static files (application, 
DLL), a huge databasefile and a vast amount of PDF files. The PDF files 
are very volatile, they change from update to update (some are removed, 
some are added but no of them are changed).

As they are many files I would really prefer to add them automatically.

I looked at the include-directive from the preprocessor but I can't find 
out how to automate.

I looked at fragments and played around with heat. In general, this 
would work. heat generates a wxs file containing a list of all pdf 
files. However, I have all of them to add to the Feature-List in my 
main file as ComponentRef-element!

Isn't there a way to include the whole fragment and/or directory?

Even if this would work, I still have to manually add/remove the items 
in the pdfs.wxs.

It would be really great if I could just put the current PDFs in the 
diretory pdfs and all of them are just added to the MSI.

However, if I run heat multiple times I clearly get different GUIDs for 
the PDFs on each call.

Does it matter when the GUIDs of the files change? Especially for the 
update?

Is there any chance to automate this process consistently?

Best Regards,
Luke

--
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

[WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke




[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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

Re: [WiX-users] Registering COM DLLs using HEAT Tool.

Registry entries created with an action of 'write' are removed upon
uninstall of the component. The action called 'createAndRemoveOnUninstall'
applies to keys and removes all entries of that key, whether created by
Windows Installer or not, and is not needed in most cases. It is a case of
the name of the action following the official documentation even though the
official label for the activity is misleading at best...

-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at] 
Sent: Wednesday, July 21, 2010 2:03 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Registering COM DLLs using HEAT Tool.

Dear Pally,

I have the same problem. BIG HINT for all users!

When you get

heat.exe : warning HEAT5150 : Could not harvest data from a file that 
was expected to be a SelfReg
DLL: TestProtocol.dll. If this file does not support SelfReg you can
ignore this warning. Otherwise, this error detail may be helpful to 
diagnose the failure: Exception of type 'System.Exception' was thrown..

then probably you should try again as administrator!
And make sure the DLL is not yet registered!

But I have an important question: heat generates all entries with

   Action=write

Wouldn't it be better to use

   Action='createAndRemoveOnUninstall'

?

Regards,
Luke



Am 21.07.2010 11:24, schrieb Pally Sandher:
 heat.exe /? or http://wix.sourceforge.net/manual-wix3/heat.htm or
 http://www.tramontana.co.hu/wix/lesson6.php#6.1 might be good places to
 start.

 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with theVirtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No.
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park,
 Glasgow G20 0SP
 Email Disclaimer

 -Original Message-
 From: vijay chander [mailto:vijaychander2...@gmail.com]
 Sent: 21 July 2010 04:51
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Registering COM DLLs using HEAT Tool.

 Hi All,

 I have read that we can register dlls using heat tool, just by using
 .wxs file which will be generated by heat tool.
 So can anyone tell me how to register a COM DLL using HEAT Tool?
 With Regards,
 Vijay
 
 --
 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




--
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] Does the msi-filename matter?

It is true that changing the MSI file name forces a major upgrade.  If you are 
concerned that your user will interfere with your servicing strategy by 
renaming 
the MSI, you can use the OriginalDatabase property in a LaunchCondition to 
abort 
the install if they have renamed the MSI.  I would suggest something like 


[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi 

http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx
 
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 4:42:20 PM
Subject: [WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke




[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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] Automatically include arbitrary files

Dear Blair,

I do not fully understand. You mean the -ag switch?

But then on every compile the PDF files get a different GUID, don't 
they? Then back to the original question: Does it matter in ANY way if 
they get a different GUID on upgrades?

I.e. In a few months I will make the first upgrade for for my product. 
Most likely a few PDFs will be removed, a few will be added. Is there 
any concern with your proposed method?

Regards,
  Luke



Am 21.07.2010 23:41, schrieb Blair:
 In your settings for heat, you should use automatic component guids (they
 come out as Guid=*) and you should setup a component group for your PDF
 files (then you can simply refer to them from your feature using the
 ComponentGroupRef element).

 -Original Message-
 From: Lukas Haase [mailto:lukasha...@gmx.at]
 Sent: Wednesday, July 21, 2010 1:29 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Automatically include arbitrary files

 Hi,

 My setup project consists of a bunch of static files (application,
 DLL), a huge databasefile and a vast amount of PDF files. The PDF files
 are very volatile, they change from update to update (some are removed,
 some are added but no of them are changed).

 As they are many files I would really prefer to add them automatically.

 I looked at the include-directive from the preprocessor but I can't find
 out how to automate.

 I looked at fragments and played around with heat. In general, this
 would work. heat generates a wxs file containing a list of all pdf
 files. However, I have all of them to add to theFeature-List in my
 main file asComponentRef-element!

 Isn't there a way to include the whole fragment and/or directory?

 Even if this would work, I still have to manually add/remove the items
 in the pdfs.wxs.

 It would be really great if I could just put the current PDFs in the
 diretory pdfs and all of them are just added to the MSI.

 However, if I run heat multiple times I clearly get different GUIDs for
 the PDFs on each call.

 Does it matter when the GUIDs of the files change? Especially for the
 update?

 Is there any chance to automate this process consistently?

 Best Regards,
 Luke


 
 --
 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



--
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] Does the msi-filename matter?

That could help reduce the chance of that problem, but depending on which
file the user changes (the initial or the update) you may not get a chance
to warn the user to not rename the MSI.

In most of the failure cases I have seen due to not finding the MSI file at
the indicated directory caused by looking for a different name than expected
(usually due to attempting a minor upgrade using an MSI downloaded using IE)
Windows Installer never even starts parsing any sequence table.

This is part of the reason huge numbers of software producers distributing
over the internet use self-extract-and-launch-style wrappers (zip-exe style)
for their MSI distribution.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Wednesday, July 21, 2010 2:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does the msi-filename matter?

It is true that changing the MSI file name forces a major upgrade.  If you
are 
concerned that your user will interfere with your servicing strategy by
renaming 
the MSI, you can use the OriginalDatabase property in a LaunchCondition to
abort 
the install if they have renamed the MSI.  I would suggest something like 


[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi 

http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx
 
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 4:42:20 PM
Subject: [WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke




[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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


--
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] Automatically include arbitrary files

Am 22.07.2010 00:07, schrieb Lukas Haase:
 Dear Blair,

 I do not fully understand. You mean the -ag switch?

 But then on every compile the PDF files get a different GUID, don't
 they? Then back to the original question: Does it matter in ANY way if
 they get a different GUID on upgrades?

 I.e. In a few months I will make the first upgrade for for my product.
 Most likely a few PDFs will be removed, a few will be added. Is there
 any concern with your proposed method?

Dear Blair,

Sorry, I forget one additional question:

Heat generates the File-Elements as:

File Id=fil6CD3EB10EF7C12F5645E92DEC7FA408E KeyPath=yes
Source=SourceDir\04156.pdf /
 ^

but in fact I placed the PDFs (relative to the directory from where I 
call candle/light) in
   src\INSTALLDIR\pdf

Is there any way to replace SourceDir with src\INSTALLDIR\pdf 
automatically? Or is there another solution?

Similar the directory with is created as:

DirectoryRef Id=TARGETDIR
   ^
   Directory Id=dir92AEA0E44CFC478DB41459D407BB54A9 Name=pdf /
/DirectoryRef

But in fact it should be DirectoryRef Id=INSTALLDIR in order to work...

Thank you very much.

Regards,
Luke




 Am 21.07.2010 23:41, schrieb Blair:
 In your settings for heat, you should use automatic component guids (they
 come out as Guid=*) and you should setup a component group for your PDF
 files (then you can simply refer to them from your feature using the
 ComponentGroupRef element).

 -Original Message-
 From: Lukas Haase [mailto:lukasha...@gmx.at]
 Sent: Wednesday, July 21, 2010 1:29 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Automatically include arbitrary files

 Hi,

 My setup project consists of a bunch of static files (application,
 DLL), a huge databasefile and a vast amount of PDF files. The PDF files
 are very volatile, they change from update to update (some are removed,
 some are added but no of them are changed).

 As they are many files I would really prefer to add them automatically.

 I looked at the include-directive from the preprocessor but I can't find
 out how to automate.

 I looked at fragments and played around with heat. In general, this
 would work. heat generates a wxs file containing a list of all pdf
 files. However, I have all of them to add to theFeature-List in my
 main file asComponentRef-element!

 Isn't there a way to include the whole fragment and/or directory?

 Even if this would work, I still have to manually add/remove the items
 in the pdfs.wxs.

 It would be really great if I could just put the current PDFs in the
 diretory pdfs and all of them are just added to the MSI.

 However, if I run heat multiple times I clearly get different GUIDs for
 the PDFs on each call.

 Does it matter when the GUIDs of the files change? Especially for the
 update?

 Is there any chance to automate this process consistently?

 Best Regards,
 Luke


 
 --
 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



 --
 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



--
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] Does the msi-filename matter?

Dear Blair, Dear Christopher,

Thank you for your reply.

Am 22.07.2010 00:11, schrieb Blair:
 [...]
 This is part of the reason huge numbers of software producers distributing
 over the internet use self-extract-and-launch-style wrappers (zip-exe style)
 for their MSI distribution.

Do you have a recommendation for such a tool?

 [...]
 It is true that changing the MSI file name forces a major upgrade.

Isn't this really dumb? I am kind of disappointed of MSI... Everything 
gets a GUID in order to be REALLY sure that everything just depends on 
an ID and not on a name etc. And then...that?!

 [...] I would suggest something like
 [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi
 http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

 http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Is this what you mean?

Condition Message=You must not rename the msi file!
OriginalDatabase ~ \MYSUPPORTEDFILENAME.msi
/Condition

Regards,
Luke


 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Lukas Haaselukasha...@gmx.at
 To: wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 4:42:20 PM
 Subject: [WiX-users] Does the msi-filename matter?

 Hi,

 Does the filename of the msi file matter in any way?

 I really DO NOT hope so! Because I have no influence if the user renames
 the file before installing?!

 [1] says: There are cases when the Windows Installer forces you to use
 a major upgrade [...] You have to when you change the name of the .msi
 file for any reason. [...]

 Regards,
 Luke




 [1] http://www.tramontana.co.hu/wix/lesson4.php#4.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


 --
 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



--
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] Automatically include arbitrary files

-ag switch: sets the guid of each generated component as *. This cause the
compiler to compute a GUID based on the directory tree the component is in
and the name of the keypath. This results in stable GUIDs that don't change
between builds unless you change the directory or the filename (and in
either of those cases, you want a new guid). -ag should have been the
default in heat from the beginning.

If you use -gg, the guids will be different every time, and that would be
bad. The * for guids in the compiler means generate and the algorithm
for guid generation is different based on what the guid is for, but always
with an eye toward the safest results for as many cases as possible.

Since you are adding and removing PDF files, you should be planning on only
using Major Upgrades, and so your Product/@Id value should also be * (in
that case, the algorithm simply generates a new guid each time, which is the
primary requirement for generating major upgrades).

SourceFile directory: Easiest fix (from my point of view) is to use the -var
switch, and tell the compiler where to look. Something like this:

Heat ... -var PdfFolder ...
Candle ... -dPdfFolder=src\INSTALLDIR\pdf\ ...

Blair

-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at] 
Sent: Wednesday, July 21, 2010 3:17 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Automatically include arbitrary files

Am 22.07.2010 00:07, schrieb Lukas Haase:
 Dear Blair,

 I do not fully understand. You mean the -ag switch?

 But then on every compile the PDF files get a different GUID, don't
 they? Then back to the original question: Does it matter in ANY way if
 they get a different GUID on upgrades?

 I.e. In a few months I will make the first upgrade for for my product.
 Most likely a few PDFs will be removed, a few will be added. Is there
 any concern with your proposed method?

Dear Blair,

Sorry, I forget one additional question:

Heat generates the File-Elements as:

File Id=fil6CD3EB10EF7C12F5645E92DEC7FA408E KeyPath=yes
Source=SourceDir\04156.pdf /
 ^

but in fact I placed the PDFs (relative to the directory from where I 
call candle/light) in
   src\INSTALLDIR\pdf

Is there any way to replace SourceDir with src\INSTALLDIR\pdf 
automatically? Or is there another solution?

Similar the directory with is created as:

DirectoryRef Id=TARGETDIR
   ^
   Directory Id=dir92AEA0E44CFC478DB41459D407BB54A9 Name=pdf /
/DirectoryRef

But in fact it should be DirectoryRef Id=INSTALLDIR in order to work...

Thank you very much.

Regards,
Luke




 Am 21.07.2010 23:41, schrieb Blair:
 In your settings for heat, you should use automatic component guids (they
 come out as Guid=*) and you should setup a component group for your PDF
 files (then you can simply refer to them from your feature using the
 ComponentGroupRef element).

 -Original Message-
 From: Lukas Haase [mailto:lukasha...@gmx.at]
 Sent: Wednesday, July 21, 2010 1:29 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Automatically include arbitrary files

 Hi,

 My setup project consists of a bunch of static files (application,
 DLL), a huge databasefile and a vast amount of PDF files. The PDF files
 are very volatile, they change from update to update (some are removed,
 some are added but no of them are changed).

 As they are many files I would really prefer to add them automatically.

 I looked at the include-directive from the preprocessor but I can't find
 out how to automate.

 I looked at fragments and played around with heat. In general, this
 would work. heat generates a wxs file containing a list of all pdf
 files. However, I have all of them to add to theFeature-List in my
 main file asComponentRef-element!

 Isn't there a way to include the whole fragment and/or directory?

 Even if this would work, I still have to manually add/remove the items
 in the pdfs.wxs.

 It would be really great if I could just put the current PDFs in the
 diretory pdfs and all of them are just added to the MSI.

 However, if I run heat multiple times I clearly get different GUIDs for
 the PDFs on each call.

 Does it matter when the GUIDs of the files change? Especially for the
 update?

 Is there any chance to automate this process consistently?

 Best Regards,
 Luke




 --
 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

Re: [WiX-users] Does the msi-filename matter?

2010-07-21 Thread Neil Sleightholm

But a key point is that this is only a possible** problem for minor upgrades. 
If you do major upgrades you can ignore it.

**I say possible because I have never seen an issue but I mainly stick to major 
upgrade because they are less hassle.

Neil

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: 21 July 2010 23:12
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Does the msi-filename matter?

That could help reduce the chance of that problem, but depending on which
file the user changes (the initial or the update) you may not get a chance
to warn the user to not rename the MSI.

In most of the failure cases I have seen due to not finding the MSI file at
the indicated directory caused by looking for a different name than expected
(usually due to attempting a minor upgrade using an MSI downloaded using IE)
Windows Installer never even starts parsing any sequence table.

This is part of the reason huge numbers of software producers distributing
over the internet use self-extract-and-launch-style wrappers (zip-exe style)
for their MSI distribution.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Wednesday, July 21, 2010 2:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does the msi-filename matter?

It is true that changing the MSI file name forces a major upgrade.  If you
are 
concerned that your user will interfere with your servicing strategy by
renaming 
the MSI, you can use the OriginalDatabase property in a LaunchCondition to
abort 
the install if they have renamed the MSI.  I would suggest something like 


[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi 

http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx
 
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 4:42:20 PM
Subject: [WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke




[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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


--
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] Upgrading from other setup program to WiX/MSI

1. You can build MSIs with WiX that don't require running the setup as
administrator. Nothing that can be done outside of Windows Installer without
elevation requires elevation in Windows Installer to also do.

2. Windows Installer has no built-in support for detecting/removing non-MSI
packages. However, if you know how to find/remove your SetupSpecialist
package (the Uninstall key, perhaps?) then you can detect presence and
automate removal as part of your upgrade (does the old installer allow
silent removal?) You may have trouble detecting/removing things installed
by other than the current user, however, but that is due to the nature of
how Windows treats user accounts/profiles, not do to any inherent limitation
in Windows Installer itself.

-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at] 
Sent: Wednesday, July 21, 2010 1:20 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading from other setup program to WiX/MSI

Hi,

Today I began creating my first WiX project. Until now I used 
SetupSpecialist but as I am facing serious problems with it I want to 
use WiX in future.

This is my first big question: On clients' computers there will be an 
old instance of my program (with SetupSpecialist) installed. Even worse: 
My new version requires the setup to be run as administrator.

However, the old versions might be installed as normal users.

What is the best way to handle this situation?

Thank you.

Regards,
Luke



--
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] Does the msi-filename matter?

InstallShield grin/

Seriously, I'm warming up to WiX but I still only use it for my merge module 
development ( hundreds of them ).   I still consume them with InstallShield 
Product Configurations to support dozens of products with upwards to 15,000 
files each and dozens of third party packages to be bootstrapped before my 
MSI.   One day ( year ) WiX will have Burn and I'll reevaluate that strategy.

Regards,
Chris
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 5:26:46 PM
Subject: Re: [WiX-users] Does the msi-filename matter?

Dear Blair, Dear Christopher,

Thank you for your reply.

Am 22.07.2010 00:11, schrieb Blair:
 [...]
 This is part of the reason huge numbers of software producers distributing
 over the internet use self-extract-and-launch-style wrappers (zip-exe style)
 for their MSI distribution.

Do you have a recommendation for such a tool?

 [...]
 It is true that changing the MSI file name forces a major upgrade.

Isn't this really dumb? I am kind of disappointed of MSI... Everything 
gets a GUID in order to be REALLY sure that everything just depends on 
an ID and not on a name etc. And then...that?!

 [...] I would suggest something like
 [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi
 http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

 http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Is this what you mean?

Condition Message=You must not rename the msi file!
    OriginalDatabase ~ \MYSUPPORTEDFILENAME.msi
/Condition

Regards,
Luke


 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Lukas Haaselukasha...@gmx.at
 To: wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 4:42:20 PM
 Subject: [WiX-users] Does the msi-filename matter?

 Hi,

 Does the filename of the msi file matter in any way?

 I really DO NOT hope so! Because I have no influence if the user renames
 the file before installing?!

 [1] says: There are cases when the Windows Installer forces you to use
 a major upgrade [...] You have to when you change the name of the .msi
 file for any reason. [...]

 Regards,
 Luke




 [1] http://www.tramontana.co.hu/wix/lesson4.php#4.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


 --
 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



--
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] Does the msi-filename matter?

Same here.  I've heard people post for years about how Major Upgrades are a 
pain 
and you better follow the component rules to a letter if you want minor 
upgrades, small updates and patching to work.   I've choosen to only support 
Major Upgrades and it's a bit of a vindication to now see the likes of Rob talk 
about why WiX's own installer only does Major Upgrades.
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Neil Sleightholm n...@x2systems.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 5:58:54 PM
Subject: Re: [WiX-users] Does the msi-filename matter?

But a key point is that this is only a possible** problem for minor upgrades. 
If 
you do major upgrades you can ignore it.

**I say possible because I have never seen an issue but I mainly stick to major 
upgrade because they are less hassle.

Neil

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: 21 July 2010 23:12
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Does the msi-filename matter?

That could help reduce the chance of that problem, but depending on which
file the user changes (the initial or the update) you may not get a chance
to warn the user to not rename the MSI.

In most of the failure cases I have seen due to not finding the MSI file at
the indicated directory caused by looking for a different name than expected
(usually due to attempting a minor upgrade using an MSI downloaded using IE)
Windows Installer never even starts parsing any sequence table.

This is part of the reason huge numbers of software producers distributing
over the internet use self-extract-and-launch-style wrappers (zip-exe style)
for their MSI distribution.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Wednesday, July 21, 2010 2:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does the msi-filename matter?

It is true that changing the MSI file name forces a major upgrade.  If you
are 
concerned that your user will interfere with your servicing strategy by
renaming 
the MSI, you can use the OriginalDatabase property in a LaunchCondition to
abort 
the install if they have renamed the MSI.  I would suggest something like 


[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi 

http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx
 
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 4:42:20 PM
Subject: [WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke




[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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


--
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] Does the msi-filename matter?

I have often said (even on this list) that for most products, Major Upgrades
are the way to go. Until your distribution strategy requires supporting MSP
files, and you feel more technically confident in your abilities in Windows
Installer deployment technologies, just set things up for Major Upgrades and
get on with your life.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Wednesday, July 21, 2010 4:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does the msi-filename matter?

Same here.  I've heard people post for years about how Major Upgrades are a
pain 
and you better follow the component rules to a letter if you want minor 
upgrades, small updates and patching to work.   I've choosen to only support

Major Upgrades and it's a bit of a vindication to now see the likes of Rob
talk 
about why WiX's own installer only does Major Upgrades.

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me

- Original Message 
From: Neil Sleightholm n...@x2systems.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 5:58:54 PM
Subject: Re: [WiX-users] Does the msi-filename matter?

But a key point is that this is only a possible** problem for minor
upgrades. If 
you do major upgrades you can ignore it.

**I say possible because I have never seen an issue but I mainly stick to
major 
upgrade because they are less hassle.

Neil

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: 21 July 2010 23:12
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Does the msi-filename matter?

That could help reduce the chance of that problem, but depending on which
file the user changes (the initial or the update) you may not get a chance
to warn the user to not rename the MSI.

In most of the failure cases I have seen due to not finding the MSI file at
the indicated directory caused by looking for a different name than expected
(usually due to attempting a minor upgrade using an MSI downloaded using IE)
Windows Installer never even starts parsing any sequence table.

This is part of the reason huge numbers of software producers distributing
over the internet use self-extract-and-launch-style wrappers (zip-exe style)
for their MSI distribution.

-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Wednesday, July 21, 2010 2:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does the msi-filename matter?

It is true that changing the MSI file name forces a major upgrade.  If you
are 
concerned that your user will interfere with your servicing strategy by
renaming 
the MSI, you can use the OriginalDatabase property in a LaunchCondition to
abort 
the install if they have renamed the MSI.  I would suggest something like 

[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi 

http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me

- Original Message 
From: Lukas Haase lukasha...@gmx.at
To: wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 4:42:20 PM
Subject: [WiX-users] Does the msi-filename matter?

Hi,

Does the filename of the msi file matter in any way?

I really DO NOT hope so! Because I have no influence if the user renames 
the file before installing?!

[1] says: There are cases when the Windows Installer forces you to use 
a major upgrade [...] You have to when you change the name of the .msi 
file for any reason. [...]

Regards,
Luke

[1] http://www.tramontana.co.hu/wix/lesson4.php#4.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

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first --

Re: [WiX-users] Does the msi-filename matter?

#1
How long before you ship?
Search for self-extract and many of what comes up can be set to run a
command-line at the end of the extract. I recently used some sort of
WinZip-like program. I've also successfully used IExpress in the past.

#2
As far as I have been able to gather the reason is that Windows Installer
stores two bits of data separately: the SourceList which are a list of
directories used to search for cached copies of the original MSI file, and
the name of the MSI, in case some of those cache directories contain other
MSI files as well. So, they combine each path with the expected filename and
if they don't find the package with the needed PackageGuid, they continue on
to the next path in the list, prompting and/or failing when they are done.

#3
I can't speak for Christopher but I would assume he was indicating something
like this:
Condition Message=You must not rename the msi file!
[OriginalDatabase]  \MYSUPPORTEDFILENAME.msi
/Condition

The comparison operator is  (that isn't an email artifact).

However, I'm concerned that may cause repairs and/or removals to fail.


-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at] 
Sent: Wednesday, July 21, 2010 3:27 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Does the msi-filename matter?

Dear Blair, Dear Christopher,

Thank you for your reply.

Am 22.07.2010 00:11, schrieb Blair:
 [...]
 This is part of the reason huge numbers of software producers distributing
 over the internet use self-extract-and-launch-style wrappers (zip-exe
style)
 for their MSI distribution.

Do you have a recommendation for such a tool?

 [...]
 It is true that changing the MSI file name forces a major upgrade.

Isn't this really dumb? I am kind of disappointed of MSI... Everything 
gets a GUID in order to be REALLY sure that everything just depends on 
an ID and not on a name etc. And then...that?!

 [...] I would suggest something like
 [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi
 http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

 http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

Is this what you mean?

Condition Message=You must not rename the msi file!
OriginalDatabase ~ \MYSUPPORTEDFILENAME.msi
/Condition

Regards,
Luke


 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Lukas Haaselukasha...@gmx.at
 To: wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 4:42:20 PM
 Subject: [WiX-users] Does the msi-filename matter?

 Hi,

 Does the filename of the msi file matter in any way?

 I really DO NOT hope so! Because I have no influence if the user renames
 the file before installing?!

 [1] says: There are cases when the Windows Installer forces you to use
 a major upgrade [...] You have to when you change the name of the .msi
 file for any reason. [...]

 Regards,
 Luke




 [1] http://www.tramontana.co.hu/wix/lesson4.php#4.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




--
 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




--
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] Wcalog does not log

WcaLog just calls MSI APIs. You might try debugging down to see if the MSI
API calls are return failures.

I've never seen a problem with logging except that you can't log at all from
a button push.

On Wed, Jul 21, 2010 at 1:05 PM, Fangren tim.kr...@shavlik.com wrote:


 I have a custom action that does not log no matter what method is used to
 turn logging on.  Even though it executes correctly.  I can see the
 property
 being set in the log and the custom action begin and end.

 Code example (made generic):

 extern C UINT __stdcall MyCustomAction(MSIHANDLE install)
 {
CUSTOM_ACTION_BEGIN
{
HRESULT hr = ::WcaInitialize(install, MyCustomAction);
if (FAILED(hr))
{
return ERROR_INSTALL_FAILURE;
}

::WcaLog(LOGMSG_STANDARD, Establishing MyCustomAction);

std::wstring info = GenerateInfo();
SaveMsiProperty(install, LREGISTEREDINFO, info);

::WcaLog(LOGMSG_VERBOSE, Info is %S, info);

return ::WcaFinalize(ERROR_SUCCESS);
}
CUSTOM_ACTION_END
 }


 Based on research it appears there is a bug in wcautil that prevent
 deferred
 custom actions from logging.  Looking into this I found the following:

 http://www.joyofsetup.com/2008/07/15/verbose-logging-from-wcautil/
 In the comments is the mention of a bug being created in 2008.

 I did find a similar bug on SouceForge: ID 1845036.

 https://sourceforge.net/tracker/index.php?func=detailaid=1845036group_id=105970atid=642714

 This bug was closed because they weren't sure how to reproduce it.  I have
 been able to consistently reproduce this through use of deferred custom
 actions.  Logging works as expected in my non-deferred custom actions.

 Does anyone know if this has been fixed yet?  If not is there a method to
 re-open the bug or should I submit a new one?

 I did try this in a 3.5 based build and the same problem still existed.


 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wcalog-does-not-log-tp5322711p5322711.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 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




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
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] Does the msi-filename matter?

Uhh, I personally always recommend Major Upgrades over all the other
options. IMHO, the other options (minor updates and small updates) add pain
that is rarely worth it (i.e. you have to be really big with lots of
customers to bother with .msp's).

I'd be curious to see who actually recommends anything but Major Upgrades
for the general case.

On Wed, Jul 21, 2010 at 4:07 PM, Christopher Painter 
chr...@deploymentengineering.com wrote:

 Same here.  I've heard people post for years about how Major Upgrades are a
 pain
 and you better follow the component rules to a letter if you want minor
 upgrades, small updates and patching to work.   I've choosen to only
 support
 Major Upgrades and it's a bit of a vindication to now see the likes of Rob
 talk
 about why WiX's own installer only does Major Upgrades.

 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Neil Sleightholm n...@x2systems.com
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 5:58:54 PM
 Subject: Re: [WiX-users] Does the msi-filename matter?

 But a key point is that this is only a possible** problem for minor
 upgrades. If
 you do major upgrades you can ignore it.

 **I say possible because I have never seen an issue but I mainly stick to
 major
 upgrade because they are less hassle.

 Neil

 -Original Message-
 From: Blair [mailto:os...@live.com]
 Sent: 21 July 2010 23:12
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Does the msi-filename matter?

 That could help reduce the chance of that problem, but depending on which
 file the user changes (the initial or the update) you may not get a chance
 to warn the user to not rename the MSI.

 In most of the failure cases I have seen due to not finding the MSI file at
 the indicated directory caused by looking for a different name than
 expected
 (usually due to attempting a minor upgrade using an MSI downloaded using
 IE)
 Windows Installer never even starts parsing any sequence table.

 This is part of the reason huge numbers of software producers distributing
 over the internet use self-extract-and-launch-style wrappers (zip-exe
 style)
 for their MSI distribution.

 -Original Message-
 From: Christopher Painter [mailto:chr...@deploymentengineering.com]
 Sent: Wednesday, July 21, 2010 2:51 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Does the msi-filename matter?

 It is true that changing the MSI file name forces a major upgrade.  If you
 are
 concerned that your user will interfere with your servicing strategy by
 renaming
 the MSI, you can use the OriginalDatabase property in a LaunchCondition to
 abort
 the install if they have renamed the MSI.  I would suggest something like


 [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi

 http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

 http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Lukas Haase lukasha...@gmx.at
 To: wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 4:42:20 PM
 Subject: [WiX-users] Does the msi-filename matter?

 Hi,

 Does the filename of the msi file matter in any way?

 I really DO NOT hope so! Because I have no influence if the user renames
 the file before installing?!

 [1] says: There are cases when the Windows Installer forces you to use
 a major upgrade [...] You have to when you change the name of the .msi
 file for any reason. [...]

 Regards,
 Luke




 [1] http://www.tramontana.co.hu/wix/lesson4.php#4.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



 --
 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
 ___

Re: [WiX-users] Wix3 heat - create a wxi from wxs fragment through transform

I left a comment on the blog post. Why did you transform things into an
Include file?

On Tue, Jul 20, 2010 at 2:50 PM, Leif Ringstad lei...@gmail.com wrote:

 Hi

 After struggling for too many hours to get this transform working, I
 thought
 I would share it with the list.

 http://techandaccessibility.blogspot.com/2010/07/using-wix3-and-heat-to-create-wxi.html

 
 http://techandaccessibility.blogspot.com/2010/07/using-wix3-and-heat-to-create-wxi.html
 I
 played around with several different wildcards, but it seems to give
 various
 levels of success. I should add that this is the first time I played around
 with xsl stylesheets, so if there is an expert on the list, I'm sure there
 is a better way. Although this one works for simple files containing
 DirectoryRef, Directory, File and Component

 cheers,
 Leif

 --
 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




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
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] Does the msi-filename matter?

Rob- I seem to recall several blog articles years ago talking about how major 
upgrades are ugly.   One was from an active blogger at the time ( Vagmi ) but 
I don't remember the others. 

http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx

Blair-   My MSI mojo is good, but what development throws over the wall to me 
frequently will not end well with anything other then a major upgrade with 
respect to msi servicing patterns and rules.  I'm sure you've seen that also.

Chris



- Original Message 
From: Rob Mensching r...@robmensching.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Wed, July 21, 2010 9:33:40 PM
Subject: Re: [WiX-users] Does the msi-filename matter?

Uhh, I personally always recommend Major Upgrades over all the other
options. IMHO, the other options (minor updates and small updates) add pain
that is rarely worth it (i.e. you have to be really big with lots of
customers to bother with .msp's).

I'd be curious to see who actually recommends anything but Major Upgrades
for the general case.

On Wed, Jul 21, 2010 at 4:07 PM, Christopher Painter 
chr...@deploymentengineering.com wrote:

 Same here.  I've heard people post for years about how Major Upgrades are a
 pain
 and you better follow the component rules to a letter if you want minor
 upgrades, small updates and patching to work.  I've choosen to only
 support
 Major Upgrades and it's a bit of a vindication to now see the likes of Rob
 talk
 about why WiX's own installer only does Major Upgrades.

 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Neil Sleightholm n...@x2systems.com
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 5:58:54 PM
 Subject: Re: [WiX-users] Does the msi-filename matter?

 But a key point is that this is only a possible** problem for minor
 upgrades. If
 you do major upgrades you can ignore it.

 **I say possible because I have never seen an issue but I mainly stick to
 major
 upgrade because they are less hassle.

 Neil

 -Original Message-
 From: Blair [mailto:os...@live.com]
 Sent: 21 July 2010 23:12
 To: 'General discussion for Windows Installer XML toolset.'
 Subject: Re: [WiX-users] Does the msi-filename matter?

 That could help reduce the chance of that problem, but depending on which
 file the user changes (the initial or the update) you may not get a chance
 to warn the user to not rename the MSI.

 In most of the failure cases I have seen due to not finding the MSI file at
 the indicated directory caused by looking for a different name than
 expected
 (usually due to attempting a minor upgrade using an MSI downloaded using
 IE)
 Windows Installer never even starts parsing any sequence table.

 This is part of the reason huge numbers of software producers distributing
 over the internet use self-extract-and-launch-style wrappers (zip-exe
 style)
 for their MSI distribution.

 -Original Message-
 From: Christopher Painter [mailto:chr...@deploymentengineering.com]
 Sent: Wednesday, July 21, 2010 2:51 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Does the msi-filename matter?

 It is true that changing the MSI file name forces a major upgrade.  If you
 are
 concerned that your user will interfere with your servicing strategy by
 renaming
 the MSI, you can use the OriginalDatabase property in a LaunchCondition to
 abort
 the install if they have renamed the MSI.  I would suggest something like


 [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi

 http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx

 http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

 Christopher Painter, Author of Deployment Engineering Blog
 Have a hot tip, know a secret or read a really good thread that deserves
 attention? E-Mail Me



 - Original Message 
 From: Lukas Haase lukasha...@gmx.at
 To: wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 4:42:20 PM
 Subject: [WiX-users] Does the msi-filename matter?

 Hi,

 Does the filename of the msi file matter in any way?

 I really DO NOT hope so! Because I have no influence if the user renames
 the file before installing?!

 [1] says: There are cases when the Windows Installer forces you to use
 a major upgrade [...] You have to when you change the name of the .msi
 file for any reason. [...]

 Regards,
 Luke




 [1] http://www.tramontana.co.hu/wix/lesson4.php#4.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

Re: [WiX-users] Does the msi-filename matter?

I think you have me confused with someone else. I've always had the stance:
If you can use a Major Upgrade do so. Life is too short to deal with the
difficulties otherwise.

What else have you told people I believe? smile/

On Wed, Jul 21, 2010 at 7:53 PM, Christopher Painter 
chr...@deploymentengineering.com wrote:

 Rob- I seem to recall several blog articles years ago talking about
 how major
 upgrades are ugly.   One was from an active blogger at the time ( Vagmi
 ) but
 I don't remember the others.

 http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx

 Blair-   My MSI mojo is good, but what development throws over the wall to
 me
 frequently will not end well with anything other then a major upgrade with
 respect to msi servicing patterns and rules.  I'm sure you've seen that
 also.

 Chris



 - Original Message 
 From: Rob Mensching r...@robmensching.com
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Sent: Wed, July 21, 2010 9:33:40 PM
 Subject: Re: [WiX-users] Does the msi-filename matter?

 Uhh, I personally always recommend Major Upgrades over all the other
 options. IMHO, the other options (minor updates and small updates) add pain
 that is rarely worth it (i.e. you have to be really big with lots of
 customers to bother with .msp's).

 I'd be curious to see who actually recommends anything but Major Upgrades
 for the general case.

 On Wed, Jul 21, 2010 at 4:07 PM, Christopher Painter 
 chr...@deploymentengineering.com wrote:

  Same here.  I've heard people post for years about how Major Upgrades are
 a
  pain
  and you better follow the component rules to a letter if you want minor
  upgrades, small updates and patching to work.  I've choosen to only
  support
  Major Upgrades and it's a bit of a vindication to now see the likes of
 Rob
  talk
  about why WiX's own installer only does Major Upgrades.
 
  Christopher Painter, Author of Deployment Engineering Blog
  Have a hot tip, know a secret or read a really good thread that deserves
  attention? E-Mail Me
 
 
 
  - Original Message 
  From: Neil Sleightholm n...@x2systems.com
  To: General discussion for Windows Installer XML toolset.
  wix-users@lists.sourceforge.net
  Sent: Wed, July 21, 2010 5:58:54 PM
  Subject: Re: [WiX-users] Does the msi-filename matter?
 
  But a key point is that this is only a possible** problem for minor
  upgrades. If
  you do major upgrades you can ignore it.
 
  **I say possible because I have never seen an issue but I mainly stick to
  major
  upgrade because they are less hassle.
 
  Neil
 
  -Original Message-
  From: Blair [mailto:os...@live.com]
  Sent: 21 July 2010 23:12
  To: 'General discussion for Windows Installer XML toolset.'
  Subject: Re: [WiX-users] Does the msi-filename matter?
 
  That could help reduce the chance of that problem, but depending on which
  file the user changes (the initial or the update) you may not get a
 chance
  to warn the user to not rename the MSI.
 
  In most of the failure cases I have seen due to not finding the MSI file
 at
  the indicated directory caused by looking for a different name than
  expected
  (usually due to attempting a minor upgrade using an MSI downloaded using
  IE)
  Windows Installer never even starts parsing any sequence table.
 
  This is part of the reason huge numbers of software producers
 distributing
  over the internet use self-extract-and-launch-style wrappers (zip-exe
  style)
  for their MSI distribution.
 
  -Original Message-
  From: Christopher Painter [mailto:chr...@deploymentengineering.com]
  Sent: Wednesday, July 21, 2010 2:51 PM
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] Does the msi-filename matter?
 
  It is true that changing the MSI file name forces a major upgrade.  If
 you
  are
  concerned that your user will interfere with your servicing strategy by
  renaming
  the MSI, you can use the OriginalDatabase property in a LaunchCondition
 to
  abort
  the install if they have renamed the MSI.  I would suggest something like
 
 
  [OriginalDatabase]  \MYSUPPORTEDFILENAME.msi
 
  http://msdn.microsoft.com/en-us/library/aa370562(VS.85).aspx
 
  http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx
 
  Christopher Painter, Author of Deployment Engineering Blog
  Have a hot tip, know a secret or read a really good thread that deserves
  attention? E-Mail Me
 
 
 
  - Original Message 
  From: Lukas Haase lukasha...@gmx.at
  To: wix-users@lists.sourceforge.net
  Sent: Wed, July 21, 2010 4:42:20 PM
  Subject: [WiX-users] Does the msi-filename matter?
 
  Hi,
 
  Does the filename of the msi file matter in any way?
 
  I really DO NOT hope so! Because I have no influence if the user renames
  the file before installing?!
 
  [1] says: There are cases when the Windows Installer forces you to use
  a major upgrade [...] You have to when you change the name of the .msi
  file for

Re: [WiX-users] Does the msi-filename matter?