Re: [WiX-users] Improve the WiX mailing list
I find the wix-users mailing list to be sufficient. I had terrible experiences with InstallShield and InstallShield's forums over the years. I've used InstallShield 7, 10/X/10.5 and now 2008. I avoid the forums as much as possible. WiX has actually helped me become a better InstallShield packager. No support system is perfect. I certainly don't feel there is a disconnect between the leaders and the users of WiX. Cheers, David. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Monday, 2 June 2008 10:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Improve the WiX mailing list A forum instead of a mailing list would go a long way to solve the problem. While vBulletin is standard out of the box, I actually like the feature over at the Microsoft forums where topics can be attributed as a Question and as Answered. This allows a group of volunteers to see who has been assisted and who has not. BTW, this is one place where I feel that their is a disconnect between the leaders and the users of WiX. I've posted over 3,500 times on InstallShield Community helping many, many people over the years and personally I don't see what the big complaint is about going to a forum based system. Rob Mensching [EMAIL PROTECTED] wrote: Answering questions takes time. Depending on the complexity of the question and the amount of time available some questions may go unanswered for a very long time. The only thing I know to do is to keep doing research and follow up with your own question with whatever extra research you may have found narrowing down the complexity of the question until someone has cycles to answer it... I'm answering community stuff tonight since I'm home sick and can't sleep any longer but don't have enough focus to dig into technical problems. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Riyaz Mogharabin Sent: Monday, June 02, 2008 00:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Improve the WiX mailing list Dear All, I hope you are fine and doing well. I have a question from you experts about the mailing lists. How can we manage the WiX mailing list to ensure most of the emails are answered? I personally have sent some emails to the group that I'm sure they have answers, but nobody has answered them yet, and perhaps will never answer. How can we change this? How can we have a guarantee that all the mails are answered and if necessary are treated with? (Some of them may need research and maybe useful to be added in the next releases.) Maybe we can have an index or a list of the emails with no answers? And try to answer them one by one? Do not forget that the archive is a very good help besides the documentation. I hope there are good suggestions for this. Regards, Riyaz --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (was: RE: WIX 3.0 release date)
WiX isn't hard. Keeping to MSI's rules is. Creating visual designers to abstract people away from the complexities can be a bad thing. For example, try to get your software certified for Vista without a good understanding of MSI and ICE. InstallShield Developer/7 was terrible, 10/X/10.5 wasn't much better. 2008 is good, however I still find myself in the direct editor a lot, avoiding the fancy InstallShield GUI. That's just my opinion/experience. WiX has made me a better packager (with both WiX and InstallShield). I say get the CLI tools right before adding visual designers (increasing the complexity/opportunity for issues). Cheers, David. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Monday, 2 June 2008 11:04 PM To: General discussion for Windows Installer XML toolset.; Friedrich Dominicus Subject: Re: [WiX-users] (was: RE: WIX 3.0 release date) Up until just 2 weeks ago the Managed Code debate was certainly applicable.Also I believe that your desire to be 100% perfect on authoring content ( a good goal ) is conflicting with users goals to decrease the learning curve and accelerate authoring with visual designers.But you usually don't frame it in that context, you usually just say something along the lines of a `I'm a command line guy` or `notepad is fine`. Users clearly don't think that as I often get comments talking about how hard WiX is. In the end, I don't know if refusing to automate authoring really helps any as people can still get unexpected results. Take the recent MergeMod.dll problem in WiX.That was a pain point as a result of OMUS and MSI's narrow view of what you should and should not do. InstallShield has a checkbox called always overwrite that helps on a per component basis but you still have to know to check it. I was at InstallShield a year and a half ago and one of the things that I suggested was to extend validation across builds. Write now validation can catch some problems with a package but it can't catch the type of problem that MergeMod caused. But if you could identify the database elements that influence all of these unexpected behaviors, catalog them and then holistically validate the package against previous packages you could problem solve many of them. Then you could probably consider more automated authoring. Rob Mensching [EMAIL PROTECTED] wrote: That article focuses on the case where the leaders of the project become detached from the users of the project. It really doesn't matter if the project is open source or commercial, the results are the same. Users quit using the project. For commercial entities that usually ends up affecting the bottom line (the article refers to this as get developers fired). For open source projects the project ends up with fewer users or ends up forking and going in different directions. To bring the point back home, I can't currently think of any cases where this is a problem for the WiX toolset. There are plenty of things that need to be fixed/addressed in the WiX toolset but I don't think the leaders of the project or the users of the project disagree here. The two cases I can think of where there has been some contention: 1. FragmentRef. Fragment ref was a WiX v2 concept that over time I found wasn't really necessary. What I found was everyone was putting FragementRefs everywhere. In WiX v3 we removed the FragmentRef concept and some people complained. The complaints were exactly what I was looking for because it helped us find the remaining places where references were not being automatically generated by the WiX toolset. Now that those are fixed, functionality that was not necessary was removed for a better system... I think. 2. Component Rules. These things have been the bane of my existence since the end of my internship on the Windows Installer team back in 1998. I documented the rules and sent them around to all of the developers back then. I was incredulous that they could be real but as well all know now they are. The Component Rules make auto-generating content in the core toolset very, very difficult because so much management infrastructure has to be in place to make sure the Component GUIDs remain stable. Otherwise, a product will end up unpatchable or worse. IMHO it is not acceptable for the WiX toolset to autogenerate content that makes one's packages to be unpatchable. I know there are some tools out there that solve some of the problems with Component GUID generation but they aren't perfect. Still working on the perfect solution here since being partially wrong has very negative consequences. In any case, I think the leaders of the project and the users of the project are still mostly aligned... since we all just want a working solution. I'm curious if there are any topics that people feel there is a disconnect
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hi Guys, I've done some further testing. I upgraded to 3.0.3127 and tried that. I created a brand new ActiveX DLL in VB6, compiled it once and ran heat. I got interesting results: On Vista, Wix 3.0.3127, DLL compiled in Vista: I get no TypeLib entries. I get a lot of Class, Interface, RegistryValue entries, mostly children of the Component element. On Windows 2000, Wix 3.0.3127 (VirtualPC), same DLL file copied to it (DLL compiled in Vista): I get the correct TypeLib entry under File. I get TypeLib entries for the VB6RM under Component (I discard these anyway) I get almost no RegistryValue entries (not related to the DLL anyway, so discarded)! So, it looks as though something has changed between 3.0.2925 and 3.0.3127. It also seems Vista does something to hinder heat's interrogation/harvest. Note that I run heat as Administrator on Vista. I had a look at the heat harvesting extension code, only out of curiosity. Would you recommend to not run heat in Vista for ActiveX/COM DLLs? Cheers, David. _ From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Wednesday, 1 August 2007 5:28 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Mike. I appreciate the detailed explanations. It confirms what I thought was happening, but I was never quite sure. With DLLs, I never have no compatibility (chaos mode!). So no probs there. The thing is, with what you've said below regarding DLLs and compatibility should not affect the way heat harvests the TypeLibs? Also, from my previous post with the Vista/Windows 2000 on a new DLL compiled once, produced different results. I am now resorting to running heat on a Win2k Pro VPC to get my TypeLibs, Classes and Interfaces as this seems correct (although the heat output sometimes corrupts, and misses some required attributes). Regardless of compat mode (Binary or Project), I will need to run heat after a new compile, for example if I were to add new Classes to the project and if auto-increment is on for versioning. Cheers, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, 3 August 2007 7:38 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should endeavour not to break binary compatibility! As I recall - the product on which I use the feature requires binary compatibility, so a break of compatibility is not permitted - Visual Basic prompts to tell you that you have done so and would you like to continue? If you accept the break, it switches into project compatibility mode. In binary compatibility mode, it preserves class, interface and type library GUIDs. If you make a compatible change to an interface, it increments the type library's minor version number by 1, generates a new GUID for that interface, and typedefs the old interface (plus corresponding IID) to the new one. The new interface is laid out with the new methods at the end, regardless of where you put them in the class declaration. (You can see this in the OLE/COM Object Viewer that comes with VS 6.0). When registering, it registers the old interface GUID with a Forward registry key pointing to the new GUID (this feature doesn't seem to be documented anywhere!) In project compatibility mode, VB generates new GUIDs for modified interfaces, but preserves class and type library GUIDs. It lays out the interface in the class declaration order. It bumps the type library's major version by one. It does not forward the interface's old GUID to the new one (as it hasn't guaranteed binary compatibility by building the common methods in the same order). If you don't use any compatibility mode, VB generates everything from scratch every time. This is the 'chaos' mode which litters your registry every time you build the component. I would at least set project compatibility between builds which don't change the component's interfaces. If you use these modes it is important to ensure that you know when you've made a change to the interface of the component, so you can update the reference copy of the DLL. I would recommend using one of the compatibility modes so that your registration settings aren't changing between releases. Strictly, I think a changed registry key would be a different resource, meaning you've changed the make-up of the MSI component. The MSI component rules would suggest you should change the component's GUID, but then that has the knock-on effect that you should change the name or install path of the file resources too, otherwise you can get multiple components owning the same resources. Windows Installer tracks component references, not resources - uninstalling one of the components can lead to the resources being prematurely removed. This would perhaps suggest that your COM registry keys should actually be in different MSI components from the files that implement those COM classes, so that the keys can vary separately from the files. You then run into difficulty with minor versus major upgrades, since minor upgrades aren't allowed to modify the makeup of a feature - you can only add new child features. This would tend to suggest you can only modify your COM interfaces in a major upgrade! -- Mike Dimmick _ From: David Howell [mailto:[EMAIL PROTECTED] Sent: 01 August 2007 00:07 To: 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Thanks Mike. And I agree regarding your points. Unfortunately Binary Compatibility hasn't been set with these DLLs (and isn't really required for this project). Should I set Binary Compatibility anyway? If this is the cause, then what happens a change breaks Binary Compatibility (it does happen)? I've attached some of the output from heat. Cheers, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Wednesday, 1 August 2007 5:28 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, I see your predicament! Again, InstallShield has the ability to add files via wildcards etc (not that I'm promoting InstallShield, for the cost its pretty clunky), can't remember the exact term. A question I would ask is that if you have 16,000+ files that are being changed, added, deleted on a daily basis, with daily builds, is msi technology your best option? Without know the circumstances (e.g. is it an internal project only) perhaps there is an easier way? Sorry, getting off-topic. As for the future of heat, I have no idea. I'm just a user ;-) Good Luck! Dave. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 9:19 AM To: David Howell; Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo _ From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David
[WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix-3.0 and existing Merge Modules
Thanks. Much appreciated! I added the EnsureTable entries and now light does not produce any errors. David. Derek Cicerone wrote: 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
[WiX-users] Wix-3.0 and MDAC27ENU merge module
Hi Again, I am now trying to using the MDAC27ENU.MSM in my wix-3.0 project. Again, this msm was obtained from the InstallShield (or MS) website. When I run light, I receive the following warnings and errors: Microsoft (R) Windows Installer Xml Linker version 3.0.2015.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. .wxs(28) : warning LGHT1056 : The Directory table contains a row with primary key(s) 'DesktopFolder' which cannot be merged from the merge module 'C:\Merge Modules\mdac27enu.MSM'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. .wxs(28) : warning LGHT1056 : The Directory table contains a row with primary key(s) 'ProgramFilesFolder' which cannot be merged from the merge module 'C:\Merge Modules\mdac27enu.MSM'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. .wxs(28) : warning LGHT1056 : The Directory table contains a row with primary key(s) 'SystemFolder' which cannot be merged from the merge module 'C:\Merge Modules\mdac27enu.MSM'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. light.exe : error LGHT0204 : ICE99: The directory name: PrimaryVolumePath is the same as one of the MSI Public Properties and can cause unforeseen side effects. light.exe : error LGHT0204 : ICE99: The directory name: WindowsVolume is the same as one of the MSI Public Properties and can cause unforeseen side effects. If I don't include this particular merge module, I don't receive any warnings or errors. I understand I can ignore the warnings, however how do I overcome the errors? Cheers, David. - 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
