Re: [WiX-users] registering an MMC snap-in
Alright, so if I understand things right, I need to capture the registry entries created by installutil and write them into the Wix file so that the Windows Installer writes them directly. How about running mmcperf which is necessary to get the MMC 3.0 API into the global assembly cache on XP and 2003? I make that a custom action that happens after installing the assembly (MMC 3.0)? Looking at documentation, I saw ways to see if .Net 2.0 was installed. Are there ways to see if MMC 3.0 is installed on the operating systems that don't come with it? Brant Gurganus http://gurganus.name/brant On Sun, Jun 28, 2009 at 10:43 PM, Christopher Karperchristopher.kar...@gmail.com wrote: You'll need to follow the manual registration process, and build the registry entries yourself. There is no extension to handle this as-is. A search on MSDN should get you the results you need, depending on the platform you used to develop the snap in. Heat may be able to harvest the registry info for you as well, but I don't know. Chris On Sun, Jun 28, 2009 at 8:22 PM, Brant Gurganus br...@gurganus.name wrote: My understanding from documentation on MSDN is that installutil shouldn't be used to register the MMC 3.0 snap-in in actual deployment. What then is the correct way to register an MMC snap-in with a Windows Installer built with Wix? I'm currently using Wix 3.5 since that's what had the VS2010 integration. I'm pretty new to Wix in the first place. Brant Gurganus http://gurganus.name/brant -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixUI localizations..
Thanks, I've fired a message through requesting the disclaimer/waiver/whatever it is to sign. I'll provide the missing translations once it comes through :) 2009/6/26 DEÁK JAHN, Gábor d...@tramontana.co.hu: On Wed, 24 Jun 2009 18:15:22 +1000, Sascha Beaumont wrote: Sascha, localization is still an open and ongoing process, anybody can join and provide the missing translations. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: d...@tramontana.co.hu -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
Just checked our Windows 7 test server and it has the text size set to 'Smaller - 100% (default)'. Rob Anthony Bouch wrote: No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
Be aware that this is not just a Windows 7 problem. I run my Windows XP machine with large fonts set in the control panel's Display Properties and also see the bitmap stretching. I believe it arises because the dialog size is based on the font size. When not using an external UI, we just either try to use art that scales well or use a solid colour. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: 29 June 2009 10:13 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Just checked our Windows 7 test server and it has the text size set to 'Smaller - 100% (default)'. Rob Anthony Bouch wrote: No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
Thanks Rob. Also understood Peter. I just tested a Vista box - setting the DPI to 120 and running the installer - and sure enough the installer dialog increased in size (stretching the artwork as well). Just surprised I didn't notice this earlier since I was using a high DPI setting on my notebook previously. A shame that the dialog windows don't scale the artwork down well - since producing oversized artwork was the easy solution. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, June 29, 2009 4:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Be aware that this is not just a Windows 7 problem. I run my Windows XP machine with large fonts set in the control panel's Display Properties and also see the bitmap stretching. I believe it arises because the dialog size is based on the font size. When not using an external UI, we just either try to use art that scales well or use a solid colour. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: 29 June 2009 10:13 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Just checked our Windows 7 test server and it has the text size set to 'Smaller - 100% (default)'. Rob Anthony Bouch wrote: No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --
[WiX-users] What is a difference TYPICAL Installation and Complete Installation.
hi, I have been using WiX 3.0 for migrating my installlers in Installshield to WiX. One thing i am not able to understand is the Difference between *typical*and *complete* installation. Can any one please throw some light on this. Regards, Akash -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering an MMC snap-in
Here's the code I used:
Property Id=MMC3
DirectorySearch Id=MMC3Path Path=[SystemFolder] Depth=3
FileSearch Id=MMC3Installed Name=mmc.exe
MinVersion=5.2.3790.3959 /
/DirectorySearch
/Property
If MMC3 has a value, then it's installed.My snap in is optional, so I
just make it available or not, depending on MMC3 install state. If you
require it for your product, then you may be better served by having a
bootstrapper, or at least an install condition:
Condition Message='MMC 3.0 is required for this product.'
MMC3
/Condition
And FWIW, here's my edited list of registry operations for installing a .NET
MMC3 snap-in:
Component Id=ms_Native_RegistryOperations
Guid={INSTALLER_COMPONENT_GUID_X64} Win64=yes
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}\NodeTypes
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}\Standalone
Action=createAndRemoveOnUninstall /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Type
Value=Namespace.SnapIn, SnapIn, Version=0.0.0.1, Culture=neutral,
PublicKeyToken=gobbledeegook Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=ApplicationBase Value=[SNAPINFOLDER] Type=string Action=write
/
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=ConfigurationFile Value=[#ms_SnapIn.dll.config] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=NameString
Value=Snap In Name Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Description
Value=MMC 3.0 snap-in to end all snap-ins. Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Provider
Value=Big Momma's House, Inc. (c) Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=AssemblyName
Value=SnapIn Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=ModuleName
Value=SnapIn.dll Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=RuntimeVersion
Value=v2.0.50727 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=FxVersion
Value=3.0.0.0 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=About
Value={----} Type=string Action=write
/
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=NameStringIndirect Value=@[SNAPINFOLDER]SnapIn.Resources,-1
Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=DescriptionStringIndirect Value=@[SNAPINFOLDER]SnapIn.Resources,-2
Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=IconIndirect
Value=@[SNAPINFOLDER]SnapIn.Resources,-1 Type=string Action=write /
/Component
Component Id=ms_Wow64_RegistryOperations
Guid={INSTALLER_COMPONENT_GUID_X86} Win64=no
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}\NodeTypes
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}\Standalone
Action=createAndRemoveOnUninstall /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Type
Value=Namespace.SnapIn, SnapIn, Version=0.0.0.1, Culture=neutral,
PublicKeyToken=gobbledeegook Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=ApplicationBase Value=[SNAPINFOLDER] Type=string Action=write
/
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}
Name=ConfigurationFile Value=[#ms_SnapIn.dll.config] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=NameString
Value=Snap In Name Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Description
Value=MMC 3.0 snap-in to end all snap-ins. Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=Provider
Value=Big Momma's House, Inc. (c) Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID} Name=AssemblyName
Value=SnapIn Type=string Action=write /
RegistryValue Root=HKLM
Re: [WiX-users] Installing VB6 COM+ components
Hi Neil, Thanks for the suggestion. I did take out the Registryvalue lines and help the complus: / stuff, then tried it again. I'm still getting failed to find component errors. I don't understand how to get around this. Jim -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Saturday, June 27, 2009 12:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing VB6 COM+ components ErrorCode='-2146368476' (0x80110424) means the file does not exist. You mentioned using registry keys to register it, that isn't required for COM+. Can you post your WiX code that is failing? I would expect to see something like this: Component Id=xtimers_dll DiskId=1 Guid=E0E0C0B6-32DA-4522-845B-5D15BE4808AD File Id=xtimers_dll Name=xtimers.dll Source=xtimers.dll KeyPath=yes Vital=yes / complus:ComPlusApplication Id=xtimers Name=My COM+ Application complus:ComPlusAssembly Id=MyComPlusAssembly Type=native DllPath=[#xtimers_dll] complus:ComPlusComponent Id=xtimers CLSID=YOUR CLASS ID / /complus:ComPlusAssembly complus:ComPlusApplicationRole Id=Role Name=My Role / /complus:ComPlusApplication /Component Neil -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: 26 June 2009 19:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Installing VB6 COM+ components All, I really apologize for being a pain on this topic. I've been looking everywhere that I can think of to get some clue and answers to get these components installed but I'm not having any luck at all. I can get them registered using the registry elements and have trimmed out the various parts using the heat options -suid -svb6 -scom and -sreg . I've been looking at the install log line by line however it's not showing anything that I can see as a problem other than the following errors: Action 16:16:51: CreateComPlusPartitions. Creating COM+ partitions Action 16:16:51: AddUsersToComPlusPartitionRoles. Adding users to COM+ partition roles Action 16:16:51: AddComPlusPartitionUsers. Setting default COM+ partitions for users Action 16:16:51: CreateComPlusApplications. Creating COM+ applications CreateComPlusApplications: Application: NFTS Dictionary Constants CreateComPlusApplications: Application: NFTS V3.0 XTimers Action 16:16:52: CreateComPlusApplicationRoles. Creating COM+ application roles Action 16:16:52: AddUsersToComPlusApplicationRoles. Adding users to COM+ application roles Action 16:16:52: RegisterComPlusAssemblies. Registering COM+ components RegisterComPlusAssemblies: DLL: D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll ComPlusInstallExecute: ErrorInfo: Name='D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll', ErrorCode='-2146368476', MajorRef='D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll', MinorRef='invalid' ComPlusInstallExecute: Error 0x80110401: Failed to install components ComPlusInstallExecute: Error 0x80110401: Failed to register native assembly ComPlusInstallExecute: Error 0x80110401: Failed to register assembly, key: XTimerComPlusAssembly ComPlusInstallExecute: Error 0x80110401: Failed to register assemblies Action ended 16:16:53: InstallFinalize. Return value 3. When I check the file properties on the XTimers.dll it indicates that it is a Microsoft file v1.00.0078 and provides code-only xtimer objects. I think one of the questions I asked before in another post was do VB6 COM+ components have an assembly? I've only seen assemblies mentioned in .NET. I've spent the last 4-5 months on this project and now I'm at a road block and I don't know which way to go. Thank you in advance, Jim -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
It is interesting that the latest Windows Installer release doesn't handle this better. Especially considering that High DPI support for apps is highly recommended on Windows XP, Vista, and 7, based on the latest Windows Application Quality Cookbook from Microsoft (http://code.msdn.microsoft.com/Windows7AppQuality, see page 38), but then they don't appear to give us a good option for following that advice in our installers. I wonder if anyone has access to push this issue with the MSI team at Microsoft? --Quinton -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:54 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Thanks Rob. Also understood Peter. I just tested a Vista box - setting the DPI to 120 and running the installer - and sure enough the installer dialog increased in size (stretching the artwork as well). Just surprised I didn't notice this earlier since I was using a high DPI setting on my notebook previously. A shame that the dialog windows don't scale the artwork down well - since producing oversized artwork was the easy solution. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, June 29, 2009 4:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Be aware that this is not just a Windows 7 problem. I run my Windows XP machine with large fonts set in the control panel's Display Properties and also see the bitmap stretching. I believe it arises because the dialog size is based on the font size. When not using an external UI, we just either try to use art that scales well or use a solid colour. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: 29 June 2009 10:13 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Just checked our Windows 7 test server and it has the text size set to 'Smaller - 100% (default)'. Rob Anthony Bouch wrote: No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- -- --
[WiX-users] Paraffin 3.1: Updated WiX Fragment Generate/Update Tool
Hello Fellow WiX Users, I posted an update to my Paraffin tool which generates and update WiX fragments for your installers. Thanks to everyone who has used it and especially to everyone who sent feedback. See what's new and fixed here: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/28/paraffin3-1-new-and-improved.aspx You might be wondering how Paraffin and Heat compare. Here's what I said in the above link: Many people have asked about the status of Paraffin now that WiX 3.0 has a much-improved Heat program that handles updating fragments. First off, I am thrilled that Brian Rogers is making Heat much more capable and useful. The WiX team as a whole has done an amazing job of making installers easier to write for mere mortals. Anything that can wrap the interesting API known as Windows Installer is always a good thing. With Heat now doing many of the things Paraffin does, and way more, if you're in the planning stages of your install you need to seriously look at the whole WiX approach to auto generating fragments. The WiX developers are much smarter than I am and are thinking hard about how to solve these difficult problems. Paraffin meets my needs, and may meet yours, but definitely look at the Heat approach. Hope you find Paraffin useful! John Wintellect http://www.wintellect.com 877-968-5528 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] IIS Application Pool, how to not create if exist?
Hi I have the following code to create a IIS application pool. How can I put in logic says that don't create if it's already exists? DirectoryRef Id=TARGETDIR Component Id='SFSAEAppPoolComp' Guid='B7D1E298-5A98-11DE-937D-1DD455D89593' iis:WebAppPool Id='SFSAEAppPool' Name='Assessment Engine AppPool' /iis:WebAppPool /Component Thanks Jirong Hu Build Master 780-644-5488 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing VB6 COM+ components
Neil, or anyone, I think I have it working for a few of my DLLs, however I have one more question. What if the DLL has more than one CLSID? Do I need to list both of them or just the first one? Thanks, Jim -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Saturday, June 27, 2009 12:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing VB6 COM+ components ErrorCode='-2146368476' (0x80110424) means the file does not exist. You mentioned using registry keys to register it, that isn't required for COM+. Can you post your WiX code that is failing? I would expect to see something like this: Component Id=xtimers_dll DiskId=1 Guid=E0E0C0B6-32DA-4522-845B-5D15BE4808AD File Id=xtimers_dll Name=xtimers.dll Source=xtimers.dll KeyPath=yes Vital=yes / complus:ComPlusApplication Id=xtimers Name=My COM+ Application complus:ComPlusAssembly Id=MyComPlusAssembly Type=native DllPath=[#xtimers_dll] complus:ComPlusComponent Id=xtimers CLSID=YOUR CLASS ID / /complus:ComPlusAssembly complus:ComPlusApplicationRole Id=Role Name=My Role / /complus:ComPlusApplication /Component Neil -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: 26 June 2009 19:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Installing VB6 COM+ components All, I really apologize for being a pain on this topic. I've been looking everywhere that I can think of to get some clue and answers to get these components installed but I'm not having any luck at all. I can get them registered using the registry elements and have trimmed out the various parts using the heat options -suid -svb6 -scom and -sreg . I've been looking at the install log line by line however it's not showing anything that I can see as a problem other than the following errors: Action 16:16:51: CreateComPlusPartitions. Creating COM+ partitions Action 16:16:51: AddUsersToComPlusPartitionRoles. Adding users to COM+ partition roles Action 16:16:51: AddComPlusPartitionUsers. Setting default COM+ partitions for users Action 16:16:51: CreateComPlusApplications. Creating COM+ applications CreateComPlusApplications: Application: NFTS Dictionary Constants CreateComPlusApplications: Application: NFTS V3.0 XTimers Action 16:16:52: CreateComPlusApplicationRoles. Creating COM+ application roles Action 16:16:52: AddUsersToComPlusApplicationRoles. Adding users to COM+ application roles Action 16:16:52: RegisterComPlusAssemblies. Registering COM+ components RegisterComPlusAssemblies: DLL: D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll ComPlusInstallExecute: ErrorInfo: Name='D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll', ErrorCode='-2146368476', MajorRef='D:\Projects\NFTS\Src\apps\nfts\binaries\XTimers.dll', MinorRef='invalid' ComPlusInstallExecute: Error 0x80110401: Failed to install components ComPlusInstallExecute: Error 0x80110401: Failed to register native assembly ComPlusInstallExecute: Error 0x80110401: Failed to register assembly, key: XTimerComPlusAssembly ComPlusInstallExecute: Error 0x80110401: Failed to register assemblies Action ended 16:16:53: InstallFinalize. Return value 3. When I check the file properties on the XTimers.dll it indicates that it is a Microsoft file v1.00.0078 and provides code-only xtimer objects. I think one of the questions I asked before in another post was do VB6 COM+ components have an assembly? I've only seen assemblies mentioned in .NET. I've spent the last 4-5 months on this project and now I'm at a road block and I don't know which way to go. Thank you in advance, Jim -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detecting if WiX 3.0 is installed
Thanks, as always, Bob! I put in the feature request (https://sourceforge.net/tracker/?func=detailaid=2814132group_id=105970atid=642717). Using the registry key SOFTWARE\Microsoft\Windows Installer XML\version is sufficient. I guess anyone using a Product Id=* really needs to plan a detection scheme. Recently someone on the list was asking if there were any best practices and this might be one. In fact, it might be a good thing to add to WiXCOP. :) -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, June 25, 2009 8:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Detecting if WiX 3.0 is installed John Robbins wrote: WiX 3.0 uses a Product Id=* to autogenerate a product ID. Say you wanted to build a tool that required WiX 3.0. How would your installer correctly determine that any build of WiX 3.0 was installed? There are two aspects: 1. The source says you can use a registry path or the upgrade code, which have been stable for months and are unlikely to change. 2. Unless you have an SLA that says they're supported for detection, you don't have a contract and it could change, either accidentally because we didn't know or intentionally when we're feeling malicious and evil. I'd suggest opening a feature request so at least we know someone wants a particular detection mechanism. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem using WixCA
Hi, I am using the following code to launch my exe. Now, I set Return=Check, so install shouldn't succeed in case of failure. Well, the install did succeed, but my exe is not doing what it is supposed to do. The only problem i can think of is setting CURRENT FOLDER path, as if I run my exe after the install it works fine. So, how can I set current working folder before calling this custom action. or anyother thing, I am missing here. CustomAction Id=QtExecDeferredExampleWithProperty_Cmd Property=QtExecDeferredExampleWithProperty Value=quot; [INSTALLDIR]\dir1\dir2\test.exequot; -param1 param2 Execute=immediate/ CustomAction Id=QtExecDeferredExampleWithProperty BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/ InstallExecuteSequence Custom Action=QtExecDeferredExampleWithProperty_Cmd After=CostFinalizeNot Installed/Custom Custom Action=QtExecDeferredExampleWithProperty Before=InstallFinalizeNot Installed/Custom /InstallExecuteSequence Thanks, Gulfam -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is a difference TYPICAL Installation and Complete Installation.
I don't think it has to be complicated. Typical is the feature set that most users will use all of the time. Complete is everything, all the features. Without details it's hard to say, but Typical might exclude tutorials, samples, templates, migration tools etc that aren't need to run the app. If you were using InstallShield with Typical but installing everything then I guess you didn't need Typical in the first place? Phil Wilson -Original Message- From: akash bhatia [mailto:911ak...@gmail.com] Sent: Monday, June 29, 2009 3:14 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] What is a difference TYPICAL Installation and Complete Installation. hi, I have been using WiX 3.0 for migrating my installlers in Installshield to WiX. One thing i am not able to understand is the Difference between *typical*and *complete* installation. Can any one please throw some light on this. Regards, Akash -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] VB6 ComPlus Components - Installed
I want to all who gave input to helping me with this most painful thorn in my side. LOL I finally managed to get my components installed. Now to dowse my head in some much needed Rogaine. :) Jim -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing VB6 COM+ components
I see you got it working, out of interest what was the answer to this? Neil -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: 29 June 2009 18:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing VB6 COM+ components Neil, or anyone, I think I have it working for a few of my DLLs, however I have one more question. What if the DLL has more than one CLSID? Do I need to list both of them or just the first one? Thanks, Jim -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing VB6 COM+ components
It was a couple things actually. 1.) I discovered that I wasn't using the CLSIDs of the DLL for the component in the assembly, and 2) I changed the path to the dll from an actual path to [#component-id] to match the actual component/file id. Now I'm working on how to fill in all the values that would show up when you look at the compononent's property sheet in Component Services. I think I have it figured out though. :) Jim -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Monday, June 29, 2009 4:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing VB6 COM+ components I see you got it working, out of interest what was the answer to this? Neil -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: 29 June 2009 18:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing VB6 COM+ components Neil, or anyone, I think I have it working for a few of my DLLs, however I have one more question. What if the DLL has more than one CLSID? Do I need to list both of them or just the first one? Thanks, Jim -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] dotNetInstaller, a setup bootstrapper, 1.6 Released
Forgive me for shameless advertising. dotNetInstaller 1.6 has been released. dotNetInstaller is an open-source, imperfect, but very feature-rich setup bootstrapper. It might just be what you're looking for before Burn and might give some good ideas for a more perfect bootstrapper developed by the Wix folks as well. This version is our first release from CodePlex, has brand new documentation, a much better editor, Windows Server 2008 support, lots of bug fixes and much more. http://dotnetinstaller.codeplex.com/ cheers dB. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is a difference TYPICAL Installation and Complete Installation.
Akash, Typical and Complete are names of feature sets. A feature set installs a particular group of components. Each feature set can install a different set of components (though a component can be used in more than one feature set if needed). An install always requires at least one feature set. In my case, I install everything anyway so I only use one feature set and the user doesnt have any options. However, I could equally set up the installer to have a typical feature set that installs just the application and a complete feature set that installs both the application AND the documentation and the user will then get to choose what it is they want to install. Whether you need more than one feature set will entirely depend on what it is you are installing and if you need to give the user options on what is or isn't installed. Chris -Original Message- From: akash bhatia [mailto:911ak...@gmail.com] Sent: Monday, June 29, 2009 3:14 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] What is a difference TYPICAL Installation and Complete Installation. hi, I have been using WiX 3.0 for migrating my installlers in Installshield to WiX. One thing i am not able to understand is the Difference between *typical*and *complete* installation. Can any one please throw some light on this. Regards, Akash -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Delete registry value
Is there a way to delete registry value? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ExtractFiles() Method Doesn't Work on Merge Modules
It appears the ExtractFiles() methods don't work on merge modules. The
methods work fine on an MSI but not merge modules. It appears just by
browsing through the source of the
Microsoft.Deployment.WindowsInstaller.Package assembly that we are trying to
count the number of rows in the Media table which doesn't exist in merge
modules. I tried the latest build of WiX 3.0 and the issue still appears
there. Maybe I'm doing something wrong. All I'm doing is
using (InstallPackage pkg = new InstallPackage(msmFile,
DatabaseOpenMode.Transact))
{
pkg.ExtractFiles();
}
With that code, you get a NullReferenceException object.
Thoughts?
--
View this message in context:
http://n2.nabble.com/ExtractFiles%28%29-Method-Doesn%27t-Work-on-Merge-Modules-tp3177440p3177440.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat Website Harvester Status?
I have read several postings from Rob that the heat website harvester could possibly be broken? What is the status on that specific portion of heat? I have been receiving many of the same errors that are on the mailing list. heat.exe : error HEAT5158 : The web site 'IIS://localhost/LM/W3SVC/1/ROOT/virDirectoryName' could not be found. Please check that the web site exists, and that it is spelled correct. heat.exe : error HEAT5158 : The web site 'IIS://localhost/W3SVC/1/ROOT/virDirectoryName' could not be found. Please check that the web site exists, and that it is spelled correct. heat.exe : error HEAT0001 : Value cannot be null. Parameter name: argument Exception Type: System.ArgumentNullException OS: Windows Server 2008 IIS Ver: 7.0 I have installed the IIS 6.0 Resource Kit and verified that the Metabase location is correct. Anyone have a working example to give w/ IIS7? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat Website Harvester Status?
Hey Aaron, Could you share your command line string? This error is of interest to me. heat.exe : error HEAT0001 : Value cannot be null. Parameter name: argument Exception Type: System.ArgumentNullException Thanks, Brian Rogers Intelligence removes complexity. - Me http://blogs.msdn.com/icumove -- NEW On Mon, Jun 29, 2009 at 2:45 PM, Aaron Webster aaron.webs...@af-group.comwrote: I have read several postings from Rob that the heat website harvester could possibly be broken? What is the status on that specific portion of heat? I have been receiving many of the same errors that are on the mailing list. heat.exe : error HEAT5158 : The web site 'IIS://localhost/LM/W3SVC/1/ROOT/virDirectoryName' could not be found. Please check that the web site exists, and that it is spelled correct. heat.exe : error HEAT5158 : The web site 'IIS://localhost/W3SVC/1/ROOT/virDirectoryName' could not be found. Please check that the web site exists, and that it is spelled correct. heat.exe : error HEAT0001 : Value cannot be null. Parameter name: argument Exception Type: System.ArgumentNullException OS: Windows Server 2008 IIS Ver: 7.0 I have installed the IIS 6.0 Resource Kit and verified that the Metabase location is correct. Anyone have a working example to give w/ IIS7? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExtractFiles() Method Doesn't Work on Merge Modules
It's a bug (oversight) in the implementation of ExtractFiles(). Can you create
a bug report on SourceForge?
-Original Message-
From: jnewton [mailto:jonathan.new...@ni.com]
Sent: Monday, June 29, 2009 2:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ExtractFiles() Method Doesn't Work on Merge Modules
It appears the ExtractFiles() methods don't work on merge modules. The
methods work fine on an MSI but not merge modules. It appears just by
browsing through the source of the
Microsoft.Deployment.WindowsInstaller.Package assembly that we are trying to
count the number of rows in the Media table which doesn't exist in merge
modules. I tried the latest build of WiX 3.0 and the issue still appears
there. Maybe I'm doing something wrong. All I'm doing is
using (InstallPackage pkg = new InstallPackage(msmFile,
DatabaseOpenMode.Transact))
{
pkg.ExtractFiles();
}
With that code, you get a NullReferenceException object.
Thoughts?
--
View this message in context:
http://n2.nabble.com/ExtractFiles%28%29-Method-Doesn%27t-Work-on-Merge-Modules-tp3177440p3177440.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExtractFiles() Method Doesn't Work on Merge Modules
I posted a thread last week that no one has replied to. I was using
ExtractFiles on an MSI and it doesn't raise an error or extract any files.
http://n2.nabble.com/DTF-ExtractFiles-Problem-td3148972.html
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
--- On Mon, 6/29/09, Jason Ginchereau jason...@microsoft.com wrote:
From: Jason Ginchereau jason...@microsoft.com
Subject: Re: [WiX-users] ExtractFiles() Method Doesn't Work on Merge Modules
To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net
Date: Monday, June 29, 2009, 6:02 PM
It's a bug (oversight) in the
implementation of ExtractFiles(). Can you create a bug
report on SourceForge?
-Original Message-
From: jnewton [mailto:jonathan.new...@ni.com]
Sent: Monday, June 29, 2009 2:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ExtractFiles() Method Doesn't Work on
Merge Modules
It appears the ExtractFiles() methods don't work on merge
modules. The
methods work fine on an MSI but not merge modules. It
appears just by
browsing through the source of the
Microsoft.Deployment.WindowsInstaller.Package assembly that
we are trying to
count the number of rows in the Media table which doesn't
exist in merge
modules. I tried the latest build of WiX 3.0 and the
issue still appears
there. Maybe I'm doing something wrong. All I'm doing is
using (InstallPackage pkg = new InstallPackage(msmFile,
DatabaseOpenMode.Transact))
{
pkg.ExtractFiles();
}
With that code, you get a NullReferenceException object.
Thoughts?
--
View this message in context:
http://n2.nabble.com/ExtractFiles%28%29-Method-Doesn%27t-Work-on-Merge-Modules-tp3177440p3177440.html
Sent from the wix-users mailing list archive at
Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to change data in VolumeCostList control
kezhong zhou wrote: ReserveCost table in a custom action. But I tried a lot of times, found that I can only 'SELECT' the ReserveCost table at install time, but can not INSERT or UPDATE the table. :( You can't permanently update tables in custom actions. You can make temporary changes. However, why do you need to do it at runtime? -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Enforcing x86-only and x64-only installs
Quinton Tormanen wrote: doesn't invoke the PCA when done. However, if I choose to run it directly from the web (using Run instead of Save), then it mysteriously runs in the Windows Vista context and DOES invoke the PCA. Probably depends on how each browser handles the download. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detecting if WiX 3.0 is installed
John Robbins wrote: Using the registry key SOFTWARE\Microsoft\Windows Installer XML\version is sufficient. Agreed. The right values are probably there, as we did some work to enable the WiX that was to ship in VS2010 to be swapped out for the public version. I guess anyone using a Product Id=* really needs to plan a detection scheme. I'd suggest avoiding the use of product codes -- it ties you to a single build if you rely on major upgrades, as some bright folks have recommended http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/.g If you use minor upgrades/patches, it still means changing whenever they do a major upgrade or a SxS release. You can use upgrade codes to detect any products in that family. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0: How to run a program
little.forest wrote: So that means, if I need to run an executable as asyncNoWait, then I'll have to use a different kind of customaction? If so, do you know what that type of customaction is? See the MSI SDK topic Custom Action Return Processing Options. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trying to use Installed property in control condition
David Bartmess wrote: So what can I use to check if the product has already been installed? I thought Installed was the proper way It is -- I'm saying WixUI uses it and it works. Try @Hidden=yes. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
