[WiX-users] Retiring from the WiX community
I've just posted my last 3 blog posts: Addition of two new tools to WiX for transform (Torch)and patch creation (Pyro): http://installing.blogspot.com/2006/09/torch-and-pyro.html Ability to auto-generate safe component guids (limited to single-file components): http://installing.blogspot.com/2006/09/automatically-generating-component.html Retiring from the WiX community:http://installing.blogspot.com/2006/09/retiring-from-wix-community.html Thanks for all the great times and good memories! D e r e k- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Processing reg files using heat.exe
.reg files are not currently supported. However, heats internal code has support for grabbing values directly from the registry, so it would probably be easiest to just add command line support for grabbing keys directly. What kind of keys would you grab? User settings? HKCU? HKLM? Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vitaliy Ilyin Sent: Monday, September 04, 2006 1:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Processing reg files using heat.exe Hi everyone, Is it possible to convert registry files to wix fragments using the heat.exe like it was with the tallow? If not, will this feature be implemented later? Thanks, Vitaliy. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Processing reg files using heat.exe
That sounds very reasonable to me please open a feature request and ask for the following syntax to be supported for heat: Heat.exe reg HKEY_LOCAL_MACHINE\SOFTWARE\Company Name Thanks, Derek From: Vitaliy Ilyin [mailto:[EMAIL PROTECTED] Sent: Monday, September 04, 2006 3:27 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Processing reg files using heat.exe Hi Derek, Thanks for you quick answer. I`d like to grab HKEY_LOCAL_MACHINE\SOFTWARE\Company Name registry key and all it`s subkeys.. Regards, Vitaliy. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, September 04, 2006 1:44 PM To: Vitaliy Ilyin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Processing reg files using heat.exe .reg files are not currently supported. However, heats internal code has support for grabbing values directly from the registry, so it would probably be easiest to just add command line support for grabbing keys directly. What kind of keys would you grab? User settings? HKCU? HKLM? Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vitaliy Ilyin Sent: Monday, September 04, 2006 1:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Processing reg files using heat.exe Hi everyone, Is it possible to convert registry files to wix fragments using the heat.exe like it was with the tallow? If not, will this feature be implemented later? Thanks, Vitaliy. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ui for wix3
Title: Ui for wix3 No. Just link with: -cultures:en-us -ext WixUIExtension To get the equivalent functionality. In WiX 3.0, the localization strings, wixlib, and bitmaps are all self-contained in WixUIExtension.dll. Hopefully once we teach everyone about the new model its easier to use. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Krawczyk Sent: Thursday, August 31, 2006 12:03 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Ui for wix3 Hello Does wix3 have a basic ui lib file, like wixui.lib was for wix2?? Thanks for help - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using XmlFile to update an existing attribute
You need to be careful with braces because it's a formatted value so they need to be escaped like this: [\[] for left brace and [\]] for right brace (I think that's the syntax). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chesong Lee Sent: Thursday, August 31, 2006 2:22 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using XmlFile to update an existing attribute Isn't it possible to use the xpath like this? [] in XPath is not a numerical index but node test predicate. /Configuration/companyname/vals/[EMAIL PROTECTED]'something2']/@value -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Thursday, August 31, 2006 4:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using XmlFile to update an existing attribute I'm trying to set the value of an attribute to the machine name. this is a snippet of the xml file. Configuration . . . companyname vals add name=something value=value1 / add name=something2 value=valueIwanttoupdate / /vals /companyname /Configuration When I use the //Configuration/Companyname[1]/vals[1]/add[2] for the ElementPath it updates value1 no matter what add I reference. Any ideas why this happens? How can I update the value attribute of the 2nd add element in the group. I don't want to create a new element, because all the elements already exist along with all of their attributes. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension.
Hehe, alright, I just fixed it. This should be in the next WiX 3.0 release. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ali-Akber Saifee Sent: Wednesday, August 30, 2006 2:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension. Some of my installation components use DirectShow filters... (*.ax files).. when i try to harvest them with heat the class information + registry information is not extracted. I suspect this is due to a wildcard filter which is not classifying .ax files as possible candidates for COM objects... i tried simply renaming the file to a .dll and it is harvested properly then.. .ocx files are also ok. rgrds./Ali - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Light error 0216
Very hard to say whats causing that without more information. Especially for the Win 32 exceptions, the output is vital to figuring it out. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrel Miller Sent: Wednesday, August 30, 2006 5:34 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Light error 0216 This error is reproducable in the latest 3.0.2015 release. However, you need to be running using a non-administrator account to see it. I discovered it while trying to integrate wix with the TFS build. The TFS build runs under a domain account called TFSService that is not a local administrator. If I run light from a local administrator account everything runs fine. Darrel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension.
.tlb files arent supported yet. I thought those were usually compiled into a .dll or other file when shipped to the customer. Do you ship the .tlb as part of your setup? Does the .tlb register a separate .dll file in the actual registry keys? Derek From: Brad Davis [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 6:59 AM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension. As of last week's release, .tlb files didn't work eitheralthough I didn't verify that it was already registered prior to harvesting, as I believe that's a pre-req? On 8/30/06, Derek Cicerone [EMAIL PROTECTED] wrote: Hehe, alright, I just fixed it. This should be in the next WiX 3.0 release. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ali-Akber Saifee Sent: Wednesday, August 30, 2006 2:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension. Some of my installation components use DirectShow filters... (*.ax files).. when i try to harvest them with heat the class information + registry information is not extracted. I suspect this is due to a wildcard filter which is not classifying .ax files as possible candidates for COM objects... i tried simply renaming the file to a .dll and it is harvested properly then.. .ocx files are also ok. rgrds./Ali - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Brad - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] using heat to harvest COM objects that do not have the '.dll' extension.
I see. Thank you for explaining that Ill add .tlb to the
list of known self-reggable file extensions. Hopefully this should be in the
next build. Please let me know if it works for you (without having to use VSI
preferably J).
Thanks,
Derek
From: Brad Davis
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 11:41 AM
To: [EMAIL PROTECTED]
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] using heat to harvest COM objects that do not
have the '.dll' extension.
Yesin this case, it's used
as the unmanaged managed code interface for a .NET COM-callable wrapper
assembly. I'm not an expert, but the process we used to get around the issue
today yeilded registration nodes for the .tlb and the associated
assemblygoing around Charlie's barn:
1. Add a setup / deployment project to the .NET project.
2. Build it, yeilding an .MSI
3. Run dark against it, and pull out the necessary fragment for the .tlb and
associated .dll:
Component Id=C__54BB173E646F6AE275AE40C424030C9B
Guid={65041B27-3664-B4B5-42AF-4C03915AA068}
File Id=_54BB173E646F6AE275AE40C424030C9B
Name=Atlas.Validation.DispatchWrapper.tlb KeyPath=yes
ShortName=ATLASV~1.TLB Vital=yes DiskId=1
Source=SourceDir\File\_54BB173E646F6AE275AE40C424030C9B
TypeLib
Id={75E29D5A-DF04-479A-ACCB-473EEF7A5B23} Advertise=yes
Cost=0 Description=Atlas_Validation_DispatchWrapper
Language=0 MajorVersion=1 MinorVersion=0
/
/File
RegistryValue
Id=_5899F3F60FC04B9BBBF1D7F134EC113F Root=HKCR
Key=Interface\{D55F1491-5EA3-4A9F-B746-F5C4E4DE071C}
Value=_DispatchWrapper Type=string /
RegistryValue
Id=_9EAEC7F543244B2D850B647DC513535E Root=HKCR
Key=Interface\{D55F1491-5EA3-4A9F-B746-F5C4E4DE071C}\ProxyStubClsid
Value={00020424---C000-0046} Type=string
/
RegistryValue
Id=_ADA1E9C6DAC34E479D5063CB53A5C5B7 Root=HKCR
Key=Interface\{D55F1491-5EA3-4A9F-B746-F5C4E4DE071C}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string
/
RegistryValue Id=_57B1136CC4764B6E96761EC1F026515B
Root=HKCR
Key=Interface\{D55F1491-5EA3-4A9F-B746-F5C4E4DE071C}\TypeLib
Value={75E29D5A-DF04-479A-ACCB-473EEF7A5B23}
Type=string /
RegistryValue
Id=_E074DD719CBC4C5EA39EB8A7A7E9EAEE Root=HKCR
Key=Interface\{D55F1491-5EA3-4A9F-B746-F5C4E4DE071C}\TypeLib
Name=Version Value=1.0 Type=string /
/Component
On 8/30/06, Derek Cicerone
[EMAIL PROTECTED]
wrote:
.tlb files aren't supported yet.
I thought those were usually compiled into a .dll or other file when shipped to
the customer. Do you ship the .tlb as part of your setup? Does the
.tlb register a separate .dll file in the actual registry keys?
Derek
From: Brad Davis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 30, 2006 6:59 AM
To: [EMAIL PROTECTED]
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] using heat to harvest COM objects that do not
have the '.dll' extension.
As of last week's release, .tlb files didn't
work eitheralthough I didn't verify that it was already registered prior to
harvesting, as I believe that's a pre-req?
On 8/30/06, Derek Cicerone [EMAIL PROTECTED]
wrote:
Hehe, alright, I just fixed
it. This should be in the next WiX 3.0 release.
Derek
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Ali-Akber Saifee
Sent: Wednesday, August 30, 2006 2:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] using heat to harvest COM objects that do not have
the '.dll' extension.
Some of my installation components use DirectShow filters... (*.ax files)..
when i try to harvest them with heat the class information + registry
information is not extracted. I suspect this is due to a wildcard filter which
is not classifying .ax files as possible candidates for COM objects...
i tried simply renaming the file to a .dll and it is harvested properly
then.. .ocx files are also ok.
rgrds./Ali
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
-Brad
--
-Brad
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo
Re: [WiX-users] Light error 0216
What happens if you pass -sval when running light? Im wondering if you dont even have permission to run installations (which validation kinda is one) on that machine. Derek From: Darrel Miller [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 12:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Light error 0216 Hi Rob, Win2K3 R2 Enterprise Edition Service Pack 1 Windows Installer. V 3.01.4000.1830 Running under VMWare Server. Darrel From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: August 30, 2006 3:43 PM To: 'Darrel Miller'; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Light error 0216 Are you building on Win2k3? If so, what version of the Windows Installer do you have on the machine? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrel Miller Sent: Wednesday, August 30, 2006 12:34 To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Light error 0216 Hi Derek, Here are the details: When the following command is executed, C:\Build\TM2Client\Development\Sources\TM21\WixInstallerC:\bin\wix\wix-3.0.2015.0-binaries\light -out test.msi obj\release\product.wixobj the following error occurs light.exe : error LGHT0216 : An unexpected Win32 exception with error code 0x659 occurred: This installation is forbidden by system policy. Contact your system administrator - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat?
The 1:1 mapping is more costly, but the performance impact is minimal compared to the pain of having an unserviceable release. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob MacFadyen Sent: Wednesday, August 30, 2006 9:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat? Richard, Thanks for the link. I'm now wondering if the 1-to-1 mapping of components to files becomes the norm, what will happen to performance (the same link cautions to keep the number of components to a minimum). Isn't the component keypath checked as part of repair logic? If lots of applications are doing 1-to-1 component to file mapping, then the does anything need repairing routine will suffer considerably... won't it? Can anyone comment on the performance aspects of 1 to 1 component/file mapping? Regards, Rob MacFadyen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] HEAT5158 error..
Your best shot may be to just debug this directly its just C# code interacting with directory services after all. Unfortunately, the errors returned by directory services are usually pretty sparse, so its hard to say what went wrong. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Davis Sent: Monday, August 28, 2006 12:31 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] HEAT5158 error.. I enter the command below, and I get the HEAT5158 error...do I need a URL-type reference instead? My case is correct: C:\Inetpub\wwwrootheat website ChangeTracking -out changetracking.wxs Microsoft (R) Windows Installer XML Toolset Harvester version 3.0.2023.0 Copyright (C) Microsoft Corporation 2006. All rights reserved. heat.exe : error HEAT5158 : The web site 'ChangeTracking' could not be found. Please check that the web site e xists, and that it is spelled correctly (please note, you must use the correct case). Regards, -- -Brad - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] AddValidReference missing?
Weve changed the APIs for extensions in WiX 3.0. Please take a look at CompilerCore.cs to get an idea of whats now available. Specifically, for simple references, we now track source line information so that error messages can not only tell you that a referenced item is unavailable but also tell you where it was referenced from (which is extremely useful when debugging that type of an error). Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stumpf, Mark Sent: Thursday, August 24, 2006 7:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] AddValidReference missing? I am trying out the most recent release of WiX 3.0 (3.0.2023.0) When I attempt to compile, I get an error that says, error CS0117: 'Microsoft.Tools.WindowsInstallerXml.CompilerCore' does not contain a definition for 'AddValidReference' I looked in the Object Browser and found that AddValidReference is missing from CompilerCore, but was present in the 1821 version. Am I missing something? Do we need to use a different call? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failed to locate connection for merge
What version of WiX are you using (the exact version)? That looks like a bug weve fixed already. Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Ludlow Sent: Thursday, August 24, 2006 9:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Failed to locate connection for merge Hi all, I have an installation that is including several merge modules (some are ours, some are written by MS). Now, I'm trying to add another called VaultMessages, and light is throwing the following error: light.exe : error LGHT0001 : Failed to locate connection for merge: VaultMessages.dll Exception Type: System.ApplicationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String databasePath, Output output) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run (String[] args) Has anyone seen anything like this before? Thanks John - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WIX 3.0: File name problems
Please download the latest weekly release. I believe I caught and fixed that bug on Tuesday. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Davis Sent: Thursday, August 24, 2006 12:18 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: [WiX-users] WIX 3.0: File name problems Using WIX 3.latest: It seems that it doesn't like files that are not dlls: I keep on getting this error when trying to 'light' it up...this used to work in 2.x btw: C:\Projects\Atlas.Validation.Installers\ValidationMSI.wxs(19) : error LGHT0132 : The assembly file 'C:\Projects\Atlas.Validation\Build_RELEASE_Assembly\w3wp.exe .config' appears to be invalid. Please ensure this is a valid assembly file and that the user has the appropriate access rights to this file. More information : The format of the file 'w3wp.exe.config' is invalid. C:\Projects\Atlas.Validation.Installers\ValidationMSI.wxs(27) : error LGHT0132 : The assembly file 'C:\Projects\Atlas.Validation\Build_RELEASE_Assembly\Atlas.Va lidation.DispatchWrapper.tlb' appears to be invalid. Please ensure this is a va lid assembly file and that the user has the appropriate access rights to this fi le. More information: The format of the file 'Atlas.Validation.DispatchWrapper. tlb' is invalid. Any ideas? -- -Brad - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix-3.0 and existing Merge Modules
The merge modules do not have the _Validation rows required for validation to succeed. You'll need to ensure the tables in the merge modules exist in your MSI file before the merging occurs. Add something like the following for each table reported below: EnsureTable Id=Component / Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: Wednesday, August 23, 2006 6:08 PM To: Wix-users Subject: [WiX-users] Wix-3.0 and existing Merge Modules Hi, I recently converted one of my Wix-2.0 projects to Wix-3.0. The project uses multiple merge modules obtained from InstallShield (as we use InstallShield X too). In particular, I am using the OLEAUT32.MSM, COMCAT.MSM and MSVBVM60.MSM merge modules (plus others, MSXML4, Common Controls etc). I am inserting the modules using: ... Directory Id=INSTALLDIR Name=MyLocation Merge Id=COMCATMERGE DiskId=1 SourceFile=C:\Merge Modules\COMCAT.MSM Language=0 / Merge Id=OLEAUT32MERGE DiskId=1 SourceFile=C:\Merge Modules\OLEAUT32.MSM Language=0 / Merge Id=VB6SP6RUNTIMEMERGE DiskId=1 SourceFile=C:\Merge Modules\MSVBVM60.MSM Language=0 / ... /Directory ... Feature Id=ProductFeature Title=Program Files Level=1 InstallDefault=local AllowAdvertise=no ConfigurableDirectory=INSTALLDIR TypicalDefault=install MergeRef Id=OLEAUT32MERGE/ MergeRef Id=COMCATMERGE/ MergeRef Id=VB6SP6RUNTIMEMERGE/ /Featue Candle doesn't produce any errors. When I Light, I receive multiple errors: Microsoft (R) Windows Installer Xml Linker version 3.0.2015.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. : error LGHT0204 : ICE03: Table: Registry Column: Registry Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Registry Column: Root Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Registry Column: Key Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Registry Column: Name Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Registry Column: Value Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Registry Column: Component_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Extension Column: Extension Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Extension Column: Component_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Extension Column: ProgId_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Extension Column: MIME_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Extension Column: Feature_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: MIME Column: ContentType Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: MIME Column: Extension_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: MIME Column: CLSID Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: CLSID Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Context Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Component_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: ProgId_Default Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Description Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: AppId_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: FileTypeMask Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Icon_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: IconIndex Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: DefInprocHandler Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Argument Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Feature_ Missing specifications in _Validation Table (or Old Database) : error LGHT0204 : ICE03: Table: Class Column: Attributes Missing specifications in _Validation Table (or Old Database) : error LGHT0204 :
Re: [WiX-users] Error using Candle under 2.0.4415.0
You can't mix and match tools. You'd need to grab the entire toolset release so that candle/wix/light/etc... all match. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david adams Sent: Tuesday, August 22, 2006 12:42 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error using Candle under 2.0.4415.0 I am checking to see if the ConfigureIIS custom action still has the buffer overflow problem in release 4415. I got the following error attempting to [CANDLE] the project. candle.exe : error CNDL0001 : Could not load file or assembly 'wix, Version=2.0.4221.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) Exception Type: System.IO.FileLoadException Stack Trace: at System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark stackMark, Boolean loadTypeFromPartialName) at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark stackMark) at System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, B oolean ignoreCase, Boolean reflectionOnly, StackCrawlMark stackMark) at System.Type.GetType(String typeName) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) David Adams MSN MessengerID: [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126 (Verbose Output)
That's the problem right there - I noticed the version of the toolset you
are using is a bit old - please try the latest weekly release of 2.0 to see
if that fixes the issue. If not, please open a bug with the log information
below - it looks like the CA is not properly handling a machine with many
websites already installed. How many websites are previously installed on
the machine?
Thanks,
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of david adams
Sent: Monday, August 21, 2006 7:35 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
(Verbose Output)
Derek:
I am copying the relevant section of the output. It appears the the problem
occurs in ConfigureIIS. The first reported failure is in Insufficient
buffer error.
David Adams
MSN MessengerID: [EMAIL PROTECTED]
Action ended 10:29:26: InstallFiles. Return value 1.
Action 10:29:26: ConfigureIIs. Configuring IIS
Action start 10:29:26: ConfigureIIs.
Action 10:29:26: StartMetabaseTransaction. Starting IIS Metabase Transaction
Action start 10:29:26: StartMetabaseTransaction.
1: Starting IIS Metabase Transaction
Action ended 10:29:26: StartMetabaseTransaction. Return value 1.
Action 10:29:26: RollbackMetabaseTransaction. Rolling back IIS Metabase
Transaction
Action start 10:29:26: RollbackMetabaseTransaction.
1: Rolling back IIS Metabase Transaction
Action ended 10:29:26: RollbackMetabaseTransaction. Return value 1.
Action 10:29:26: CommitMetabaseTransaction. Committing IIS Metabase
Transaction
Action start 10:29:26: CommitMetabaseTransaction.
1: Committing IIS Metabase Transaction
Action ended 10:29:26: CommitMetabaseTransaction. Return value 1.
ConfigureIIs: Error 0x8007007a: Insufficient buffer to track all
sub-WebSites
ConfigureIIs: Error 0x8007007a: Failed to find web root
ConfigureIIs: Error 0x8007007a: failed to read IIsWebSite table
Error 26002. Failed to read IIsWebs table. (-2147024774 )
MSI (s) (5C!0C) [10:29:29:166]: Product: Crawford RiskTech Interfaces --
Error 26002. Failed to read IIsWebs table. (-2147024774 )
Action ended 10:29:29: ConfigureIIs. Return value 3.
Action ended 10:29:29: INSTALL. Return value 3.
From: Derek Cicerone [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: 'david adams'
[EMAIL PROTECTED],wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
Date: Sun, 20 Aug 2006 16:51:04 -0700
MIME-Version: 1.0
Received: from winisp-fe1.winisp.net ([192.197.157.82]) by
bay0-mc3-f15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Sun,
20 Aug 2006 16:51:10 -0700
Received: from derekclap ([24.19.239.190]) by winisp-fe1.winisp.net over
TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006
16:51:05 -0700
X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlKtU9j2Z7TuGo=
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcbEWdpJmgcexPGzReG/rfznV0qBqAAWS3+A
Content-Language: en-us
x-cr-puzzleid: {24B75461-3B63-4C9E-91F0-D9A3733C075F}
x-cr-hashedpuzzle: ANCj ASoD B9Wr D64F GeSW G7HL G8Wb HO5P H7VP IsHi NCIV
NMNb OCzW Qgvm TB9Z
U1rY;2;ZABhAHYAaQBkAGEAZABhAG0AcwAwADAAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0AOwB3
AGkAeAAtAHUAcwBlAHIAcwBAAGwAaQBzAHQAcwAuAHMAbwB1AHIAYwBlAGYAbwByAGcAZQAuAG4A
ZQB0AA==;Sosha1_v1;7;{24B75461-3B63-4C9E-91F0-D9A3733C075F};ZABlAHIAZQBrAGMA
QAB1AHMAZQByAHMALgBzAG8AdQByAGMAZQBmAG8AcgBnAGUALgBuAGUAdAA=;Sun,
20 Aug 2006 23:50:00
GMT;UgBFADoAIABbAFcAaQBYAC0AdQBzAGUAcgBzAF0AIABbAEIAdQBnACAAIwAxADQAOQA4ADY
ANAA1ACAAXQAgAEMAbwBuAGYAaQBnAHUAcgBlACAASQBJAFMAIABlAHIAcgBvAHIAIABvAG4AIAA
yAC4AMAAuADQAMQAyADYA
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 20 Aug 2006 23:51:06.0149 (UTC)
FILETIME=[808C0D50:01C6C4B3]
That's a separate issue - that is a custom action failure. Some of the
scenarios in which I heard that might happen include wrong/missing IIS on
the target machine. I'm really not an expert on the IIS stuff so I'll have
to defer to someone more knowledgeable. One thing you can do to make this
easier to debug is get a verbose installation log and post the lines of the
failure (and around it) here.
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of david adams
Sent: Sunday, August 20, 2006 6:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
It sounded like the same symptoms.
Candle and Light process successfully, but the MSI gets a Windows Installer
Error 'Failed to read IIs Webs Table' (the failed table read is either
'Webs' or 'Web'). The symptoms seemed very similar to the 3.0 problem that
was apparently a missing extension.
David Adams
MSN MessengerID: [EMAIL PROTECTED]
From: Derek Cicerone [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: 'david adams'
[EMAIL PROTECTED],wix-users@lists.sourceforge.net
Subject: RE
Re: [WiX-users] Detecting .NET Framework version installed
I just looked at those conditions and I'd like to add one more thing: please always add Installed OR to any launch condition. The launch conditions are always run during an installation activity (such as reinstall and uninstallation). So given the examples below, if a user uninstalls the .net framework 2.0 they will not be able to uninstall your application. This is probably unlikely but there are tons of scenarios in which I've seen poor launch conditions prevent uninstallations or reinstallations of products. Also, all the registry searches listed in the tutorial for .net can now be found in the NetFx extension (along with a CA for running NGen 2.0 on your assemblies). I strongly recommend using these registry searches versus your own (we've even got one for .NET 3.0). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Biryukov Sent: Monday, August 21, 2006 9:32 AM To: Harvey Werner; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Detecting .NET Framework version installed See WiX tutorial : http://www.tramontana.co.hu/wix/lesson6.php On Mon, 21 Aug 2006 20:23:11 +0400, Harvey Werner [EMAIL PROTECTED] wrote: I am still a newbie to WiX and would like to know the best way using WiX to detect what version of .NET framework is installed on a local machine. The install needs to detect if .NET 2.0 is installed or not. Can someone please point me in the right direction? Thanks. -- Harvey Werner / [EMAIL PROTECTED] / 971.327.5279 -- Alexander Biryukov - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
That's a separate issue - that is a custom action failure. Some of the
scenarios in which I heard that might happen include wrong/missing IIS on
the target machine. I'm really not an expert on the IIS stuff so I'll have
to defer to someone more knowledgeable. One thing you can do to make this
easier to debug is get a verbose installation log and post the lines of the
failure (and around it) here.
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of david adams
Sent: Sunday, August 20, 2006 6:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
It sounded like the same symptoms.
Candle and Light process successfully, but the MSI gets a Windows Installer
Error 'Failed to read IIs Webs Table' (the failed table read is either
'Webs' or 'Web'). The symptoms seemed very similar to the 3.0 problem that
was apparently a missing extension.
David Adams
MSN MessengerID: [EMAIL PROTECTED]
From: Derek Cicerone [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: 'david adams'
[EMAIL PROTECTED],wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
Date: Fri, 18 Aug 2006 16:42:02 -0700
MIME-Version: 1.0
Received: from winisp-ti72.winisp.net ([192.197.157.85]) by
bay0-mc9-f3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 18
Aug 2006 16:42:19 -0700
Received: from derekclap ([131.107.0.71]) by winisp-ti72.winisp.net over
TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006
16:42:18 -0700
X-Message-Info: LsUYwwHHNt2Rk1wRN5NPmisemruUgqRK70Qxh9B3QcA=
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcbDHK8MLa3KkKiOQkaTW0QoGs+lqgAAxRag
Content-Language: en-us
x-cr-puzzleid: {106F9247-2D97-41F9-B01B-0D5748113E40}
x-cr-hashedpuzzle: DdR6 DokY GN62 IipQ NDL+ NNEu N+BB PMXf Pa1v Pfvq Qn0a
SVT4 SYii WBF3 W/ZP
Xohg;2;ZABhAHYAaQBkAGEAZABhAG0AcwAwADAAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0AOwB3
AGkAeAAtAHUAcwBlAHIAcwBAAGwAaQBzAHQAcwAuAHMAbwB1AHIAYwBlAGYAbwByAGcAZQAuAG4A
ZQB0AA==;Sosha1_v1;7;{106F9247-2D97-41F9-B01B-0D5748113E40};ZABlAHIAZQBrAGMA
QAB1AHMAZQByAHMALgBzAG8AdQByAGMAZQBmAG8AcgBnAGUALgBuAGUAdAA=;Fri,
18 Aug 2006 23:42:00
GMT;UgBFADoAIABbAFcAaQBYAC0AdQBzAGUAcgBzAF0AIABbAEIAdQBnACAAIwAxADQAOQA4ADY
ANAA1ACAAXQAgAEMAbwBuAGYAaQBnAHUAcgBlACAASQBJAFMAIABlAHIAcgBvAHIAIABvAG4AIAA
yAC4AMAAuADQAMQAyADYA
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 18 Aug 2006 23:42:18.0894 (UTC)
FILETIME=[F173D2E0:01C6C31F]
The problem listed below is not a bug - it's just a change in how 3.0
works.
What problem are you experiencing with 2.0?
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of david adams
Sent: Friday, August 18, 2006 4:19 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
Does anyone know a status on this bug? I am experiencing the same problem
using
WiX v.2.0.4221.0
We moved to 4221 from 3309 (where it worked) to implement MessageQueue
functionality, but may have to revert if there is not a solution to this
problem.
Any ideas?
David Adams
MSN MessengerID: [EMAIL PROTECTED]
From: Brad Davis [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WIX 3.0: Creating IIS virtual directories
Date: Fri, 18 Aug 2006 16:29:48 -0500
MIME-Version: 1.0
Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by
bay0-mc2-f16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444);
Fri,
18 Aug 2006 14:29:58 -0700
Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93])by
sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid 9D57812D23; Fri, 18
Aug
2006 14:29:57 -0700 (PDT)
Received: from sc8-sf-mx1-b.sourceforge.net
([10.3.1.91]helo=mail.sourceforge.net)by
sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)id
1GEBud-0001hy-3Zfor wix-users@lists.sourceforge.net; Fri, 18 Aug 2006
14:29:55 -0700
Received: from nz-out-0102.google.com ([64.233.162.205])by
mail.sourceforge.net with esmtp (Exim 4.44) id 1GEBuc-pW-8Xfor
wix-users@lists.sourceforge.net; Fri, 18 Aug 2006 14:29:55 -0700
Received: by nz-out-0102.google.com with SMTP id l8so593835nzffor
wix-users@lists.sourceforge.net;Fri, 18 Aug 2006 14:29:52 -0700 (PDT)
Received: by 10.65.98.4 with SMTP id a4mr4344742qbm;Fri, 18 Aug 2006
14:29:52 -0700 (PDT)
Received: by 10.64.243.6 with HTTP; Fri, 18 Aug 2006 14:29:48 -0700
(PDT)
X-Message-Info: LsUYwwHHNt13J04AU+y+/C+O2WduChQ9i3ZT82fnpL8=
References:
[EMAIL PROTECTED]007a01c6c
[EMAIL PROTECTED]d8b3e9d60608181152p47403ef6x748
[EMAIL PROTECTED][EMAIL PROTECTED]
ge.net
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.See
http://spamassassin.org/tag/ for more details.Report problems
tohttp://sf.net/tracker/?func=addgroup_id=1atid=210.0
Re: [WiX-users] WIX 3.0: Creating IIS virtual directories
Please keep wix-users on the thread. You need to pass in -ext WixIIsExtension for the candle/lit/light command lines now. No non-standard functionality is baked into the wix tools anymore everything has been moved out into extensions. Derek From: Brad Davis [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 11:52 AM To: [EMAIL PROTECTED] Subject: Re: [WiX-users] WIX 3.0: Creating IIS virtual directories No changes...my file looks at: http://schemas.microsoft.com/wix/2006/wi I did add the xmlns for IISextension as an attribute, and the candle error changed, now it's looking for an extension: C:\Projects\Atlas.Validation.Installers\ShipmentWSInstallerMSI.wxs(53) : error CNDL0200 : The Component element contains an unhandled extension element 'WebVirtualDir'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/IIsExtension ' namespace has been provided. This is the element in question: Component Id=C_shipmentsavewsdir Guid=493E3487-AA4C-4476-8CC0-4B1C763AF6F7 WebVirtualDir Id=ShipmentSaveWSDir Alias=ShipmentSaveWS Directory=InstallDir WebSite=DefaultWebSite xmlns= http://schemas.microsoft.com/wix/IIsExtension WebApplication Id=ShipmentSaveWS Name=ShipmentSaveWS / /WebVirtualDir /Component Thanks, -Brad On 8/18/06, Derek Cicerone [EMAIL PROTECTED] wrote: Please try running wixcop on your source file it should automatically update it to the proper schema for your version of 3.0. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Davis Sent: Friday, August 18, 2006 8:28 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WIX 3.0: Creating IIS virtual directories Why doesn't this work? Things have changed since 2.0I based my syntax on the online tutorial. See attached .wxs file Thanks, -- -Brad -- -Brad - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
The problem listed below is not a bug - it's just a change in how 3.0 works. What problem are you experiencing with 2.0? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david adams Sent: Friday, August 18, 2006 4:19 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126 Does anyone know a status on this bug? I am experiencing the same problem using WiX v.2.0.4221.0 We moved to 4221 from 3309 (where it worked) to implement MessageQueue functionality, but may have to revert if there is not a solution to this problem. Any ideas? David Adams MSN MessengerID: [EMAIL PROTECTED] From: Brad Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WIX 3.0: Creating IIS virtual directories Date: Fri, 18 Aug 2006 16:29:48 -0500 MIME-Version: 1.0 Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by bay0-mc2-f16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 18 Aug 2006 14:29:58 -0700 Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93])by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid 9D57812D23; Fri, 18 Aug 2006 14:29:57 -0700 (PDT) Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91]helo=mail.sourceforge.net)by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)id 1GEBud-0001hy-3Zfor wix-users@lists.sourceforge.net; Fri, 18 Aug 2006 14:29:55 -0700 Received: from nz-out-0102.google.com ([64.233.162.205])by mail.sourceforge.net with esmtp (Exim 4.44) id 1GEBuc-pW-8Xfor wix-users@lists.sourceforge.net; Fri, 18 Aug 2006 14:29:55 -0700 Received: by nz-out-0102.google.com with SMTP id l8so593835nzffor wix-users@lists.sourceforge.net;Fri, 18 Aug 2006 14:29:52 -0700 (PDT) Received: by 10.65.98.4 with SMTP id a4mr4344742qbm;Fri, 18 Aug 2006 14:29:52 -0700 (PDT) Received: by 10.64.243.6 with HTTP; Fri, 18 Aug 2006 14:29:48 -0700 (PDT) X-Message-Info: LsUYwwHHNt13J04AU+y+/C+O2WduChQ9i3ZT82fnpL8= References: [EMAIL PROTECTED]007a01c6c [EMAIL PROTECTED]d8b3e9d60608181152p47403ef6x748 [EMAIL PROTECTED][EMAIL PROTECTED] ge.net X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems tohttp://sf.net/tracker/?func=addgroup_id=1atid=210.0 RCVD_BY_IP Received by mail server with no name0.1 HTML_40_50 BODY: Message is 40% to 50% HTML0.0 HTML_MESSAGE BODY: HTML included in message X-BeenThere: wix-users@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: General discussion for Windows Installer XML toolset.wix-users.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:wix-us [EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=wix-users List-Post: mailto:wix-users@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:wix-us [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 18 Aug 2006 21:29:58.0782 (UTC) FILETIME=[74C6E1E0:01C6C30D] Derek, Thank you so much for your assistance.sure hope they document this soon, or is it somewhere I'm unaware of? I looked in the .chm...anyway, progress: Candle works, light doesn't, whether I put the -ext before or after the object file: C:\Projects\Atlas.Validation.Installerslight ShipmentWSInstallerMSI.wixobj-ext WixIISExtension Microsoft (R) Windows Installer Xml Linker version 3.0.2015.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (62) : error LGHT0102 : The localization variable !(loc.ConfigureIIs) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (63) : error LGHT0102 : The localization variable !(loc.StartMetabaseTransaction) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (64) : error LGHT0102 : The localization variable !(loc.RollbackMetabaseTransaction) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (65) : error LGHT0102 : The localization variable !(loc.CommitMetabaseTransaction) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (66) : error LGHT0102 : The localization variable !(loc.WriteMetabaseChanges) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs (28) : error LGHT0102 : The localization variable !(loc.msierrIISCannotConnect) is unknown. Please ensure the variable is defined. On 8/18/06, Derek Cicerone [EMAIL
Re: [WiX-users] MSComm32.ocx MSM not registering ocx
When you use the merge module, do you see the mscomm32.ocx file get installed? Do you have a verbose installation log? Those are really useful for tracking down issues. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 3:00 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx mscomm32.msm Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 5:56 PM To: 'Dave Williamson'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx Which msm is causing problems (what is its exact name)? Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Williamson Sent: Thursday, August 17, 2006 2:46 PM To: 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx The versions of the file are the same. Actually it was the same physical file just to be sure (I used the extracted file from the msm). OK. So now I'm back to using the Tallow generated code (because it works) but I'm at a cross roads. Rob has said that the component's GUID is super important when trying to keep up with shared files installed on a machine ... in this case the shared file is a vb 6 ocx control. And the Tallow code does not match the Dark code of the msm so technically I should not use the msm component GUID with the tallow code because they are different ... yet what is being accomplished is installing a shared file, mscomm32.ocx, on the end user's system32 dir, registered, and reference counted ... and that does need to be coordinated with other folks installing that same file. If I use the same GUID then the mscomm32.ocx should not be uninstalled prematurely if my app is uninstalled and other apps that have installed the ocx are still installed. If I use a different GUID then the mscomm32.ocx could be uninstalled if the basic reference counting is out of whack. What a [EMAIL PROTECTED] if you do and [EMAIL PROTECTED] if you don't situation. Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 4:48 PM To: Dave Williamson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx Dave Williamson wrote: The Dark output showed some interesting constructs that were not directly in the tallow code but seemed like they were the same thing but represented in a different manner. Yes, tallow doesn't know how to use the strongly-typed COM-registration elements. (Heat, in WiX v3, does.) So it just turns them into registry values. The only other suggestion I can think of is to check the files in the merge module, to make sure you're using the same version. It's been ages since I worried about COM evils.g -- sig://boBhttp://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSComm32.ocx MSM not registering ocx
Weird I did a comparison of the registry values in the self-registration and those in the merge module but they seem to be very similar. Im not sure whats going on there sorry. The only thing I can think of would be to export your HKCR hive in the broken state, then run the self-reg, then export it again to see what changed. That might provide some clues. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 3:43 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx The log file was too big for email accounts so is there any particular part you want to see? Here is the section that copies the mscomm32.ocx: MSI (s) (B0:F4): Executing op: SetTargetFolder(Folder=C:\WINDOWS\System32\) MSI (s) (B0:F4): Executing op: SetSourceFolder(Folder=1\PFiles\FICS\Redist\MS\System\) MSI (s) (B0:F4): Executing op: FileCopy(SourceName=mscomm32.ocx,SourceCabKey=Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24,DestName=mscomm32.ocx,Attributes=0,FileSize=103744,PerTick=32768,,VerifyMedia=1,CheckCRC=0,Version=6.0.81. 69,Language=1033,InstallMode=58982400,,) MSI (s) (B0:F4): File: C:\WINDOWS\System32\mscomm32.ocx; To be installed; No patch; No existing file MSI (s) (B0:F4): Source for file 'Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24' is compressed InstallFiles: File: mscomm32.ocx, Directory: C:\WINDOWS\System32\, Size: 103744 MSI (s) (B0:F4): Note: 1: 2318 2: C:\WINDOWS\System32\mscomm32.ocx MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Executing op: InstallProtectedFiles(AllowUI=1) MSI (s) (B0:F4): Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: , Name: , Value: ) Keep in mind that in this particular case the file is getting installed but it isn't getting registered completely because a manual registration after the install corrects any missing or invalid registration. Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:23 PM To: '[EMAIL PROTECTED]'; 'Bob Arnson' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx Yes the file gets installed. I was using a fresh install of windows XP in virtual pc so the file does not exist at all to begin with. And yes I have a verbose log (it is attached). Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 6:14 PM To: 'Dave Williamson'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx When you use the merge module, do you see the mscomm32.ocx file get installed? Do you have a verbose installation log? Those are really useful for tracking down issues. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 3:00 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx mscomm32.msm Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 5:56 PM To: 'Dave Williamson'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx Which msm is causing problems (what is its exact name)? Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Williamson Sent: Thursday, August 17, 2006 2:46 PM To: 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx The versions of the file are the same. Actually it was the same physical file just to be sure (I used the extracted file from the msm). OK. So now I'm back to using the Tallow generated code (because it works) but I'm at a cross roads. Rob has said that the component's GUID is super important when trying to keep up with shared files installed on a machine ... in this case the shared file is a vb 6 ocx control. And the Tallow code does not match the Dark code of the msm so technically I should not use the msm component GUID with the tallow code because they are different ... yet what is being accomplished is installing a shared file, mscomm32.ocx, on the end user's system32 dir, registered, and reference counted ... and that does need to be coordinated with other folks installing that same file. If I use the same GUID then the mscomm32.ocx should not be uninstalled prematurely if my app is uninstalled
Re: [WiX-users] MSComm32.ocx MSM not registering ocx
If it installs the file to the same place as the MSM, then use the same guid. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 4:09 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx Yep. Did that earlier. See earlier post to thread. I don't think the problem is a Wix problem. And I don't think it is going to get solved anytime soon because it is a 3rd party msm. So what I need to do is author something with Wix that tries to accomplish my goals without screwing up everyone else who might depend on this shared component. What would you do ... use the same GUID as the msm (and hope that the root of the problem is getting to the end point and not the end point) in the hopes that when the true problem is discovered the end install result will be the same or be true to the fact that the tallowed version of the component is not the same and use a new GUID? Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 7:01 PM To: 'Dave Williamson'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx Weird I did a comparison of the registry values in the self-registration and those in the merge module but they seem to be very similar. Im not sure whats going on there sorry. The only thing I can think of would be to export your HKCR hive in the broken state, then run the self-reg, then export it again to see what changed. That might provide some clues. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 3:43 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx The log file was too big for email accounts so is there any particular part you want to see? Here is the section that copies the mscomm32.ocx: MSI (s) (B0:F4): Executing op: SetTargetFolder(Folder=C:\WINDOWS\System32\) MSI (s) (B0:F4): Executing op: SetSourceFolder(Folder=1\PFiles\FICS\Redist\MS\System\) MSI (s) (B0:F4): Executing op: FileCopy(SourceName=mscomm32.ocx,SourceCabKey=Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24,DestName=mscomm32.ocx,Attributes=0,FileSize=103744,PerTick=32768,,VerifyMedia=1,CheckCRC=0,Version=6.0.81. 69,Language=1033,InstallMode=58982400,,) MSI (s) (B0:F4): File: C:\WINDOWS\System32\mscomm32.ocx; To be installed; No patch; No existing file MSI (s) (B0:F4): Source for file 'Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24' is compressed InstallFiles: File: mscomm32.ocx, Directory: C:\WINDOWS\System32\, Size: 103744 MSI (s) (B0:F4): Note: 1: 2318 2: C:\WINDOWS\System32\mscomm32.ocx MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Executing op: InstallProtectedFiles(AllowUI=1) MSI (s) (B0:F4): Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: , Name: , Value: ) Keep in mind that in this particular case the file is getting installed but it isn't getting registered completely because a manual registration after the install corrects any missing or invalid registration. Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:23 PM To: '[EMAIL PROTECTED]'; 'Bob Arnson' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx Yes the file gets installed. I was using a fresh install of windows XP in virtual pc so the file does not exist at all to begin with. And yes I have a verbose log (it is attached). Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 6:14 PM To: 'Dave Williamson'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSComm32.ocx MSM not registering ocx When you use the merge module, do you see the mscomm32.ocx file get installed? Do you have a verbose installation log? Those are really useful for tracking down issues. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 3:00 PM To: [EMAIL PROTECTED]; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSComm32.ocx MSM not registering ocx mscomm32.msm Dave Williamson Clear Sky Software [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, August 17, 2006 5:56 PM To: 'Dave
Re: [WiX-users] The property name that I set on the command line becomes all upper cased
Im surprised that Windows Installer was nice enough to uppercase it for you and didnt just display an error. You cannot specify a mixed-case property on the command line. Only uppercase properties can be specified because they are public properties. This is due to the security design for how properties are handled. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dangle123 ... Sent: Wednesday, August 16, 2006 2:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The property name that I set on the command line becomes all upper cased When I try to set a property throught the command line as follows, the namereceived asupper case by the MSI. msiexec.exe /i sample.msi /l*v c:\sample.log PropertyName=SomeValue PropertyName becomes PROPERTYNAME as indicated in the log. Is there a way to prevent the property name from changing to all upper case? Thanks in advance, -- Leo - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Light error 0216
Title: Message Please try the latest 3.0 release were continuously fixing bugs for 3.0 and being even a little behind can be somewhat painful. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Cadenas Sent: Tuesday, August 15, 2006 9:31 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Light error 0216 I tested the same files with version 2.0.3309.0 and I didn't have any problems. Just FYI for those of you using 3.0.1821.0 Diego Cadenas Web Application Developer www.bsecure.com 850.275.1010 xt.7208 Phone 850.362.4303 xt.7501 Fax -- Internet Email Confidentiality Statement -- Information contained in this e-mail message is intended only for the individual to whom it is addressed and is private and confidential. If you are not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please kindly destroy it and notify the sender immediately by reply e-mail. Thank you for your cooperation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Cadenas Sent: Tuesday, August 15, 2006 11:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Light error 0216 I downloaded the 3.0 version of votive which comes with WiX's core files. For some reason everytime I try to use lightI get the following error: light.exe : error LGHT0216 : An unexpected Win32 exception occurred: The system cannot open the device or file specified First, I got this error trying to create merge modules. First Irebuilt my assemblies to discartdll corruption. i made sure my assembly attribute for file is set to .net. I alsomade sure that my dll's and merge modules are under the samedirectory. Then I tried to create the msi without msm's, just a direct reference to the dll in question. Same error. Finally I downloaded the first sample from Gábor. Same light error showed up. Iam doing something stupidly wrong? the light version i got is 3.0.1821.0 Thanks Diego Cadenas Web Application Developer www.bsecure.com 850.275.1010 xt.7208 Phone 850.362.4303 xt.7501 Fax -- Internet Email Confidentiality Statement -- Information contained in this e-mail message is intended only for the individual to whom it is addressed and is private and confidential. If you are not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please kindly destroy it and notify the sender immediately by reply e-mail. Thank you for your cooperation. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible MergeModule bug
I agree there should be some way to catch this mistake. Before
you added the dummy directory entry, did the MSI even include the custom action
to set the modularized directory name to the real directory name or did it omit
that? Basically, Im trying to figure out what crumbs will be left behind by
the merge process that we might be able to catch in an ICE.
Thanks,
Derek
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Friday, August 11, 2006 9:27 AM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Possible MergeModule bug
Yes adding the dummy entry fixed the problem. We have checked both
VS2003 and VS2005 and neither of them create modularized folder names - so I
guess that is where the bug is!
In an ideal world there should be an ICE error if the dummy folder
is missing.
Neil
From: Rob Mensching
[mailto:[EMAIL PROTECTED]
Sent: 10 August 2006 18:01
To: Neil Sleightholm; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Possible MergeModule bug
Standard directories are a little bit different. The way
they work is you add a GUID to them everywhere. You also need to make
sure the WindowsFolder is listed in your Directory table for your Merge Module
(which I think is probably the root of your bug). Then, during the merge
process mergemod.dll creates Type 51 CustomActions that resolve
WindowsFolder.GUID to WindowsFolder.
I think this is silly. My original draft of the Merge Module
specification did exactly what you described below. However, the final
draft of the spec was updated as per above. I never got a good answer (at
least, not one I remember wink/) why the documented way is
better. I want to say it had something to do with the way UI in Merge
Modules might work... but whatever.
Try adding WindowsFolder to your Directory tree.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Wednesday, August 09, 2006 12:28 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Possible MergeModule bug
I
thinkwe have found a bug in WiX (both 2 and 3) concerning the
modularization of various field values when making a merge
module.As we understand it modularization means appending the
module GUID to things like component names to make them unique when actually
merged into an MSI. The WiX code also does this for properties in formatted
fields, presumably to avoid property name clashes with the parent
MSI (or any other merge modules). It doesn't modularize if the
property is a standard one, but this check fails to include standard
directories (which can also be used as properties).We found this bug when
attempting to set a registry value for an event source, e.g.:
Registry
Root=HKLM Key=SYSTEM\CurrentControlSet\Services\Eventlog\Application\Enterprise
Library Logging Name=EventMessageFile
Value=[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
Type=string /
In this
example[WindowsFolder] ended up as [WindowsFolder.moduleguid]. This of
course fails to resolve in the MSI resulting in an empty substitution
value.We checked the same thing using a VS merge module setup project and
it was fine. We traced through the WiX2 source and added the additional check
for a standard directory in OutputRow.cs (on or near line 231)and it now
worksok e.g.:
string
identifier = group.Value;
if (!Common.IsStandardProperty(identifier)
!Common.IsStandardDirectory(identifier)
(null == ignoreModularizations || !ignoreModularizations.ShouldIgnoreModularization(identifier)))
{
sb.Insert(group.Index + group.Length, '.');
sb.Insert(group.Index + group.Length + 1, moduleGuid);
}
We
think the call to IsStandardProperty ought to automatically call
IsStandardDirectory but that may be a tooglobal
change.
Could
someone confirm whether this is a bug and whether I should raise a bug report
for it.
Regards
Neil
Neil
Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista -Error in SchedServiceConfig
Does the service control manager (I assume thats what SCM stands for) require admin access now? If it does, well need to tag the SchedServiceConfig CA as non-impersonated. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahar Shah Sent: Friday, August 11, 2006 5:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Vista -Error in SchedServiceConfig Hi, I am using wix 2.0 and trying to run my setup as a non admin on Vista Beta 2. I get the following error(access denied) while trying to install my windows service as a non admin - SchedServiceConfig: Error 0x80070005: failed to get handle to SCM How do I elevate my priviledges and install the service as localsystem ? Regards Bahar - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Support for Vista parental settings
No - but if you'd be interested in adding custom actions, I'm sure it would be a great addition to pubca. One interesting aspect about this for Vista is that most games will install to per-machine locations which will require admin privileges whereas most children accessing a computer should not be administrators (indeed if they are, then can't they just bypass the Parental settings?). So basically, I believe this type of a block would only be useful for games installed solely per-user. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Thursday, August 10, 2006 10:01 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Support for Vista parental settings Is there any resources for making Wix check for Parental settings on a Vista machine? So to prevent a user who cannot play M rated games from even installing the game? -- View this message in context: http://www.nabble.com/Support-for-Vista-parental-settings-tf2085871.html#a57 48363 Sent from the wix-users forum at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the order of components installation?
Self reg is strongly discouraged and ordering the components is not supported. WiX will create the rows in random order, MSI can execute them in whatever order it wants. The best way to handle your scenario is to pull all the registration from the dll files upfront using either tallow or heat. Otherwise, you'll need to solve this issue with custom actions (and there's a really good chance of introducing bugs when doing that). Derek -Original Message- From: Peter G. Sakhno [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 12:52 AM To: wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: Re: [WiX-users] What is the order of components installation? My product setup includes MSM with specific runtime environment. I want be sure that components from that MSM are installed first. More over, this MSM have self-registered COM components and they must be registered in predefined order. (I know that self-registration is very not recommended) I also want to know what defines order of components installation. Is it the order of appearance in MSI DB? If it is so, does the order of components in WiX code affect the order in the compiled DB? Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ Derek Cicerone wrote: It can't be controlled. Why does the order matter in your scenario? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter G. Sakhno Sent: Tuesday, August 08, 2006 4:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What is the order of components installation? In which order components are installed on the target system? How this order can be controlled? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ -- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=1216 42 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error LGHT0102 UtilExtension
Starting with the latest release, we have now exposed all strings which appear during installation in the extensions to localization. This means that you now need to specify the language of strings you would like to use when you run light. This can be done by providing -cultures:en-us on the light command line for English strings (I'm not aware of any other translations at this point). This is the first step towards ensuring that all the setup UI produced by WiX will be 100% localizable. The eventual goal is to translate all the strings from the extensions similarly to the effort for the WiX UI extension's strings. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Hecker Sent: Wednesday, August 09, 2006 2:27 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error LGHT0102 UtilExtension Having updated to 3.0.2002 I get some strange errors during linking. Can you tell me what to do? Microsoft (R) Windows Installer Xml Linker version 3.0.2002.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. E:\delivery\Dev\wix_public\src\ext\utilextension\wixlib\UtilExtension.wxs(15 9) : error LGHT0102 : The localization variable !(loc.msierrXmlFileFailedRead) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\utilextension\wixlib\UtilExtension.wxs(16 0) : error LGHT0102 : The localization variable !(loc.msierrXmlFileFailedOpen) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\utilextension\wixlib\UtilExtension.wxs(16 1) : error LGHT0102 : The localization variable !(loc.msierrXmlFileFailedSelect) is unknown. Please ensure the variable is defined. E:\delivery\Dev\wix_public\src\ext\utilextension\wixlib\UtilExtension.wxs(16 2) : error LGHT0102 : The localization variable !(loc.msierrXmlFileFailedSave) is unknown. Please ensure the variable is defined. -- View this message in context: http://www.nabble.com/Error-LGHT0102-UtilExtension-tf2077631.html#a5722503 Sent from the wix-users forum at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] check/change screen resolution
Thank goodness there is no way to do that right now! I would hate an installation that messed with my monitor resolution. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, August 09, 2006 9:43 AM To: roxana Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] check/change screen resolution roxana wrote: I'd like my MSI package to check the screen resolution for the logged-in The ScreenX and ScreenY properties are set by MSI. and to change it to 1280/1024. There's no built-in way to change the resolution. -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Request for Advice regarding File Organisation
That is why we encourage everyone to be very careful with component guids and when possible install to private locations. If you have several products which share some common files, you don't need merge modules to achieve that. Just ensure that you author those common components once and share the resulting wixobj/wixlib files amongst all the products during linking. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Williamson Sent: Wednesday, August 09, 2006 12:14 PM To: 'Dave Williamson'; [EMAIL PROTECTED]; 'Eric Fesh'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Request for Advice regarding File Organisation I just setup a test scenario proving to myself what Rob was saying and now my mind is completely blown. A file will be deleted from disk and registration information orphaned when that file is installed by 2 different installers (in the same directory) using 2 different component GUIDs. I'll be at the funny farm for a bit. Sorry for the confusion Eric. Dave Williamson Clear Sky Software 704.568.5544 sales 704.554.6300 support 704.943.0585 fax [EMAIL PROTECTED] www.clearskysoftware.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Williamson Sent: Wednesday, August 09, 2006 1:38 PM To: [EMAIL PROTECTED]; 'Eric Fesh'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Request for Advice regarding File Organisation Ok. I read the blog(s). If 2 unrelated installs install the same shared file (say comctl32.ocx) both the installs need to use the same GUID for the component that contains the comctl32.ocx file so that reference counting isn't thrown askew? And if that is the case then the comctl32.ocx author's merge module must be used by all parties so they keep the same GUID. WOW. That means any installation that I put together must use merge modules from the shared file authors. And in my little bit of experience in creating installers I have found that the merge modules have quirks and bugs that I can't wait on them to fix and must create my own merge module that installs the shared file. Correct me if I'm wrong (and please be wrong) ... because if I'm not then this isn't so much a technical decision as much a business decision ... the decision being do we use technology on which our productivity depends on the productivity of a 3rd party. Dave Williamson Clear Sky Software 704.568.5544 sales 704.554.6300 support 704.943.0585 fax [EMAIL PROTECTED] www.clearskysoftware.com -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 1:10 PM To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Request for Advice regarding File Organisation Importance: Low PS: It is for all these reasons that tallow does not generate GUIDs for you today. It is very, very difficult to do correctly in all cases. You may be able to create specialized solutions targeted for your needs... but a solution that works for everyone every time is a lot more involved (and, I believe, requires storing data in ways that are rather unnatural in a build environment). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Wednesday, August 09, 2006 10:03 AM To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Request for Advice regarding File Organisation It can be worse than that. If any of those Files are shared across different Products that can be installed on the user's machine, you can get into scenarios where the Files are incorrectly reference counted. I tried to capture much of the trickiness here: http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to
Re: [WiX-users] Possible MergeModule bug
The modulararization is correct. Please see http://windowssdk.msdn.microsoft.com/en-us/library/ms700896.aspx
In your final msm file, does the [WindowsFolder] value in the
Registry entry also get modularized? If not, that could be a bug.
Derek
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Wednesday, August 09, 2006 12:28 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Possible MergeModule bug
I
thinkwe have found a bug in WiX (both 2 and 3) concerning the
modularization of various field values when making a merge
module.As we understand it modularization means appending the
module GUID to things like component names to make them unique when actually
merged into an MSI. The WiX code also does this for properties in formatted
fields, presumably to avoid property name clashes with the parent
MSI (or any other merge modules). It doesn't modularize if the
property is a standard one, but this check fails to include standard
directories (which can also be used as properties).We found this bug when
attempting to set a registry value for an event source, e.g.:
Registry
Root=HKLM Key=SYSTEM\CurrentControlSet\Services\Eventlog\Application\Enterprise
Library Logging Name=EventMessageFile
Value=[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
Type=string /
In this
example[WindowsFolder] ended up as [WindowsFolder.moduleguid]. This of
course fails to resolve in the MSI resulting in an empty substitution
value.We checked the same thing using a VS merge module setup project and
it was fine. We traced through the WiX2 source and added the additional check for
a standard directory in OutputRow.cs (on or near line 231)and it now
worksok e.g.:
string
identifier = group.Value;
if (!Common.IsStandardProperty(identifier)
!Common.IsStandardDirectory(identifier)
(null == ignoreModularizations ||
!ignoreModularizations.ShouldIgnoreModularization(identifier)))
{
sb.Insert(group.Index + group.Length, '.');
sb.Insert(group.Index + group.Length + 1, moduleGuid);
}
We
think the call to IsStandardProperty ought to automatically call
IsStandardDirectory but that may be a tooglobal
change.
Could
someone confirm whether this is a bug and whether I should raise a bug report
for it.
Regards
Neil
Neil
Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible MergeModule bug
Sorry, I missed that part. It sounds like everything is working from your description. What leads you to believe the modularization is causing your setup to fail (and how is your setup failing)? From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 12:58 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug Derek I'm not sure I fully understand the question beyond what I wrote In this example [WindowsFolder] ended up as [WindowsFolder.moduleguid]. Is that what you where asking? Neil From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: 09 August 2006 20:48 To: Neil Sleightholm; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug The modulararization is correct. Please see http://windowssdk.msdn.microsoft.com/en-us/library/ms700896.aspx In your final msm file, does the [WindowsFolder] value in the Registry entry also get modularized? If not, that could be a bug. Derek - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible MergeModule bug
That is weird because if nothing else, the property should be resolved to the empty string if it doesnt exist. You should look for instances of WindowsFolder.guid in a verbose installation log to get a better idea of whats going on. Derek From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 1:17 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug I'm not sure I am making sense, the problem is that the Value part of the registry is set to [WindowsFolder.moduleguid] which doesn't resolve to a valid standard folder so it gets written to the registry as [WindowsFolder.moduleguid]. Neil From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: 09 August 2006 21:02 To: Neil Sleightholm; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug Sorry, I missed that part. It sounds like everything is working from your description. What leads you to believe the modularization is causing your setup to fail (and how is your setup failing)? From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 12:58 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug Derek I'm not sure I fully understand the question beyond what I wrote In this example [WindowsFolder] ended up as [WindowsFolder.moduleguid]. Is that what you where asking? Neil From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: 09 August 2006 20:48 To: Neil Sleightholm; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Possible MergeModule bug The modulararization is correct. Please see http://windowssdk.msdn.microsoft.com/en-us/library/ms700896.aspx In your final msm file, does the [WindowsFolder] value in the Registry entry also get modularized? If not, that could be a bug. Derek - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat and component identifier length
Thanks for the heads-up but that's not a crash - it's actually an ICE warning (you can tell because it says ICE03 in front). When WiX crashes, it will display a stack trace so that we can diagnose and fix the problem. The problem you've encountered is that MSI identifiers are supposed to be 72 characters long or less. When the modularization guid and added (this only happens in merge modules), it's much easier to go over this limit because you're effectively limited to ~36 characters (I forget exactly how many). Basically you can only use half of the 72 which are available. This brings up a common question - why is the limit 72 characters? The answer is that at the time MSI was first created, it was very important to keep the size of strings in the MSI down to a minimum since installations were being packed onto floppy disks. Nowadays, the limitation seems unnecessary but there are still two good reasons to follow them: 1. Keeping identifiers under 72 characters long ensures that they are relatively succinct. 2. If you ship a merge module to another group that does follow the 72-character limit and your merge module does not, you will break validation for them (which is not very nice). In practice, the Visual Studio group does this all the time and they've gotten a ton of negative feedback about the practice. So please be a good citizen when creating merge modules. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of neil corcoran Sent: Tuesday, August 08, 2006 12:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] heat and component identifier length Hi, I've been running heat on some directories to try to generate merge modules. Everything has been going well until one directory which has files with long file names gets processed by light. light.exe crashes because of this. The component tmp.wxs(3482) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: Component, Column: Component, Key(s): apifnsm_adjust_agc_module_params.html.E2904247_E12E_4BA8_9815_E506E96D53DA The component value is 74 characters long. I believe from reading on the platformsdk.msi usenet group that 72 is the limit. I can probably get my script to adjust the strings to avoid the problem, but you might like to know about the crash. Apart from that heat looks like a useful and powerful tool. Thanks. Neil - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat and component identifier length
Added back wix-users - please keep the broader alias on the discussion. Do you have a stack trace for the failure? If you'd like to send us a crash dump, you can open a bug on SourceForge and attach the dump to it. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of neil corcoran Sent: Tuesday, August 08, 2006 1:38 AM To: [EMAIL PROTECTED] Subject: Re: [WiX-users] heat and component identifier length zips are blocked. On 08/08/06, neil corcoran [EMAIL PROTECTED] wrote: Hi Derek, Thanks for the information. I'm going to parse the file and truncate the component information. However once I get the warning light does crash. I get an application pop up window telling me to terminate or go into the debugger: From the debugger this is what I get. Unhandled exception at 0x003c32d8 in light.exe: 0xC005: Access violation reading location 0x. I got it to generate a minidump and I have attached it. Does the fact I use .Net 1.1 and not 2.0 make a difference? N On 08/08/06, Derek Cicerone [EMAIL PROTECTED] wrote: Thanks for the heads-up but that's not a crash - it's actually an ICE warning (you can tell because it says ICE03 in front). When WiX crashes, it will display a stack trace so that we can diagnose and fix the problem. The problem you've encountered is that MSI identifiers are supposed to be 72 characters long or less. When the modularization guid and added (this only happens in merge modules), it's much easier to go over this limit because you're effectively limited to ~36 characters (I forget exactly how many). Basically you can only use half of the 72 which are available. This brings up a common question - why is the limit 72 characters? The answer is that at the time MSI was first created, it was very important to keep the size of strings in the MSI down to a minimum since installations were being packed onto floppy disks. Nowadays, the limitation seems unnecessary but there are still two good reasons to follow them: 1. Keeping identifiers under 72 characters long ensures that they are relatively succinct. 2. If you ship a merge module to another group that does follow the 72-character limit and your merge module does not, you will break validation for them (which is not very nice). In practice, the Visual Studio group does this all the time and they've gotten a ton of negative feedback about the practice. So please be a good citizen when creating merge modules. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of neil corcoran Sent: Tuesday, August 08, 2006 12:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] heat and component identifier length Hi, I've been running heat on some directories to try to generate merge modules. Everything has been going well until one directory which has files with long file names gets processed by light. light.exe crashes because of this. The component tmp.wxs(3482) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: Component, Column: Component, Key(s): apifnsm_adjust_agc_module_params.html.E2904247_E12E_4BA8_9815_E506E9 6D53DA The component value is 74 characters long. I believe from reading on the platformsdk.msi usenet group that 72 is the limit. I can probably get my script to adjust the strings to avoid the problem, but you might like to know about the crash. Apart from that heat looks like a useful and powerful tool. Thanks. Neil - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=12 1642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the order of components installation?
It can't be controlled. Why does the order matter in your scenario? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter G. Sakhno Sent: Tuesday, August 08, 2006 4:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What is the order of components installation? In which order components are installed on the target system? How this order can be controlled? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Multiple binary's
What will your custom action do? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Tuesday, August 08, 2006 10:48 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using Multiple binary's I have a .exe files that relies on a .dll file, both are in the binary fields. How to I allow make sure that both files are used in a custom action -- View this message in context: http://www.nabble.com/Using-Multiple-binary%27s-tf2074160.html#a5711564 Sent from the wix-users forum at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Page Count property...
Please give us an example of the authoring you are currently trying. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vijay Kalasani Sent: Monday, August 07, 2006 3:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting Page Count property... Hi, Can somebody please help with setting up the Page Count summary property? Here are the questions I have regarding setting this. What is the difference between Summary property and ordinary property? Would you set summary properties using Property table or some other table? When I set Page Count using property table, validation is failing because Page Count are two words. I tried setting it up using the Summary Information in the view menu, but there is no field for Page Count property in there. Ill really, truly, highly appreciate any help in this regard. Thanks, Vijay - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Page Count property...
Why are you using Orca? Everything inside an MSI can be set in your WiX authoring. What are you trying to set? Derek From: Vijay Kalasani [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:44 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... Did I answer your question though? Is this what you wanted to know? From: Vijay Kalasani [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:36 PM To: '[EMAIL PROTECTED]'; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] Setting Page Count property... In the property table using ORCA, I am trying to do the following and the validation fails. Now I am looking at some documentation that suggests setting properties using custom action (type 51). Page Count 200 Thanks, Vijay From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:30 PM To: 'Vijay Kalasani'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... Please give us an example of the authoring you are currently trying. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vijay Kalasani Sent: Monday, August 07, 2006 3:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting Page Count property... Hi, Can somebody please help with setting up the Page Count summary property? Here are the questions I have regarding setting this. What is the difference between Summary property and ordinary property? Would you set summary properties using Property table or some other table? When I set Page Count using property table, validation is failing because Page Count are two words. I tried setting it up using the Summary Information in the view menu, but there is no field for Page Count property in there. Ill really, truly, highly appreciate any help in this regard. Thanks, Vijay - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Page Count property...
In Orca, its View-SummaryInformation, the Schema option. In WiX, its the Package elements InstallerVersion attribute. In general, all SummaryInformation properties are set in WiX on the Package element. To learn more about this element and all the others, take a look at wix.chm. Derek From: Vijay Kalasani [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:52 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... I am fairly new to WiX authoring, so I am first using Orca and then applying dark to get the wxs output. I want my installer to work on systems with greater than or equal to Windows Installer 2.0 installed, where as it currently works only with Windows Installer 3.1, so trying to set Page Count to 200, but I have no idea where exactly (I mean to be more specific, which table in the Orca database) should I set it. Thanks, Vijay From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:47 PM To: 'Vijay Kalasani'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... Why are you using Orca? Everything inside an MSI can be set in your WiX authoring. What are you trying to set? Derek From: Vijay Kalasani [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:44 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... Did I answer your question though? Is this what you wanted to know? From: Vijay Kalasani [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:36 PM To: '[EMAIL PROTECTED]'; 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] Setting Page Count property... In the property table using ORCA, I am trying to do the following and the validation fails. Now I am looking at some documentation that suggests setting properties using custom action (type 51). Page Count 200 Thanks, Vijay From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 3:30 PM To: 'Vijay Kalasani'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Setting Page Count property... Please give us an example of the authoring you are currently trying. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vijay Kalasani Sent: Monday, August 07, 2006 3:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting Page Count property... Hi, Can somebody please help with setting up the Page Count summary property? Here are the questions I have regarding setting this. What is the difference between Summary property and ordinary property? Would you set summary properties using Property table or some other table? When I set Page Count using property table, validation is failing because Page Count are two words. I tried setting it up using the Summary Information in the view menu, but there is no field for Page Count property in there. Ill really, truly, highly appreciate any help in this regard. Thanks, Vijay - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-language msi
Title: RE: [WiX-users] Multi-language msi Ah ok. Im not certain, but I believe Ive heard two things about that method: Its not officially supported by the MSI team (they discourage people from using it). Im not sure why though. I believe you cannot create a patch to modify the strings which come from the transform because the transform is always applied last. This would be a geo-political risk if one of the strings in your setup was found to be offensive. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lemire Sent: Sunday, August 06, 2006 8:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-language msi To make multi-language msi's right now you: 1)Make a normal msi in your primary lanuage (english in my case) 2)Make normal msi's in the other languages. 3)Run MsiTran once each on your primary language and each of your secondary ones. This builds a transform (delta) between the primary and each secondary. 4)Stuff the MsiTran generated deltas into the primary msi 5)Set the SummaryInfo to include all the languages it now includes then when msiexec runs it first compares the current os/user setting with the options in the SummaryInfo and if it matches one it applies that ones transfom before showing the UI. -Original Message- From: Derek Cicerone [mailto:[EMAIL PROTECTED]] Sent: Sat 8/5/2006 5:38 PM To: John Lemire; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Multi-language msi What is the MsiTran SummaryInfo mechanism? _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Lemire Sent: Saturday, August 05, 2006 5:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi-language msi Hi, We are currently using the MsiTran / SummaryInfo mechanism to build a single msi for English, French, German, and Italian. We're being asked to add Japanese, Chinese, and Korean and I was thinking if wix would make this easier maybe now would be a good time to invest resources in porting to wix. However the wix localization info I've read so far seems to point to separate installers for each language. Are there any examples of how to author a multi-language msi using the wix syntax/tool set? thanks -john - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-language msi
Right, using the transforms in that way is not discouraged (that's their localization story from what I know); it's just that the data coming from the transform is then unpatchable because the transforms are always applied last. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEÁK JAHN, Gábor Sent: Sunday, August 06, 2006 1:28 PM To: WiX-users Subject: [WiX-users] Multi-language msi On Sun, 6 Aug 2006 11:32:20 -0700, Derek Cicerone wrote: Derek, Its not officially supported by the MSI team (they discourage people from using it). Im not sure why though. Actually, as far as I know, it's naming the transforms according to the codepage numbers (what would make the selection of the language automatic) is discouraged, not the use of the transforms themselves like this: msiexec /i SampleMulti.msi TRANSFORMS=fr-fr.mst Bye, Gabor --- DEAK JAHN, Gabor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-language msi
Title: Multi-language msi What is the MsiTran SummaryInfo mechanism? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lemire Sent: Saturday, August 05, 2006 5:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi-language msi Hi, We are currently using the MsiTran / SummaryInfo mechanism to build a single msi for English, French, German, and Italian. We're being asked to add Japanese, Chinese, and Korean and I was thinking if wix would make this easier maybe now would be a good time to invest resources in porting to wix. However the wix localization info I've read so far seems to point to separate installers for each language. Are there any examples of how to author a multi-language msi using the wix syntax/tool set? thanks -john - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: Re: MessageQueue PubCA
Justin or Bob would have to answer that question - I'm not sure what Votive installs these days :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david adams Sent: Friday, August 04, 2006 2:07 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Re: MessageQueue PubCA I downloaded the 2.0.4421.0 binaries and retrieved the pubca.wixlib pcaext.dll files. The install generated the MSI. Thanks Derek. BTW. Should the wixlib dll have been installed with the Votive install? David Adams MSN MessengerID: [EMAIL PROTECTED] From: david adams [EMAIL PROTECTED] To: [EMAIL PROTECTED], wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MessageQueue PubCA Date: Fri, 04 Aug 2006 20:42:59 + MIME-Version: 1.0 X-Originating-IP: [12.6.40.2] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by bay0-mc6-f7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 4 Aug 2006 13:43:12 -0700 Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93])by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid 2B8AC12F35; Fri, 4 Aug 2006 13:43:12 -0700 (PDT) Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92]helo=mail.sourceforge.net)by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)id 1G96Vh-Fe-OYfor wix-users@lists.sourceforge.net; Fri, 04 Aug 2006 13:43:09 -0700 Received: from bay0-omc1-s8.bay0.hotmail.com ([65.54.246.80])by mail.sourceforge.net with esmtp (Exim 4.44) id 1G96Vh-0008Af-9Efor wix-users@lists.sourceforge.net; Fri, 04 Aug 2006 13:43:09 -0700 Received: from hotmail.com ([64.4.61.24]) by bay0-omc1-s8.bay0.hotmail.comwith Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 13:43:04 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;Fri, 4 Aug 2006 13:43:03 -0700 Received: from 64.4.61.200 by by102fd.bay102.hotmail.msn.com with HTTP;Fri, 04 Aug 2006 20:42:59 GMT X-Message-Info: txF49lGdW41un/J1DbPfyfIVh5GhNQ0qo3EKQvRVlr8= X-OriginalArrivalTime: 04 Aug 2006 20:43:03.0602 (UTC)FILETIME=[95040120:01C6B806] X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems tohttp://sf.net/tracker/?func=addgroup_id=1atid=210.5 FROM_ENDS_IN_NUMS From: ends in numbers0.0 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-BeenThere: wix-users@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: General discussion for Windows Installer XML toolset.wix-users.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:wix-users- [EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=wix-users List-Post: mailto:wix-users@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:wix-users- [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] It appears that Fredrik had already answered the question. When I looked on the SourceForge Wix-Users archive, I found the following: **Cliff Notes version from Fredrik's email candle queues.wxs -ext Microsoft.Tools.WindowsInstallerXml.PcaCompiler,pcaext light queues.wixobj %WIX_HOME%\ca\pubca.wixlib -out queues.msi -ext Microsoft.Tools.WindowsInstallerXml.PcaCompiler,pcaext (%WIX_HOME% is the directory where you have WiX installed on you system.) *** When I took the steps, it appears that I am missing the pcaext.dll for the reference and the pubca.wixlib. Are these not available in the bin directory like wixca, etc.? David Adams MSN MessengerID: [EMAIL PROTECTED] From: Derek Cicerone [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: 'david adams' [EMAIL PROTECTED],wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MessageQueue PubCA Date: Fri, 4 Aug 2006 12:32:59 -0700 MIME-Version: 1.0 Received: from winisp-fe1.winisp.net ([192.197.157.82]) by bay0-mc5-f6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 4 Aug 2006 12:33:00 -0700 Received: from derekclap ([131.107.0.89]) by winisp-fe1.winisp.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 12:32:59 -0700 X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlKtU9j2Z7TuGo= X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca3+2B7nwCLXwMGSka2Q4fxhiOZUAAAQKBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2922 Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 04 Aug 2006 19:32:59.0464 (UTC) FILETIME=[CB277480:01C6B7FC] You need to pass in the pubca extension. For v2, it should look something like this: -ext assembly, class (or maybe its class, assembly - I don't remember - it was always too verbose for me :) (I'm not sure of the specifics for pubca
Re: [WiX-users] Calling custom actions in Merge Modules
You should not be referencing a custom action from a merge module in a main installation. Who wrote the custom action? If its yours then you should use wixlib files instead of merge modules. If its not yours, whoever did write it should have made it a table-driven custom action. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Cullen Sent: Thursday, August 03, 2006 7:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Calling custom actions in Merge Modules Hi I have a merge module that I created including all the files for a product, including the exe. I now want to launch that exe at the end of my main wix project. I have tried using a custom action which was created in the merge module as below Publish Event='DoAction' Value=LaunchFile.8757FF80_A4ED_45C0_8672_55821E0CB48F(NOT Installed) AND (LAUNCHPRODUCT = 1)/Publish But light complains about not knowing what this reference is. I have added this by hand using Orca and it works so how can I get Wix to understand it. Cheers Stuart Cullen Confidentiality: This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Performance issues
Title: Performance issues What are the install times like if you disable system restore? Apparently MSI installations take a large up-front hit while loading on system restore and disabling it (assuming you dont use it), can speed things up quite a bit. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley Sent: Thursday, August 03, 2006 8:26 AM To: '[EMAIL PROTECTED]'; Simon Topley; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Performance issues Preaching to the choir there, we were using an old shonky none msi version of installshield. It clearly did less work, it's just hard explaining that to users/support staff, when all they see is the end result. With the previous version the guy who wrote it put a million workarounds in there to allow our support staff to install multiple copies of the same version of the product... Trying to explain that this is bad practice just gets me insults. Oh well, all is well now, the performance figures have calmed people down a little now that they realize they are complaining about nothing. Cheers Rob. From: Rob Mensching [mailto:[EMAIL PROTECTED]] Sent: 03 August 2006 16:17 To: 'Simon Topley'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Performance issues When you say you've replaced InstallShield with the WiX toolset, what version of InstallShield did you replace? I ask because the non-MSI versions of InstallShield used a scripting engine to do the install. That engine (as I've been told) doesn't do nearly the same amount of integrity checking that the Windows Installer does. For example, the Windows Installer maintains a rollback script of all the files that were replaced during the installation. Thus, if the user cancels, everything gets put back the way it was. That adds overhead that most installation technologies don't implement (and one of the reasons I cringe every time I see another product released on those engines). Now, if you were using InstallShield for Windows Installer and the package you created with the WiX toolset was slower... well, then the WiX toolset probably has a bug. smile/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley Sent: Thursday, August 03, 2006 1:12 AM To: 'wix-users@lists.sourceforge.net' Subject: [WiX-users] Performance issues Good morning to the Brotherhood/Sisterhood, I'm sure this is a problem others have encounted. I have now replace our suite of installsheild products with spanky new WIX versions. I have managed to elimitnate a large amount of redundant code (previous installers copied large amounts of file that were never used). Most of the installers are now half the size in compressed form. Dispite this the installation process now takes longer (so I'm told, I intend to run some performance tests later today). Is there a standard explaination for this that I can give to people (i.e. talk to city hall) I am playing with the idea of having internal versions (products that will only be used by testers and support staff) as uncompressed in the hope that most of the time is being spent extracting files. Simon The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixUI_Minimal without license agreement
Im surprised Bob hasnt responded to this yet J Im not sure how it works in WiX 2.0, but in 3.0, doing something like this should be very easy since we moved all the dialog flow into one file apiece for each of the dialog packs (mondo, minimal, etc). You can just take the single file for a pack that is closest to what you want, copy it to your setup sources, tweak it as necessary, then link call light with -ext WixUIExtension like normal and be done. You dont need to set various properties, re-compile the library or anything like that. It should be exceedingly simple for 3.0. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Beaudet Sent: Thursday, August 03, 2006 11:51 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WixUI_Minimal without license agreement Scott, I have the same concern except that I'm referencing the WixUI_FeatureTree. I should say that I'm still working my way through the tutorial so the answer may be in there but I'd sure like to hit the easy button and find a way to make the license screen disappear. My installer is for our field techs who can't agree on anything much less whether or not to accept some licensing terms. ;) Brian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Thursday, August 03, 2006 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WixUI_Minimal without license agreement I want to use the Minimal wixui because I want the user to be able to just click next and have the install go, but I dont want eula in it. Is there any way to use the regular welcomeDlg in place of the WelcomeEulaDlg. I get an error 2803 when I click the next button when I tried just changing the dialogRef. What am I missing? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Thursday, August 03, 2006 10:57 AM To: Simon Porter Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] installing fonts via msi Simon Porter wrote: I'm trying to put together a simple msi that will install a bunch of fontsthat I can then deploy using active directory. The problem I'm gettingthough is when I run the setup program it complains that it couldn'tregister the fonts and to check I have sufficient permissions. I amcurrently logged on as the local admin and domain admin. The log contains this message too: Cannot get the font title for LT_50255.ttf. The doc is kinda ambiguous but it does say: Font name. It is recommended that you leave this column null for TrueType Fonts and TrueType Collections because the installer can register the font after reading the correct font title from the font file. If the font name is entered, it must be identical to font title from the font file. You must specify a title for fonts that do not have embedded names, such as .fon files. So not being able to read the font title is probably a genuine error condition. -- sig://boBhttp://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
Title: RE: [WiX-users] rfc: Package element changes Thanks for the feedback Jeremy. I think thats a valid concern, so the warning idea is definitely out. So it sounds like the decision is basically between using * or lots of question marks. If people feel that the star syntax is clearly better, then I agree its a good idea. But if theres no clear consensus on it being a win then we might just leave it alone since everyone is already familiar with the current syntax. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Farrell Sent: Thursday, August 03, 2006 3:52 PM To: WiX-users Subject: Re: [WiX-users] rfc: Package element changes From: Bob Arnson Sent: Wed 8/2/2006 8:44 AM Derek Cicerone wrote: I've done some more thinking about this. I think Rob's main objection with making Product/@Id optional was that someone might accidentally forget to specify it. However, what if we displayed a warning to the user whenever they omitted the Property/@Id attribute informing them that doing so is non-standard and would result in generating a new ProductCode for each build - thus making it impossible to do anything other than major upgrades. Why should that be a warning? I agree totally. As far as I'm concerned this is a useful feature. I want to be sure the ProductCode changes every time, to ensure that it is impossible to do anything other than major upgrades. This may be an unusual requirement, but it's a valid one and I shouldn't like to see a warning for it. I'm sure mine isn't the only environment where warnings are forbidden in production builds. If this were to generate a warning, the warning ought to be very specific to this case, and it should be possible to suppress this one warning from the command line. Even that's messy though - I'd far rather there not be a warning for this. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
That's correct - we generate the entire guid every time. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEÁK JAHN, Gábor Sent: Wednesday, August 02, 2006 1:14 AM To: WiX-users Subject: [WiX-users] rfc: Package element changes On Tue, 1 Aug 2006 16:44:39 -0400, Dave Williamson wrote: Dave, I assume that 12345678----??5?? makes up all the GUID parts except for 12345678 and 5. Somebody correct me if I'm wrong but as far as I know GUIDs are always created complete. There is no such thing as partial GUID creation. A GUID is only then can be guaranteed unique if it is generated fresh in every respect. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
I've done some more thinking about this. I think Rob's main objection with making Product/@Id optional was that someone might accidentally forget to specify it. However, what if we displayed a warning to the user whenever they omitted the Property/@Id attribute informing them that doing so is non-standard and would result in generating a new ProductCode for each build - thus making it impossible to do anything other than major upgrades. I think would be ideal because it: 1. Keeps the schema consistent - omitting the Id attribute generates an identifier/guid. 2. Warns users of the specific dangers of generating a ProductCode every time (so it provides more user education than the current tools). 3. Doesn't really prevent a user from getting back to a good state if they really did want to specify a ProductCode since they can always go back and hard-code in a ProductCode when they discover that building patches using images with different ProductCodes does not work. I'm also thinking of adding a similar warning if a user sets the Package/@Id attribute for a Product because that would produce identical PackageCodes for multiple msi files, which is against MSI recommendations and may result in undesirable behavior in some scenarios as well. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Wednesday, August 02, 2006 1:24 AM To: 'DEÁK JAHN, Gábor'; 'WiX-users' Subject: Re: [WiX-users] rfc: Package element changes That's correct - we generate the entire guid every time. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEÁK JAHN, Gábor Sent: Wednesday, August 02, 2006 1:14 AM To: WiX-users Subject: [WiX-users] rfc: Package element changes On Tue, 1 Aug 2006 16:44:39 -0400, Dave Williamson wrote: Dave, I assume that 12345678----??5?? makes up all the GUID parts except for 12345678 and 5. Somebody correct me if I'm wrong but as far as I know GUIDs are always created complete. There is no such thing as partial GUID creation. A GUID is only then can be guaranteed unique if it is generated fresh in every respect. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
Hmm, that's a very good point. I'm just trying to address Rob's concern that a developer wouldn't understand what it means to generate the guid. Honestly, I'd be more worried about them copying a setup with a guid and failing to modify it (thus introducing collisions for users). It almost argues for us to always omit the guid in our examples in which case we'd then have to somehow educate the user that they should set a guid if they copied one of our examples. Now I'm all confused :) Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, August 02, 2006 8:44 AM To: [EMAIL PROTECTED] Cc: 'DEÁK JAHN Gábor'; 'Rob Mensching'; 'WiX-users' Subject: Re: [WiX-users] rfc: Package element changes Derek Cicerone wrote: I've done some more thinking about this. I think Rob's main objection with making Product/@Id optional was that someone might accidentally forget to specify it. However, what if we displayed a warning to the user whenever they omitted the Property/@Id attribute informing them that doing so is non-standard and would result in generating a new ProductCode for each build - thus making it impossible to do anything other than major upgrades. Why should that be a warning? -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Turning off all sub-features
Be wary of level 0 for features - you can get into scenarios where it's difficult to bring the features back to life :) Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Beaudet Sent: Wednesday, August 02, 2006 2:01 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Turning off all sub-features Got it! Property Id=INSTALLLEVEL Value=1 / A value of 1 works for me because all of my subfeatures are set to 2. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Beaudet Sent: Wednesday, August 02, 2006 4:43 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Turning off all sub-features I'll look a little more closely in that direction. I initially set the subfeatures level to Level = 0 and that just kept them from displaying. Brian -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 4:41 PM To: Brian Beaudet; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Turning off all sub-features Take a look at the Level attribute on the Feature element (and how it pertains to the Feature table). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Beaudet Sent: Wednesday, August 02, 2006 1:39 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Turning off all sub-features I've got an installer I'm working on where the main feature is required. All of the subfeatures are not required however. Since I'm still new at this, I'm trying to actually set the subfeatures so they do not install by default. I want the user to select which ones to install. What combination of attributes do I need to set in each subfeatures Feature element? Thanks, Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExeCommand custom action
What does the exe do to the xml file? WiX has custom actions which support modifying xml files during setup. They support rollback and install nothing to the target machine. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Tuesday, August 01, 2006 2:21 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ExeCommand custom action Hi all, I've got an ExeCommand custom action (like this): CustomAction Id=LaunchConfig FileKey=$(var.projectname).exe ExeCommand=quot;[INSTALLDIR]$(var.projectname ).xmlquot; Return=asyncNoWait/ How can I make it execute with a specific working directory? Thanks, -- Shmarya --- [EMAIL PROTECTED] - http://shmarya.net NUnit rocks! http://nunit.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
Just a note: the Product/@Id should almost never be auto-generated because that forces major upgrades every time. But why would * be better than ----?? Thanks, Derek From: Rob Mensching [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 01, 2006 8:37 AM To: 'Bob Arnson'; [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] rfc: Package element changes I have no opinion on that. Anybody else care? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Monday, July 31, 2006 3:39 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] rfc: Package element changes Derek Cicerone wrote: That is an excellent point what if we keep the ???... syntax just for Product/@Id in that case and go with the recommendations below for everything else? Any chance of a different syntax? @Id=* maybe, keeping with the wildcard scheme? -- sig://boBhttp://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] custom action to write a reg value
Why? Windows Installer only writes a value if its successful (otherwise it rolls back). Are you trying to determine if an install is successful or when its successful? Derek From: Don Tasanasanta [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:26 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value I would like to write the reg value after installfinalize when Im sure that the install has been successful. __ Don Tasanasanta VIACK Corporation 425-605-7423 From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:09 PM To: Don Tasanasanta; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value Just write the registry key as part of the normal installation why would that require a custom action? Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta Sent: Tuesday, August 01, 2006 2:57 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] custom action to write a reg value Im looking to create a reg value to indicate that the install was successful. And ideas? __ Don Tasanasanta VIACK Corporation 425-605-7423 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] custom action to write a reg value
Could you explain your scenario a bit more? Why would it be important to know when an install has completed? Is this for a bootstraper? Will there be some other program continuously pinging to find out when the install is complete? Thanks, Derek From: Don Tasanasanta [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:46 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value Yes, that is exactly what Im trying to do is there another way to go about this? __ Don Tasanasanta VIACK Corporation 425-605-7423 From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:29 PM To: Don Tasanasanta; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value Why? Windows Installer only writes a value if its successful (otherwise it rolls back). Are you trying to determine if an install is successful or when its successful? Derek From: Don Tasanasanta [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:26 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value I would like to write the reg value after installfinalize when Im sure that the install has been successful. __ Don Tasanasanta VIACK Corporation 425-605-7423 From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:09 PM To: Don Tasanasanta; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] custom action to write a reg value Just write the registry key as part of the normal installation why would that require a custom action? Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta Sent: Tuesday, August 01, 2006 2:57 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] custom action to write a reg value Im looking to create a reg value to indicate that the install was successful. And ideas? __ Don Tasanasanta VIACK Corporation 425-605-7423 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: Package element changes
Weve recently discovered that the way WiX creates merge modules is a little bit incorrect. Every merge module has a unique guid which is used to modularize all the entries in the merge module (WiX does this properly). However, that guid is also supposed to be used as the package code (summary information property 9) WiX doesnt do this properly. Right now, WiX has an independent module guid and package code. The package code is most likely usually generated using the ??... syntax for Package/@Id. Id like to propose some changes to bring WiX schema support for merge modules closer to how the merge modules should be represented (and some related changes). Deprecate Module/@Guid and disallow the ... syntax for Package/@Id under a Module element. This removes the notion of a separate module guid and package code, while forcing a user to fill in the package code (which is also the guid used for modularization). Deprecate Package/@Compressed under a Module element. Merge modules are always compressed, so supporting this attribute for merge modules actually has no effect, therefore it should likely be removed. 3. Another, non merge module related change Id like to propose is deprecating the ???... syntax for Package/@Id and Product/@Id. Instead, in cases where a guid should be generated, the attribute should just be omitted. This will match how the Registry elements handle auto-generation of their identifiers when the Id attribute is missing. This change would make the schema more consistent and succinct (which I think is always a good thing J). I look forward to your feedback. Thanks, Derek - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: Package element changes
That is an excellent point what if we keep the ???... syntax just for Product/@Id in that case and go with the recommendations below for everything else? Thanks, Derek From: Rob Mensching [mailto:[EMAIL PROTECTED]] Sent: Monday, July 31, 2006 8:32 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] rfc: Package element changes Product/@Id is a kinda' scary thing to make optional. What if someone just accidentally forgets to add one? Or what if someone copies an example that didn't add it? The developer will end up with a product that is very difficult to track. I appreciate the consistency proposed but I'm concerned about the potential for accidents. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Sunday, July 30, 2006 23:16 To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: Package element changes Weve recently discovered that the way WiX creates merge modules is a little bit incorrect. Every merge module has a unique guid which is used to modularize all the entries in the merge module (WiX does this properly). However, that guid is also supposed to be used as the package code (summary information property 9) WiX doesnt do this properly. Right now, WiX has an independent module guid and package code. The package code is most likely usually generated using the ??... syntax for Package/@Id. Id like to propose some changes to bring WiX schema support for merge modules closer to how the merge modules should be represented (and some related changes). Deprecate Module/@Guid and disallow the ... syntax for Package/@Id under a Module element. This removes the notion of a separate module guid and package code, while forcing a user to fill in the package code (which is also the guid used for modularization). Deprecate Package/@Compressed under a Module element. Merge modules are always compressed, so supporting this attribute for merge modules actually has no effect, therefore it should likely be removed. 3. Another, non merge module related change Id like to propose is deprecating the ???... syntax for Package/@Id and Product/@Id. Instead, in cases where a guid should be generated, the attribute should just be omitted. This will match how the Registry elements handle auto-generation of their identifiers when the Id attribute is missing. This change would make the schema more consistent and succinct (which I think is always a good thing J). I look forward to your feedback. Thanks, Derek - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to set one File for two Components
Please note that CopyFile and RemoveFile are dangerous from a security perspective because they don't provide a simple patching solution. I would advise against that method. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Hamflett Sent: Monday, July 31, 2006 12:54 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to set one File for two Components You could use CopyFile and RemoveFile elements, but it's much easier to just include the file twice. I'd only really consider this option if the file was huge. Rob Derek Cicerone wrote: There's no better way - that's it. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter G. Sakhno Sent: Friday, July 28, 2006 6:44 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to set one File for two Components Hello. I have two Components installed into different directories. And these Components include the same file, so the same file appears in two different directories. I have authored an MSM with two Component elements under different Directory elements. Those Component elements include File elements with different Id's pointing to the same source file. But I do not like this way. The file is twice copied into the database. How can do it in another, better way? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MergeModules vs. WixLib
You can probably just pretty print the
wixlib files and inspect them directly its just xml (unless you use the bf option
to bind files into it in which case its a cabinet file with xml appended to
the end).
Derek
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein
Sent: Monday, July 31, 2006 10:03
AM
To: [EMAIL PROTECTED]
Cc:
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MergeModules
vs. WixLib
Hi Rob,
Firstly, I've now completed my migrate to .wixlib (thanks to a lot of
multi-file/regex/find-replace ;)) and am very happy with the results... for a
number of reasons:
0. You're absolutely right, wixlibs are what I needed all along... I think I was
just mislead by what I'd previously heard about wixlibs in v2...
1. They are much faster building...
2. They are much smaller once built...
3. Loose coupling ('soft' linking) is extremely powerful
About the viewer tool I often like to look into the modules I create and
verify things without having to build the entire MSI... Now I have to build an
MSI inorder to inspect it... It lengthens my turnaround cycle...
All in all, I'm very pleased with .wixlibs...
On 7/31/06, Rob Mensching [EMAIL PROTECTED]
wrote:
0. It is less about
preferable and more about .wixlibs actually are designed to
solve the problems it appears you are working on. Merge Modules are not
intended to be used the way you are trying to use them.
1. Not much. But in WiX v2, there
really isn't much to .wixlibs. They are purely a collection of .wixobj
files. Basically a more convenient way of moving around collections of
compiled source code. In WiX v2, use .wixlibs just like you would
.wixobjs. In WiX v3, .wixlibs get a set of features that help them
compete directly with Merge Modules (such that I really don't think you'll need
Merge Modules unless you are distributing setup to someone that doesn't use the
WiX toolset).
2. No. Is there a tool for
inspecting .lib files? Why do you need such a tool?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Shmarya Rubenstein
Sent: Monday, July 31, 2006 01:04
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
MergeModules vs. WixLib
Derek just pretty much answered in one of the other
threads on this issue:
Merge modules are processed by
mergemod.dll (a special dll from the Windows SDK), so WiX has very little
interaction with the contents of merge modules being put in your MSI
file. This is one of the reasons we advise against using merge modules
they are a black box that you either take or leave in their entirety.
Even if you build merge modules for an external customer, you can also create
wixlibs (or just straight wixobjs) from the authoring in the merge module for
internal usage. Basically, you should only use merge modules from
external groups and only ship merge modules to external customers. Merge
modules are good for sharing across different organizations because you might
not both be using WiX (or the same version of WiX), but within an organization,
the wixlib files are the way to go.
Ok, so I understand that wixlibs are preferrable
That leaves 2 major questions:
1. Where is the documentation for libs?
2. Is there a tool for inspecting wixlibs similar to ORCA? If not, is this
something planned for the future?
--
Shmarya
---
[EMAIL PROTECTED]
- http://shmarya.net
NUnit rocks! http://nunit.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Require License Agreement Dialog (no silent setups)
I've been thinking about adding a warning to the LaunchConditions parsing code in the compiler. In almost every case, you should add Installed OR to the beginning to ensure it only runs during initial install. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Robbins Sent: Monday, July 31, 2006 4:07 PM To: WIX-Users Mailing List Subject: [WiX-users] Require License Agreement Dialog (no silent setups) Hello, After an hour of Googling, I can't see how to disallow silent installs. The default WiX installs allow you to specify \q to MSIEXEC.EXE and you get a silent install. However, that allows you to skip checking the license agreement option, which my client doesn't like. What's the WiX magic I need to do to not allow my install to be run in silent mode. I tried a condition of UILevel=5, which worked for installs, but would never allow an uninstall (thank goodness for MSIZAP!). John Wintellect - Know How http://www.wintellect.com 877-968-5528 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
here. Perhaps this could all be handled within the context of the msi. Anyway. Thanks for reading this far if you made it and thanks for the advice. Hope to keep the discussion going. Rick From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:52 PM To: Rick Glos; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller First off, welcome! Theres some information that can help guide our answers for you: When does your product ship? What is your product (just curious)? More specifically, what does it interact with (COM, services, MSMQ, IIS, SQL, etc)? How does the C# installer install things? Does it use the Installer classes or manually set registry keys and copy files? To answer some of your questions: Im not sure how the upgrade story would work it all depends on how you currently handle uninstall and upgrade scenarios. Is there something youd need to run to perform an uninstall on the previous version (would it be managed code)? Once you get all customers on an MSI deployed setup it should be easy to have them all use the same technology after that point. Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Glos Sent: Thursday, July 27, 2006 12:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller Hello, Ive spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks updating our installer (we have a custom C# installer). I can see our new customers instead using a new .msi for later versions (5.5, 6.0, etc). What do I do about our existing customers when they wish to upgrade? Theyve never installed originally with a Windows Installer. How do I get them on the same track? Thanks for any advice, Rick Glos - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
I see. How about just putting the component into Feature1 so that it will run when Feature1 is installed locally? Derek From: Scott Sam [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 5:12 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions I need to write out to a config file what features are being installed, so that the program that update/creates the database knows what database to create/update if any at all. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 6:12 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions What are you trying to do overall? Using feature conditions in a components condition is a little awkward usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: Component Id=DbInstallationDirectoryService Guid=A4B5E633-D715-4e8e-8C4A-E58D1BAFFBAE XmlFile Action="" ElementPath=//DBInstallation/FeaturesInstalled File=[DBCREATION]dbinstallation.xml Id=dbInstallationConfig20 Name=Feature Sequence=19 Value=Feat1 / Condition![CDATA[(Feature1 = 3) AND (!Feature1 = 3)]]/Condition /Component From my understanding, it should right out FeatureFeat1/Feature if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Long path name to COM server
The very latest WiX 3.0 release fixes this, enjoy! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey T Sent: Friday, July 28, 2006 4:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Long path name to COM server Hello, all! I have following situation: when I use Classelement to install Class for my COM server, I use Server attribute to set path to my COM server in registry (under InProcServer32 key). I use unadvertised mode (i. e. Advertise=no) for Classelement. The problem is that WIX writes this in registry table to the Value column in Registry table in following manner: [!comserver.dll] where comserver.dll is the Id of my COM server in File table. When installation finishes, path to my COM server is in short form. But I want to get it in long form. I know that if WIX will write it to Registry table in [#comserver.dll] form, then I will get long path after installation. Is it possible somehow to do this? Thank you in advance. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ProgramMenuFolder and validation error
This question has been coming up often. Note that ALLUSERS is completely uppercase so a user can change your installation to be per-user via the command line or several other methods. This means that you need the HKCU key to ensure proper repair operation (since a shortcut is not a valid keypath). Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dangle123 ... Sent: Tuesday, July 25, 2006 3:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ProgramMenuFolder and validation error When defining a component with ProgramMenuFolder as the directory path for a menu item, an ICE38validation error occur indicating that the component installs to user profile and that it must use a reg key under HKCU as its KeyPaths. Since I have the property ALLUSERS=1 set doesn't this indicate that the package installs per machine and not per user? So, why do I still get this validation error? Is this an installer validation bug? Thanks, -- Leo - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
We already have a tool to convert from WiX 2.0 to WiX 3.0. Its called wixcop. I assume you were referring to converting the source code itself (not the wixlib files) since just having the libraries without source is a bit dangerous. We do not have a tool to convert from WiX 3.0 back down to 2.0. Once the time comes to ask everyone to switch from 2.0 to 3.0, the core tools should be extremely stable, and the decision to move to 3.0 should only be one way. It would be very painful to go from 2 - 3 and back to 2 since there are some concepts in 3.0 that will not translate back down to 2.0 sources (like not having short file names). The reason I assert that 3.0 core tools will be very stable by the time 3.0 is labeled stable is because Ive always set out to stabilize the core tools well ahead of the toolset as a whole. In fact, the WiX 2.0 custom actions still arent locked down whereas the core tools have been for almost a year. Thank you for this feedback, its good to see that no groups are intending to mix 2.0 and 3.0 in their organization so far. However, after much discussion over the issue, I think the hope is that WiX 3.0 will be the last time we touch the wixobj, wixlib, and wixout file formats. Were trying to make them generic enough that anything further can be supported via a new table instead of modifying the format itself. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Saturday, July 29, 2006 5:47 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files If there are utilities to bring a pure WiX 2 code base up to a pure WiX 3 code base then breaking compatibility is fine by me. We do not intend to mix the two. The utilities would eliminate costly manual conversion time and provide a quick way for the entire WiX 2 code library to be converted. So we could keep our existing WiX 2 library (just in case :)) then put upa parallel WiX 3 library and just make the switch wholesale and if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note however we won't address the switch to WiX 3 until it becomes production ready. So on that note ... to help encourage the use of (and thus bug fixing of) WiX 3 to get it ready for production the conversion utilities need to convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) convert from WiX 3 to WiX 2. You will need to weigh the cost of conversion versus backwards compatibility ... I'm clueless on just how would you automate a conversion. Dave Williamson Clear Sky Software 704.568.5544 sales 704.554.6300 support 704.943.0585 fax [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Wednesday, July 26, 2006 6:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name
Re: [WiX-users] SelfRegCost on windows 2003 Server
Title: SelfRegCost on windows 2003 Server Its probably a missing dependency. It might be easier to stop using self reg by running tallow (wix v2) or heat (v3) against the self-reg dll to collect its registry keys. J Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley Sent: Thursday, July 27, 2006 3:24 AM To: 'wix-users@lists.sourceforge.net' Subject: [WiX-users] SelfRegCost on windows 2003 Server Greetings all, I'm not sure if this is a bug with WIX, or if the problem is this end. We have a load of self registering dll's, I know, don't start. These babies work fine when installed on XP, the registry entries all appear fine etc. etc. When I run the same installer on 2003 server standard edition the installer fails with a failed to register blah blah blah.dll error. Our old Installshield versions manage to self register on 2003 fine... Any offers? Cheers ta, Simon. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ISAPI Filter installation hangs IIS
To resolve the localization issue: I think youll need to pass cultures:en-us to light to load the English resources for the extension. This change was just made in the last release. Please note that the custom action code in WiX 3.0 is identical to what can be found in 2.0. We still havent locked down on 2.0 and forked 3.0 for the custom actions (everything else has forked). Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carter Sent: Friday, July 28, 2006 10:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ISAPI Filter installation hangs IIS Has anyone encountered this? I'm trying to install a single sign on isapi filter, and at the very end of the installation when it says install to metabase or something like that, the thing hangs and eventually all resources are eaten up causing the need for a reboot. Is this what was fixed in 3.0.1926.0 ? I've been trying to get 3.0.1926.0 to compile my installer, but keep getting the following error: [exec] Microsoft (R) Windows Installer Xml Linker version 3.0.1926.0 [exec] Copyright (C) Microsoft Corporation 2003. All rights reserved. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(70) : error LGHT0102 : The localization variable !(loc.ConfigureIIs ) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(71) : error LGHT0102 : The localization variable !( loc.StartMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(72) : error LGHT0102 : The localization variable !( loc.RollbackMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(73) : error LGHT0102 : The localization variable !( loc.CommitMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(74) : error LGHT0102 : The localization variable !( loc.WriteMetabaseChanges) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(36) : error LGHT0102 : The localization variable !( loc.msierrIISCannotConnect) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(37) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebSite) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(38) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(39) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadVDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(40) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadFilters) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(41) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadMimeMap) is unknown. Please ensure the variable is defined. Any help would be appreciated, thanks. -James - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets?
WiX 3.0 has a very different method of customizing the dialogs than WiX 2.0 which is so far undocumented. It's (hopefully) much more simple. Basically, just grab a sequence file from the sources that is similar to what you want (like WixUI_Mondo.wxs) and put that in your sources and modify it to only include the dialogs you want. Depending upon the dialog, it might need to the following to get removed: Dialogs added via DialogRef - just remove the element. Dialogs referred to via a Publish element - change the sequencing of the dialogs so the one you don't want is no longer in there. There are different steps because dialogs are displayed via different methods (its an artifact of how MSI works). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafuse Robert Sent: Wednesday, July 26, 2006 9:21 AM To: 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets? Okay, I'm confused. The section Customizing dialog sets at http://wix.sourceforge.net/manual-wix2/WixUI_dialog_library.htm mentions the files CustomDialogSet.build, CustomDialogSet.wxs and TestCustom.wxs but I can not find them in the WiX 2.0 binaries or source package (they don't seem to be in 3.0 either). Am I missing something? _ Bob Rafuse -Original Message- From: Rafuse Robert Sent: Wednesday, July 26, 2006 12:08 PM To: 'wix-users@lists.sourceforge.net' Subject: RE: Is there a way to suppress license agreement dialog in stock dialog sets? Okay, ignore the question... Immediately after I hit Send, I stumbled across Customizing dialog sets in the online docs. I ~swear~ I looked for this earlier... I must have mis-typed. Sorry to bother. _ Bob Rafuse -Original Message- From: Rafuse Robert Sent: Wednesday, July 26, 2006 12:04 PM To: wix-users@lists.sourceforge.net Subject: Is there a way to suppress license agreement dialog in stock dialog sets? WiX 2.0.4305.0 I am creating an .msi that will only be used internally by my associatesy. This install does not require a license agreement dialog. I was wondering, is it at all possible to suppress this dialog while still using the stock WiX dialog sets? Thanks, --- Bob Rafuse Important Note: This email and any attachment hereto are confidential and may contain trade secrets or may be otherwise protected from disclosure. If you have received it in error you are in notice of this fact. Please notify us immediately by reply email and then delete this email and any attachment from your system. Please understand that you are not allowed to copy this email or any attachment hereto or disclose its contents to any other person. Thank you. --- Important Note: This e-mail message and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient you must not use, copy, disclose or take any action based on this e-mail or any information and attachment contained in the message. If you have received this e-mail in error, please advise the sender immediately by reply e-mail or telephone and delete this message and any attachment from your system. Thank you. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
What are you trying to do overall? Using feature conditions in a components condition is a little awkward usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: Component Id=DbInstallationDirectoryService Guid=A4B5E633-D715-4e8e-8C4A-E58D1BAFFBAE XmlFile Action="" ElementPath=//DBInstallation/FeaturesInstalled File=[DBCREATION]dbinstallation.xml Id=dbInstallationConfig20 Name=Feature Sequence=19 Value=Feat1 / Condition![CDATA[(Feature1 = 3) AND (!Feature1 = 3)]]/Condition /Component From my understanding, it should right out FeatureFeat1/Feature if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using complexReference elements in the wixobj files and instead switching to unreal WixComplexReference tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change removing custom xml from the wixobj and wixlib files can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, Ive called it out here because this change is what prompted us to begin looking at breaking backwards-compatibility. Basically, we found
Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features?
Thanks for the pointer John. Thanks, Derek -Original Message- From: John Vottero [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 7:05 PM To: [EMAIL PROTECTED]; Bob Arnson Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Should WiX add support for installingWindowsinstrumentation features? From: Derek Cicerone [mailto:[EMAIL PROTECTED] This is a good chance for us to all get on the same page. Who on the PowerShell team is saying to use the Installer classes? (Or if this is from some MSDN docs, please send us the link.) Here's a link to the documentation on registering a new Cmdlet: http://windowssdk.msdn.microsoft.com/en-us/library/ms714644.aspx It only talks about using the Installer based PSSnapin class. It seems to be aimed at in-house developers rather than professional, commercial installers. In previous versions of PowerShell/Monad (before PSSnapin), the documentation described the registry keys that had to be created for a Cmdlet but, that seems to be missing now. I'm not sure but I think that the PSSnapin class just creates the right registry entries which points out a potential advantage of Installer based classes, I don't need to know what PSSnapin does, the PowerShell team decides what needs to happen and they write the code that makes it happen. I just have to declaratively describe my Cmdlet, which is exactly what the sample code in that link does. Having real WiX extensions to support all the things supported by Installer classes would be great but, it would also be nice to have syntax in a Component that points to an assembly and Installer class and have WiX do the right stuff so that the Installer's Install, Uninstall, Rollback, etc methods are called at the right times. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using complexReference elements in the wixobj files and instead switching to unreal WixComplexReference tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change removing custom xml from the wixobj and wixlib files can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, Ive called it out here because this change is what prompted us to begin looking at breaking backwards-compatibility. Basically, we found
Re: [WiX-users] -dWixUILicenseRtf method
That's very strange - I just tried this scenario and couldn't reproduce the problem. Perhaps the fix hasn't gotten into the public weekly release yet. Once you take the next drop, please try the original scenario again and let me know if it fails again. Be sure to double-check the version of the tools you are using to ensure its the most up-to-date. Thanks, Derek -Original Message- From: Klimek Manuel [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 11:08 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: AW: [WiX-users] -dWixUILicenseRtf method As I mentioned earlier, I installed the latest available weekly snapshot 3.0.1910.0, which is from 10-Jul-2006. I also tried 3.0.1821.0 from the released files at sf.net. Both versions still have the bug. Now I just installed my wix binaries to a directory without spaces - and it works ;-) - thanks a lot Cheers, Manuel -Ursprüngliche Nachricht- Von: Derek Cicerone [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. Juli 2006 18:23 An: Klimek Manuel; wix-users@lists.sourceforge.net Betreff: RE: [WiX-users] -dWixUILicenseRtf method Please update to the latest WiX 3.0 release. This error is due to installing the WiX tools in a path with spaces and it has been fixed in the latest releases. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klimek Manuel Sent: Monday, July 24, 2006 4:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] -dWixUILicenseRtf method Hi, I installed the snapshot 3.0.1910.0 and tried to use the method specified with feature request #1503405. d:\proj\Windows Installer XML\light.exe -dWixUILicenseRtf=d:/keylog.txt /nologo /v0 /b myoutputpath (all my wixobjs) -ext WixUIExtension -cultures:de-de If I use the 'old' method by specifying wixui.wixlib and -loc with a wixui.wixlib I built from the current wix source, everything works fine. But if I use the new method I get this error (english: The system cannot find the specified file) light.exe : error LGHT0001 : Das System kann die angegebene Datei nicht finden. (Ausnahme von HRESULT: 0x80070002) Exception Type: System.IO.FileNotFoundException Stack Trace: bei System.Reflection.Assembly.nLoadFile(String path, Evidence evidence) bei System.Reflection.Assembly.LoadFile(String path) bei Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String dat abaseFile) bei Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) I played around a little bit and found that if I specify a file that really doesn't exist, I get E:\delivery\Dev\wix_public\src\ext\uiextension\wixlib\LicenseA greementDl g.wxs(28 ) : error LGHT0103 : The system cannot find the file 'keylog.txta'. So I assume that I miss yet another file (in the first case). How can I find out which files I need? Is there any documentation on this (google didn't find anything)? Cheers, Manuel -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforge CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a binary in context of current logged inuser
Youd have to be more specific about why that didnt work for us to suggest a different solution. Perhaps I dont understand the problem correctly. From: Pallavi Patrutkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 6:51 AM To: [EMAIL PROTECTED]; Bahar Shah; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Installing a binary in context of current logged inuser Hi, We tried using this Impersonate attribute setting to yes, but still it doesnt work as per the requirement. Is there is any other solution for this problem? Regards, Pallavi. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Friday, July 21, 2006 12:35 PM To: 'Bahar Shah'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing a binary in context of current logged inuser Set the Impersonate attribute to yes for that CustomAction element but then the CA doesnt run as LocalSystem so it doesnt have elevated privileges. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahar Shah Sent: Thursday, July 20, 2006 11:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing a binary in context of current logged in user Hi, I need information on how do we install and run any binary in the context of the currenlty logged in user. My problem is since msiexec runs as LocalSystem all my binaries are installed with LocalSystem privieedges. I need to tweak few binaries to run as currently logged in user context. Regards Bahar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] -dWixUILicenseRtf method
Please update to the latest WiX 3.0 release. This error is due to installing the WiX tools in a path with spaces and it has been fixed in the latest releases. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klimek Manuel Sent: Monday, July 24, 2006 4:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] -dWixUILicenseRtf method Hi, I installed the snapshot 3.0.1910.0 and tried to use the method specified with feature request #1503405. d:\proj\Windows Installer XML\light.exe -dWixUILicenseRtf=d:/keylog.txt /nologo /v0 /b myoutputpath (all my wixobjs) -ext WixUIExtension -cultures:de-de If I use the 'old' method by specifying wixui.wixlib and -loc with a wixui.wixlib I built from the current wix source, everything works fine. But if I use the new method I get this error (english: The system cannot find the specified file) light.exe : error LGHT0001 : Das System kann die angegebene Datei nicht finden. (Ausnahme von HRESULT: 0x80070002) Exception Type: System.IO.FileNotFoundException Stack Trace: bei System.Reflection.Assembly.nLoadFile(String path, Evidence evidence) bei System.Reflection.Assembly.LoadFile(String path) bei Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String dat abaseFile) bei Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) I played around a little bit and found that if I specify a file that really doesn't exist, I get E:\delivery\Dev\wix_public\src\ext\uiextension\wixlib\LicenseAgreementDl g.wxs(28 ) : error LGHT0103 : The system cannot find the file 'keylog.txta'. So I assume that I miss yet another file (in the first case). How can I find out which files I need? Is there any documentation on this (google didn't find anything)? Cheers, Manuel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ORCA validation issue with wix generated installer
That means that the component needs to have a registry key under HKCU as its keypath. This supports installation of per-user shortcuts for a per-machine installation. Alternatively, you could switch to advertised shortcuts by specifying Advertise=yes on the Shortcut elements. However, advertised shortcuts may cause undesirable demand-install behavior. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Calcote Sent: Monday, July 24, 2006 12:18 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ORCA validation issue with wix generated installer Hi, Can anyone tell me what the following error message from the Orca Validator means: ICE43 ERROR Component PROGUID_comp has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file. ?? Thanks, John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ORCA validation issue with wix generatedinstaller
It's a very good question actually and I've seen no solid recommendation on a best-practice approach. I think you can create any HKCU registry key you like and use it as the keypath (so long as each component has a different key). This issue comes up often so I'll see if I can learn more, but that's what I know so far. Derek -Original Message- From: John Calcote [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 3:27 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] ORCA validation issue with wix generatedinstaller Thanks Derek, Can you recommend the proper WiX construct for creating the HKCU key associated with the shortcuts - I have several of these messages, and I want to do it the right way, not experiment for days until I come up with the proper one accidentally. :) I've looked in the Tutorial and Help documents and I can't find a reference to this issue. If you know where the information is, please feel free to refer me to the proper pages. Thanks, John Derek Cicerone [EMAIL PROTECTED] 7/24/2006 3:21 PM That means that the component needs to have a registry key under HKCU as its keypath. This supports installation of per-user shortcuts for a per-machine installation. Alternatively, you could switch to advertised shortcuts by specifying Advertise=yes on the Shortcut elements. However, advertised shortcuts may cause undesirable demand-install behavior. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Calcote Sent: Monday, July 24, 2006 12:18 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ORCA validation issue with wix generated installer Hi, Can anyone tell me what the following error message from the Orca Validator means: ICE43 ERROR Component PROGUID_comp has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file. ?? Thanks, John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ORCA validation issue with wixgeneratedinstaller
I believe it needs to look something like the following pseudo-code: Component Registry Root=HKCU KeyPath=yes ... / Shortcut ... / /Component Basically, what you need to do is create a component with an HKCU registry key as its keypath and the shortcut. When MSI does a health check on the component to see if it's installed for the current user, it will look for a registry key to be present, when its not there, it will install the shortcut, thus ensuring that all users on the machine get the shortcut installed. MSI does not do health-checks on shortcuts, only registry keys, files, directories, and ODBC stuff. Since the file pointed to by the shortcut is likely installed (since it's in a per-machine location), only per-user stuff is suitable for checking if everything is installed for the current user. To accomplish that, a registry key is the most lightweight thing to use as a keypath for determining if everything is installed. If you'd like more info on this stuff, I'd suggest checking out the MSI documentation. It contains a lot of information, so stuff can be hard to find at times, but all this stuff I'm talking about is in there. Derek -Original Message- From: John Calcote [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 3:47 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] ORCA validation issue with wixgeneratedinstaller Derek, Okay, the subtle approach didn't work. Now I'll try the less subtle version of my question ;-)... I don't really understand how a registry key is associated with a shortcut - shortcuts are files in the file system, not registry keys, AFAIK. This is a more fundamental question. Perhaps it would be more obvious to me what I should do if I understood the more base concept. What does it actually mean to create any HKCU registry key I like, and use it as the keypath? Can you give me an example of doing this? I just don't understand the reason why this has to be done (nor do I understand the actual syntax of doing it, but if I understood the meaning of associating a registry key in the User hive with a shortcut, perhaps I could glean the syntax on my own. :) Thanks in advance, John Derek Cicerone [EMAIL PROTECTED] 7/24/2006 4:32 PM It's a very good question actually and I've seen no solid recommendation on a best-practice approach. I think you can create any HKCU registry key you like and use it as the keypath (so long as each component has a different key). This issue comes up often so I'll see if I can learn more, but that's what I know so far. Derek -Original Message- From: John Calcote [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 3:27 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] ORCA validation issue with wix generatedinstaller Thanks Derek, Can you recommend the proper WiX construct for creating the HKCU key associated with the shortcuts - I have several of these messages, and I want to do it the right way, not experiment for days until I come up with the proper one accidentally. :) I've looked in the Tutorial and Help documents and I can't find a reference to this issue. If you know where the information is, please feel free to refer me to the proper pages. Thanks, John Derek Cicerone [EMAIL PROTECTED] 7/24/2006 3:21 PM That means that the component needs to have a registry key under HKCU as its keypath. This supports installation of per-user shortcuts for a per-machine installation. Alternatively, you could switch to advertised shortcuts by specifying Advertise=yes on the Shortcut elements. However, advertised shortcuts may cause undesirable demand-install behavior. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Calcote Sent: Monday, July 24, 2006 12:18 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ORCA validation issue with wix generated installer Hi, Can anyone tell me what the following error message from the Orca Validator means: ICE43 ERROR Component PROGUID_comp has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file. ?? Thanks, John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http
Re: [WiX-users] ORCA validation issue with wix generated installer
You make a good point about the ProgramMenuFolder directory - I agree that ICE43 seems overzealous in some cases. However, during ICE validation, there is no way to know if an MSI file will be installed per-user or per-machine (since the value of ALLUSERS may be set at the last moment). So the ICE is currently configured to be very conservative and flag a Shortcut as going to a per-user location if it's possible for it to be installed to a per-user location (regardless of whether it will be or even the current value for ALLUSERS). Although you may think a shortcut will never get installed to a per-user location, nothing prevents your customer from setting ALLUSERS to modify the behavior. Thanks, Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Hoyle Sent: Monday, July 24, 2006 5:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ORCA validation issue with wix generated installer Derek Cicerone wrote: That means that the component needs to have a registry key under HKCU as its keypath. This supports installation of per-user shortcuts for a per-machine installation. I don't see why anyone would ever want to do this - put per user shortcuts in per user installations and per machine shortcuts in the all users category. Mixing the two is just silly IMO. I'm not even sure *how* you'd make wix do it, since ProgramMenuFolder is set correctly depending on the install type... you'd have to override the default behaviour somehow. I've never managed to author a nontrivial wix file without this ICE, but in each case I know I'm doing the correct thing.. it's just generated automatically by any attempt to create a shortcut. That makes the warning useless. Tony - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with Shortcuts
If you are migrating to WiX, please try using dark on your MSI files. The WiX 3.0 dark.exe should be especially accurate for the conversion. Beyond that, the authoring below nests a Shortcut under a component, which creates a shortcut to the folder of the component. To create a shortcut to a file instead, nest the shortcut under the File element. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared McIntyre Sent: Sunday, July 23, 2006 10:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with Shortcuts I'm migrating to WiX/Windows Installer from another solution. I have the application shortcut in the ProgramMenuDir working correctly, but we had other files in there in the old item, including another executable shortcut. I can't get these to work. They all show up as links to the ProgramMenuDir directory itself, and not the file. Here is an example? Component Id='License' Guid='43b0a1cc-cda5-4d19-8986-efcceedf3a4b' File Id='License' Name='License.rtf' DiskId='1' src='License.rtf' Vital='yes' ReadOnly=yes/ Shortcut Id=startmenuLicense Directory=ProgramMenuDir Name=License LongName=License.rtf Icon=License.rtf IconIndex=0 / /Component Any thoughts on what I'm doing wrong? Jared - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issue with 3.0 development release -missing libraries
WiX 3.0 does not ship wixlib files because the WiX extensions are now completely self-contained in each extension dll. You should see a WixUIExtension.dll in the 3.0 releases. To use it, just specify -ext WixUIExtension -cultures:en-us in light and you're done. This will pull in the WiX UI libraries, all the binaries, and the English localized string resources for the UI. I'm not sure what other localizations are offered, but I know en-us is in there. In terms of upgrading from WiX 2.0 to 3.0, it sounds like you did it manually since you commented on some of the major schema changes. It's much, much easier to just run WixCop on all your sources. It will automatically update your source files to the latest schema. This tool is useful even after you convert to WiX 3.0 since it will continue to be updated to allow you to keep your source files using the latest schema. Here's the suggested way to run wixcop: 1. Backup all your source files, or just check them out if you use source management. 2. Run wixcop -f -s *.wx* to update all .wxs and .wxi files found in the current directory and all sub-directories. WiX is currently using .net 1.1 for maximum compatibility. The plan is to move to .net 2.0 sometime later this year just for WiX 3.0 (2.0 will stay on .net 1.1). We just want to hold off on that a bit longer because when that happens WiX 2.0 is really going to stop getting updates. We really need someone to volunteer to start updating the docs for 3.0 now that things are beginning to settle down a bit there. Hopefully someone can help out there soon. Please let us know if you have any other questions or feedback. Thanks, Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Calcote Sent: Saturday, July 22, 2006 4:18 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Issue with 3.0 development release -missing libraries Sorry - I never finished my sentence in the first paragraph below. What I was trying to say, was that after working through the issues of the upgrade, I found it wouldn't link because the wixui library was not in root of the package directory, as it had been with the 2.0 package (odd that you folks don't have an MSI installer for WiX, don't you think? :) I tried moving the 2.x libraries into the 3.x packages, but these didn't link properly - they hadn't properly been upgraded. I also tried searching in your releases directory for other releases, but none of them had the wixlibs in the root directory of the packages. Finally, I tried building from source (after downloading and installing nant) - WiX apparently relies on VS.NET 2003 and the .NET SDK 1.1 - I've already moved on to VS 2005 and .NET SDK 2.0... what a pain! BTW, I LOVE this stuff. I've just barely begun with it, and I already feel comfortable with it and have recommended it to several others. John John Calcote [EMAIL PROTECTED] 7/22/2006 5:10 PM Hey, I was wondering why don't the wixlib libraries (wixui, etc) ship installed with the developer release? I have an installer with a GUI interface - I take advantage of the WIX UI (Mondo) interface. I tried upgrading my source to the 3.0 developer release. After working through the issues (one source file was generated by tallow - it used the src attribute on the file element - had to be changed to the newer Source attribute. Also had to change LongName to Name and remove the old short Name attributes on the File elements.) Incidentally, the reason for attempting to use 3.0 (unstable) rather than the 2.0 (stable) version was that I was having some verification issues with my installer under the 2.x release, and thought I'd try the new stuff before mentioning it to you. John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics
Re: [WiX-users] Issue with 3.0 development release-missing libraries
I'll have to defer to others for those types of questions. There are some legal implications for making contributions (a special form needs to be snail mailed in). Derek -Original Message- From: John Calcote [mailto:[EMAIL PROTECTED] Sent: Saturday, July 22, 2006 6:20 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Issue with 3.0 development release-missing libraries Derek, I'd love to help with the doc if you want. I'd probably need to ask a lot of questions along the way. How do I get started - I mean where do I look for doc sources, and such. Thanks, John Derek Cicerone [EMAIL PROTECTED] 7/22/2006 5:34 PM WiX 3.0 does not ship wixlib files because the WiX extensions are now completely self-contained in each extension dll. You should see a WixUIExtension.dll in the 3.0 releases. To use it, just specify -ext WixUIExtension -cultures:en-us in light and you're done. This will pull in the WiX UI libraries, all the binaries, and the English localized string resources for the UI. I'm not sure what other localizations are offered, but I know en-us is in there. In terms of upgrading from WiX 2.0 to 3.0, it sounds like you did it manually since you commented on some of the major schema changes. It's much, much easier to just run WixCop on all your sources. It will automatically update your source files to the latest schema. This tool is useful even after you convert to WiX 3.0 since it will continue to be updated to allow you to keep your source files using the latest schema. Here's the suggested way to run wixcop: 1. Backup all your source files, or just check them out if you use source management. 2. Run wixcop -f -s *.wx* to update all .wxs and .wxi files found in the current directory and all sub-directories. WiX is currently using .net 1.1 for maximum compatibility. The plan is to move to .net 2.0 sometime later this year just for WiX 3.0 (2.0 will stay on .net 1.1). We just want to hold off on that a bit longer because when that happens WiX 2.0 is really going to stop getting updates. We really need someone to volunteer to start updating the docs for 3.0 now that things are beginning to settle down a bit there. Hopefully someone can help out there soon. Please let us know if you have any other questions or feedback. Thanks, Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Calcote Sent: Saturday, July 22, 2006 4:18 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Issue with 3.0 development release -missing libraries Sorry - I never finished my sentence in the first paragraph below. What I was trying to say, was that after working through the issues of the upgrade, I found it wouldn't link because the wixui library was not in root of the package directory, as it had been with the 2.0 package (odd that you folks don't have an MSI installer for WiX, don't you think? :) I tried moving the 2.x libraries into the 3.x packages, but these didn't link properly - they hadn't properly been upgraded. I also tried searching in your releases directory for other releases, but none of them had the wixlibs in the root directory of the packages. Finally, I tried building from source (after downloading and installing nant) - WiX apparently relies on VS.NET 2003 and the .NET SDK 1.1 - I've already moved on to VS 2005 and .NET SDK 2.0... what a pain! BTW, I LOVE this stuff. I've just barely begun with it, and I already feel comfortable with it and have recommended it to several others. John John Calcote [EMAIL PROTECTED] 7/22/2006 5:10 PM Hey, I was wondering why don't the wixlib libraries (wixui, etc) ship installed with the developer release? I have an installer with a GUI interface - I take advantage of the WIX UI (Mondo) interface. I tried upgrading my source to the 3.0 developer release. After working through the issues (one source file was generated by tallow - it used the src attribute on the file element - had to be changed to the newer Source attribute. Also had to change LongName to Name and remove the old short Name attributes on the File elements.) Incidentally, the reason for attempting to use 3.0 (unstable) rather than the 2.0 (stable) version was that I was having some verification issues with my installer under the 2.x release, and thought I'd try the new stuff before mentioning it to you. John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a binary in context of current logged in user
Set the Impersonate attribute to yes for that CustomAction element but then the CA doesnt run as LocalSystem so it doesnt have elevated privileges. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahar Shah Sent: Thursday, July 20, 2006 11:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing a binary in context of current logged in user Hi, I need information on how do we install and run any binary in the context of the currenlty logged in user. My problem is since msiexec runs as LocalSystem all my binaries are installed with LocalSystem privieedges. I need to tweak few binaries to run as currently logged in user context. Regards Bahar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What use, WiX 2 or WiX 3 ?
When will you be shipping to your customers? The current recommendation is to only use 3.0 if your product ships in 2007 or later. That being said, we've begun slowing down the pace of changes to the WiX 3.0 core tools for a few months now, but breaking changes are still being made and I'd expect that to continue for a few months. The extensions and newer tools (like ClickThrough, heat, smoke, etc...) will also stay in a state of consistent development for quite a while (in fact, we still haven't fully stabilized extensions in 2.0!). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Biryukov Sent: Thursday, July 20, 2006 11:48 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What use, WiX 2 or WiX 3 ? In the near future we are going to use WiX for authoring a large installer with supporting: - GAC (install .Net 1.1 components) - Windows Services - COM+ components - Message Queues (MSMQ) - Web Services - Creating IIS web site How much the risk of use WiX 3 Beta, unlike WiX 2 Release ? Thanks. -- Alexander Biryukov - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a binary in context of current logged in user
The installer will run that particular custom action as the user, yes. Im afraid to ask, but what action will you be performing as the user? (Im afraid of the answer because doing anything per-user during setup is very dubious since it would likely only work for the user performing the installation and not other users on the machine). Derek From: Bahar Shah [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:13 AM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing a binary in context of current logged in user Thanks. Could you ellaborate a bit more. Do you mean to say that just setting a impersonate attribute to 'yes' the installer would know who the current logged user is and install under that priveldge ? Regards Bahar On 7/21/06, Derek Cicerone [EMAIL PROTECTED] wrote: Set the Impersonate attribute to yes for that CustomAction element but then the CA doesn't run as LocalSystem so it doesn't have elevated privileges. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Bahar Shah Sent: Thursday, July 20, 2006 11:56 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing a binary in context of current logged in user Hi, I need information on how do we install and run any binary in the context of the currenlty logged in user. My problem is since msiexec runs as LocalSystem all my binaries are installed with LocalSystem privieedges. I need to tweak few binaries to run as currently logged in user context. Regards Bahar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Path the file in Binary table
Youd have to do it via your own custom action. What is your scenario? In general you should avoid custom actions because its very difficult to write one properly/securely. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Tse Sent: Thursday, July 20, 2006 4:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Path the file in Binary table I see, so say I want to use temporary files during install as part of a custom action, but dont want the files to be on the system after execution. Is there a built in way to do this? Or do I have to make my own custom action and perform its own extraction and cleanup? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Thursday, 20 July 2006 1:13 AM To: Eddie Tse Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Path the file in Binary table Eddie Tse wrote: Files in the Binary table get extracted by the installer to a temporary folder upon execution. Is there a way to get the full path to the temporary file using just an Id from the binary table? No. MSI extracts the files only for the duration of the custom action call. -- sig://boBhttp://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Path the file in Binary table
The WiX IIS custom actions dont cover your needs? What will the external command do specifically? Derek From: Eddie Tse [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 9:44 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Path the file in Binary table Im trying to deploy web services to an IIS site running Sharepoint along with some templates that will be loaded as documents into the Sharepoint library. Looks like just executing an external command would be easier then. Eddie From: Derek Cicerone [mailto:[EMAIL PROTECTED]] Sent: Friday, 21 July 2006 10:18 AM To: 'Eddie Tse'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Path the file in Binary table Youd have to do it via your own custom action. What is your scenario? In general you should avoid custom actions because its very difficult to write one properly/securely. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Tse Sent: Thursday, July 20, 2006 4:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Path the file in Binary table I see, so say I want to use temporary files during install as part of a custom action, but dont want the files to be on the system after execution. Is there a built in way to do this? Or do I have to make my own custom action and perform its own extraction and cleanup? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Thursday, 20 July 2006 1:13 AM To: Eddie Tse Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Path the file in Binary table Eddie Tse wrote: Files in the Binary table get extracted by the installer to a temporary folder upon execution. Is there a way to get the full path to the temporary file using just an Id from the binary table? No. MSI extracts the files only for the duration of the custom action call. -- sig://boBhttp://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT1055 InstallUISequence warning
Check out the ModuleInstallUISequence. That table contains the UI actions for a merge module. One of the actions in there was likely authored improperly and is colliding with an action in the main msi. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Wednesday, July 19, 2006 1:13 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT1055 InstallUISequence warning Hi all, I'm getting a really strange warning when merging a number of WiX built merge-modules into a product: .\default.wxs(117) : warning LGHT1055 : The InstallUISequence table contains an action '' which cannot be merged from the merge module '..\./bin/modules/mod1.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. This action should only be declared in the database or one merge module. When I open up the msm in orca, I see that the InstallUISequence table is empty... This leads to an interesting question: Why does WiX generate empty tables for optional tables? Shouldn't they just be absent? Any ideas what is causing the above error? Thanks, -- Shmarya --- [EMAIL PROTECTED] - http://shmarya.net NUnit rocks! http://nunit.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Nested parenthesis is unsupported in both versions of WiX. Is that a standard Windows environment variable or one which you are defining? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, July 18, 2006 4:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename In build 2419 it was possible to evaluate the value of the environment variable CommonProgramFiles(x86) within a define as such ?define CPF=$(env.CommonProgramFiles(x86))? In 2.0.4310.0 this is broken as the close parens are no longer matched with the open parens. Are there any quoting rules that can be used to make this work in the current build? Thanks. Jeffrey Altman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename
Sorry for all the questions, here's one more: how is the value of the path to Program Files (x86) being used? This value is specific to the build machine so it wouldn't be useful in the MSI file since the machine on which the msi is being installed may use a different path. You'd want to use something more like the pre-defined property ProgramFilesFolder to get the path of that folder during installation. Thanks, Derek -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 5:00 PM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename That is a standards Windows environment variable on 64-bit Windows builds within the WOW64 environment. CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files Jeffrey Altman Derek Cicerone wrote: Nested parenthesis is unsupported in both versions of WiX. Is that a standard Windows environment variable or one which you are defining? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, July 18, 2006 4:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in thename In build 2419 it was possible to evaluate the value of the environment variable CommonProgramFiles(x86) within a define as such ?define CPF=$(env.CommonProgramFiles(x86))? In 2.0.4310.0 this is broken as the close parens are no longer matched with the open parens. Are there any quoting rules that can be used to make this work in the current build? Thanks. Jeffrey Altman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Retrieve hostname during an installation.
Thats not a good idea replying upon certain system registry values is an invitation for application compatibility issues for future versions of the OS. Instead, just use the built-in ComputerName property: ComputerName Property The ComputerName property is the computer name of the current system. The installer sets this property by a system call to GetComputerName. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Kulp Sent: Monday, July 17, 2006 12:46 PM To: Aaron Feng; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Retrieve hostname during an installation. Perhaps you could do a RegistrySearch on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName ? Wix-users, please correct me if there is a built-in or better way to do this. --kulp From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Feng Sent: Monday 17 July 2006 14:34 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Retrieve hostname during an installation. Is there an easy way to retrieve the hostname of the computer during an install without writing an custom action? Thanks, Aaron - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating msi from merge module fails
What does the verbose installation log say? Have you verified that the msi file is created with files? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arto Stimms Sent: Wednesday, July 12, 2006 2:00 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating msi from merge module fails Hi, I am trying to create an .msi file from a single merge module. The merge module I am using is the BonjourCore library from Apple which is available as an .msm file here http://developer.apple.com/networking/bonjour/BonjourCore-1_0_3.zip (in the zip file). Creating the msi file works fine, an the install runs with no errors, but no files are installed! Have anybody else encountered a similar problem? I have attached the .wxs file. Best Regards, Arto Stimms __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
Adding wix-users to this topic I just noticed it was sent to wix-devs. Please only use wix-devs for discussions of code and other internals of the WiX toolset, all discussion about using the toolset should go to wix-users. Its not necessary to have this authoring: InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence Those actions are all included automatically when they are needed: - Condition should add the LaunchConditions action at 100. - RegistrySearch should add the AppSearch action at 50. - FindRelatedProducts is used by the Upgrade table, so its actually not needed in the below authoring. You can schedule your custom actions using the Before/After attributes, so there would be no need for using the AppSearch, LaunchCondition, etc elements for that either. Other unnecessary authoring: - Fragment/@Id is only needed in extremely rare circumstances. Since FragmentRef is no longer supported, Id suggest omitting the Fragment identifiers to save unnecessary effort. - Property/@ComplianceCheck is not necessary if the value is no since its the default. - Specifying a Value for a property set by a RegistrySearch is also usually not necessary since you can more easily check for the existence of a property versus a specific value. It looks like relying upon the built-in capabilities of WiX a bit more will save authoring effort as well as enable your scenarios to work (but we should still open a bug against the Overridable attribute not working on standard action elements). Thanks, Derek From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 11:10 AM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. The reason we wanted this functionality is because we are trying to create wixlibs that are very specific. So for example, I've got a wixlib and all it does is check to see if the target machine has some other application installed on it. So here is that wxs file: ?xml version='1.0' encoding='UTF-8'? Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' xmlns:inin='http://www.inin.com/i3WixExtensions' Fragment Id=ca_ICServerCheck Condition Message=This application can not be installed on an IC Server. The install will now exit.![CDATA[ICSERVERSITENAME ]]/Condition Property Id=ICSERVERSITENAME Value=0 ComplianceCheck=no RegistrySearch Id=ICServerCheck Root=HKLM Key=SOFTWARE\Interactive Intelligence\EIC\Directory Services\Root Name=SITE Type=raw / /Property InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence /Fragment /Wix So this wix file is built as a wixlib.Then for any given install, all it as to do is include the ca_ICServerCheck.wixlib file and it's included in the install. And now when any other install needs that launch condition, it's done exactly the same way. And if it changes, it changes for every install. That being said, we will have lots of custom actions that will do the same sort of thing. So we can't include the AppSearch and LaunchConditions elements in every single ca_*.wixlibfile because when the wrapper install is built, it sees multiple of the same element and fails. We were hoping that the Overridable attribute would allow for this functionality. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:20 PM To: Wilson, Brad; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. I see the problem now. Since the AppSearch action is a standard action the wix toolset defines the overridable sequencing for the action. You cant specify Overridable=yes because its already been declared. You can override the standard sequencing already though, so setting the attribute shouldnt be necessary. Unlike custom actions, you should keep the sequencing for standard actions, well, standard across all products that you ship. It should not be tweaked for some products and not others. Why are you attempting to modify the sequencing of AppSearch and LaunchConditions? They are already sequenced so that AppSearch occurs before LaunchConditions. Please open a bug against this in the least its a documentation issue because Overridable should not be supported on the AppSearch element. Please assign the bug to me. Thanks, Derek From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 10:07 AM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. 3.0.1828.0 (it's in the subject of the email). From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:03 PM To: Wilson, Brad
Re: [WiX-users] language specific wixlibs
You didnt specify a culture for light to use, so it didnt load any localization strings from the library. Since wix libraries may contain multiple languages of localized strings, the culture is necessary to pick one. In this case, youd probably want en-us. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Brad Sent: Monday, July 10, 2006 12:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] language specific wixlibs WiX version being used: 3.0.1828.0 It appears that light.exe is failing to parse the WixLocalization elements that are included in wixlibs. The following is an example of a generated wixlib that i'm trying to include in an install (Feature_Designer.wixlib): ?xml version=1.0 encoding=utf-8 ? wixLibrary version=3.0.1808.0 xmlns=http://schemas.microsoft.com/wix/2003/11/libraries WixLocalization Codepage=1252 Culture=en-us xmlns=http://schemas.microsoft.com/wix/2003/11/localization String Id=IDFeatureTitle ![CDATA[ Interaction Designer]] /String String Id=IDFeatureDescription ![CDATA[ Interaction Designer is used to modify handlers for the xIC Server.]] /String /WixLocalization section id=Fragment_Designer type=fragment xmlns=http://schemas.microsoft.com/wix/2003/04/objects reference sourceLineNumber=..\Feature_Designer.wxs*8 table=Component symbol=FileStreamA.d / reference sourceLineNumber=..\Feature_Designer.wxs*7 table=Component symbol=I3ExprEditA.d / reference sourceLineNumber=..\Feature_Designer.wxs*4 table=Directory symbol=SERVER / reference sourceLineNumber=..\Feature_Designer.wxs*3 table=ININCustomAction symbol=TestDeferredCA / table name=Feature tuple sourceLineNumber=..\Feature_Designer.wxs*4 fieldFeature_Designer/field field / field!(loc.IDFeatureTitle)/field field!(loc.IDFeatureDescription)/field field2/field field1/field fieldSERVER/field field0/field /tuple /table ... i get the following error(s) when running light.exe: light.exe -nologo -w3 -v0 WiX_ServerManager.wixobj ..\..\..\pub\gen\install\lib\release\Feature_Designer.wixlib -loc ..\Localization\en-us.wxl -out IC_Server_Manager_Applications.msi -ext ININ.WiXExtensions.I3WiXExtensions, ININ.WiXExtensions ..\Feature_Designer.wxs(4) : error LGHT0102 : The localization variable !(loc.IDFeatureTitle) is unknown. Please ensure the variable is defined. ..\Feature_Designer.wxs(4) : error LGHT0102 : The localization variable !(loc.IDFeatureDescription) is unknown. Please ensure the variable is defined. I guess it's quite possible that i'm not structuring my wrapper install wxs file correctly. But from the documentation it looks like it is correct. Brad Wilson |Developer phone fax +1.317.715.8523 | [EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.com - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
inline From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:57 PM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Thanks for the suggestions on cleaning up my wxs file. I try to be efficiently lazy so that certainly helps. I added the InstallUISequence stuff when I first started working on this because I wasn't seeing any entries in the LanuchConditions orAppSearch tables when including the wixlib that clearly had entries specified. [DerekC] There is no LaunchConditions table only a LaunchCondition table. Elements under the InstallUISequence element create actions in the InstallUISequence, not rows in any other table. So I just took those elements out and rebuilt the wixlib. Here is the output from that: ?xml version=1.0 encoding=utf-8 ? wixLibrary version=3.0.1808.0 xmlns=http://schemas.microsoft.com/wix/2003/11/libraries section type=fragment xmlns=http://schemas.microsoft.com/wix/2003/04/objects table name=AppSearch tuple sourceLineNumber=..\ca_ICServerCheck.wxs*9 fieldICSERVERSITENAME/field fieldICServerCheck/field /tuple /table table name=LaunchCondition tuple sourceLineNumber=..\ca_ICServerCheck.wxs*7 fieldICSERVERSITENAME/field fieldThis application can not be installed on an IC Server. The install will now exit./field /tuple /table table name=Property tuple sourceLineNumber=..\ca_ICServerCheck.wxs*9 fieldICSERVERSITENAME/field field / field0/field field0/field field0/field /tuple /table table name=RegLocator tuple sourceLineNumber=..\ca_ICServerCheck.wxs*10 fieldICServerCheck/field field2/field fieldSOFTWARE\Interactive Intelligence\EIC\Directory Services\Root/field fieldSITE/field field2/field /tuple /table /section /wixLibrary When I build the wrapper install and include the wixlib, i'm not seeing those entries in the specified tables and the actions are not being scheduled. One thing I did notice is that the version of the WixLibrary says 3.0.1808.0. When I view the versions of the files i'm using to build everything they all say 3.0.1828.0. Is it possible that the wix source wasn't updated to insert the 1828 version? Or do I have a version mismatchingproblem? [DerekC] The wix library version is actually hard-coded. It does not need to match the version of the wix toolset you are using. In fact, it hardly ever does. The version in the wixlib files is updated when the schema of the wixlib file format is modified (as it was recently). It could be months before its updated again (or never). Assuming that version 1808 in the wixlib file is ok, and that I'm including the wixlib appropriately when calling light.exe, what else could cause the entries from the above wixlib file to not be created in the msi file? [DerekC] You likely arent referencing anything from the Fragment. Create a PropertyRef Id=ICSERVERSITENAME / element in your main wix authoring. This will reference the Property in the Fragment and pull it into the product (or module). This is one of the main concepts of WiX creating references to build up an installation from lots of little pieces. As a test I just removed the wixlib from being included in the wrapper install and inserted the Condition and Property elements directly in the wxs file for the install. When built, the install now has the appropriate tables and actions. [DerekC] That makes sense because the authoring wasnt being referenced follow the instructions above and it should work. So this is either some problem where i'm by mistake not including the wixlib or those elements in a wixlib that is included in an install wrapper is not resulting in the tables and actions being put in the msi. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 2:28 PM To: Wilson, Brad; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Adding wix-users to this topic I just noticed it was sent to wix-devs. Please only use wix-devs for discussions of code and other internals of the WiX toolset, all discussion about using the toolset should go to wix-users. Its not necessary to have this authoring: InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence Those actions are all included automatically when they are needed: - Condition should add the LaunchConditions action at 100. - RegistrySearch should add the AppSearch action at 50. - FindRelatedProducts is used by the Upgrade table, so its actually not needed in the below authoring. You can schedule your custom actions using the Before/After attributes, so there would be no need for using the AppSearch, LaunchCondition, etc
