[WiX-users] DLL failing to register on a SeflRegCost file
In my win64 installer, I have two .dll files that I have specified in my .wxs file as SelfRegCost="0". If I install the product to the local drive on my machine it will self register fine. If I install it to a directory on the network drive it gives me an "Error 1904.Module Y:\sandbox\mwcommgr.dll failed to register. HRESULT -2147312566. Contact your support personnel" message.Retrying the operation always fails. The HRESULT indicates TYPE_E_CANTLOADLIBRARY. Does anybody know why it fails? After I select to ignore the error and continue installing I can manually use regsvr32.exe to register the DLLs fine. Error only happens on machines which have .NET Framework installed. I wasn't able to use tallow on these DLLs like I did with my win32 installer so I was forced to use the SelfRegCost to register the DLL. Is there a permission or timeout going on here causing it not to load? I tried disabling the data execution prevention (DEP) in my BIOS and boot.ini file on my machine but that didn't help. Dependency walker complains about msjava.dll but it will install fine if I install to local drive which doesn't have msjava.dll on the machine. I can't find a win64 msjava.dll to stick in the project either to rule out that the dependency is causing this problem. Dependency walker had complained about MSVCR80.DLL too even though the install had run vcredist_x64.exe but I put MSVCR80.DLL into the project just to make sure that wasn't the problem so it doesn't complain about that anymore but it still can't register. Any help would be appreciated. Thanks. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DLL failing to register on a SeflRegCost file
The only messages were the same as the pop up message about Error 1904.Module Y:\sandbox\ -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Friday, February 27, 2009 9:55 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DLL failing to register on a SeflRegCost file Sounds like a dependency issue. Take a look at the event logs, are there any WinSxS errors reported? -Original Message- From: Steven Chin [mailto:steven.c...@mathworks.com] Sent: Friday, February 27, 2009 8:44 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] DLL failing to register on a SeflRegCost file In my win64 installer, I have two .dll files that I have specified in my .wxs file as SelfRegCost="0". If I install the product to the local drive on my machine it will self register fine. If I install it to a directory on the network drive it gives me an "Error 1904.Module Y:\sandbox\mwcommgr.dll failed to register. HRESULT -2147312566. Contact your support personnel" message. Retrying the operation always fails. The HRESULT indicates TYPE_E_CANTLOADLIBRARY. Does anybody know why it fails? After I select to ignore the error and continue installing I can manually use regsvr32.exe to register the DLLs fine. Error only happens on machines which have .NET Framework installed. I wasn't able to use tallow on these DLLs like I did with my win32 installer so I was forced to use the SelfRegCost to register the DLL. Is there a permission or timeout going on here causing it not to load? I tried disabling the data execution prevention (DEP) in my BIOS and boot.ini file on my machine but that didn't help. Dependency walker complains about msjava.dll but it will install fine if I install to local drive which doesn't have msjava.dll on the machine. I can't find a win64 msjava.dll to stick in the project either to rule out that the dependency is causing this problem. Dependency walker had complained about MSVCR80.DLL too even though the install had run vcredist_x64.exe but I put MSVCR80.DLL into the project just to make sure that wasn't the problem so it doesn't complain about that anymore but it still can't register. Any help would be appreciated. Thanks. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problems building WIX 2.0585 on a network drive - getting namespace name 'Extensions' does not exist in the class or namespace 'Microsoft.Tools.WindowsInstallerXml'
I have installed WIX to a network drive and am trying to build it. I took care of the System.Security.Permissions already by configuring .NET Framework 1.1 zone security for the local intranet to full trust but now I am running into this error: [loadtasks] Scanning assembly "Microsoft.Tools.WindowsInstallerXml.NAntTasks" for extensions. [csc] Compiling 3 files to 'S:\workspaces\schin.3rdparty\tmw\wix-src\Release\debug\WixMMCExtension.dll'. [csc] s:\workspaces\schin.3rdparty\tmw\wix-src\src\ext\MMCExtension\wixext\AssemblyInfo.cs(25,43): error CS0234: The type or namespace name 'Extensions' does not exist in the class or namespace 'Microsoft.Tools.WindowsInstallerXml' (are you missing an assembly reference?) BUILD FAILED - 1 non-fatal error(s), 1 warning(s) S:\workspaces\schin.3rdparty\tmw\wix-src\src\ext\mmcextension\mmcextension.build(71,6): External Program Failed: c:\WINNT\Microsoft.NET\Framework\v1.1.4322\csc.exe (return code was 1) I do not have this problem building WIX on the local drive. Does anybody know why this is happening? Thanks. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] tallow -s problem
When I run tallow –nologo –s mwcommgr.dll on a 32 bit machine it works fine but on a 64 bit machine I get: tallow.exe : fatal error TLLW0001: Index (zero based) must be greater than or eq ual to zero and less than the size of the argument list. Stack Trace: at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String fo rmat, Object[] args) at System.String.Format(IFormatProvider provider, String format, Object[] arg s) at System.String.Format(String format, Object arg0, Object arg1) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.Main(String[] args) The dll is a 32 bit dll. I have tried it with the 2.0.3309 and the 2.0.4415 binaries. Is this failing because it is a 32 bit dll? Thanks in advance for any 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=lnk&kid=120709&bid=263057&dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Where and why does this tallow Warning message come from?
When I run tallow -s on COM server files to create registry entries I get a warning at the end of the file after the XML such as: I18N Runtime Warning: Missing ICU data file detected while processing $(MWE_INSTALL)/bin/$(MWE_ARCH). Hint: Check for a misconfigured environment or installation. I don't see where this is generated in the source code and some of the message uses our environment parameters. How and why is this message being generated, what other warning messages might pop up and should I be worried about these warning messages that I am going to delete? Thanks. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat - Unable to locate component
I am running Wix 3.0 and heat.exe is returning the error pop-up “This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.” I eventually get another popup “Java Plug-in 1.5.0_07 in not installed properly” as well. On a different machine heat is returning MSVCP80.dll not found and later a jawt.dll not found pop up. I have .Net Framework SDK 2.0 Visual Studio 2005 and Platform SDK for Windows Server 2003 SP1 installed. Am I missing something? Thanks. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat - Unable to locate component
Thanks From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 11:00 AM To: Steven Chin Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat - Unable to locate component Steven Chin wrote: I am running Wix 3.0 and heat.exe is returning the error pop-up “This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.” I eventually get another popup “Java Plug-in 1.5.0_07 in not installed properly” as well. Heat tries to load DLLs to find their self-registration code. If the DLLs don't have their dependencies met, Heat can fail. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] heat cannot find MSVCR80.dll
Visual Studio 2005 Released version 8.0.50727.42 creates output DLLs with a manifest that says it depends upon Thus, heat can never find the MSVCR80.DLL version on the machine. Is there a way to make heat ignore the version dependency so as to take the latest version which is on the machine? Alternatively, is there a patch to VS 2005 to create correct manifest that indicates the correct version of VC80.CRT that it is using instead of a beta 2 version? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat cannot find MSVCR80.dll
I checked and I do have that policy file and but I don’t think the redirect is working. heat still cannot find MSVCR80.DLL. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:51 AM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Yes, it does indeed do this. However, you should have a publisher policy installed on your machine which redirects to 8.0.50727.42. I also have one which redirects to 8.0.50727.163. I'm running Windows XP SP2 with all current patches. Look in %SystemRoot%\WinSXS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773 and check that 8.0.50727.42.policy is present, and that the corresponding .cat file is also present. If not, reinstall the vcredist package. You can't just copy MSVCR80.DLL - you must use an installer which correctly installs the Win32 assemblies. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Chin Sent: 20 September 2006 19:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] heat cannot find MSVCR80.dll Visual Studio 2005 Released version 8.0.50727.42 creates output DLLs with a manifest that says it depends upon Thus, heat can never find the MSVCR80.DLL version on the machine. Is there a way to make heat ignore the version dependency so as to take the latest version which is on the machine? Alternatively, is there a patch to VS 2005 to create correct manifest that indicates the correct version of VC80.CRT that it is using instead of a beta 2 version? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat cannot find MSVCR80.dll
Hi Mike, Heat runs but many of our DLLs in our product have a manifest in them indicating this dependency. I noticed that we have at least a dozen DLLs with manifests requiring VC80.CRT" version="8.0.50608.0 but the pop-up error saying it cannot find MSVCR80.DLL only comes up 4 times. Maybe it is something else. We are not trying to include the Visual C Runtime in our package. How would we ignore this dependency from Heat? A pop up appears requiring user intervention and I am running heat from a perl script so as to have the build be automated. We are shipping a copy of the JRE we are using and when heat gets to those DLLs it causes a pop up 7 times indicating “Java Plug-in 1.5.0._07 is not installed properly”. I actually have this version of JDK installed on my system and use it with my IDE’s and Tomcat. Do I need the path to these DLLs in the system’s path for heat not to complain? From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 9:35 AM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Sorry, I was assuming that the problem was that heat.exe wouldn't run because MSVCR80.DLL was missing, but I see that Heat is a .NET Framework executable. I have to assume that you're trying to include the Visual C Runtime in your package. You should ignore this dependency from Heat. The supported method of redistributing the VS2005 C runtime within an MSI is to use a element to merge in the Microsoft_VC80_CRT_x86.msm merge module. -- Mike Dimmick From: Steven Chin [mailto:[EMAIL PROTECTED] Sent: 21 September 2006 14:11 To: Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll I checked and I do have that policy file and but I don’t think the redirect is working. heat still cannot find MSVCR80.DLL. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:51 AM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Yes, it does indeed do this. However, you should have a publisher policy installed on your machine which redirects to 8.0.50727.42. I also have one which redirects to 8.0.50727.163. I'm running Windows XP SP2 with all current patches. Look in %SystemRoot%\WinSXS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773 and check that 8.0.50727.42.policy is present, and that the corresponding .cat file is also present. If not, reinstall the vcredist package. You can't just copy MSVCR80.DLL - you must use an installer which correctly installs the Win32 assemblies. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Chin Sent: 20 September 2006 19:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] heat cannot find MSVCR80.dll Visual Studio 2005 Released version 8.0.50727.42 creates output DLLs with a manifest that says it depends upon Thus, heat can never find the MSVCR80.DLL version on the machine. Is there a way to make heat ignore the version dependency so as to take the latest version which is on the machine? Alternatively, is there a patch to VS 2005 to create correct manifest that indicates the correct version of VC80.CRT that it is using instead of a beta 2 version? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat cannot find MSVCR80.dll
Thanks for the info Mike. I think it has more to do with the manifests in the DLLs and lack of manifests in some. If I remove a manifest from a DLL that has one of the VC80.CRT dependencies then I will get more of these pop ups. I know that I have 34 DLLs that have VC80.CRT dependencies that don’t have manifests but if I try to add the manifests to the DLLs I will get 54 pop up errors. Because of this problem I am going to try using tallow and the 2.0 tools. Tallow has no problems with the DLLS and their manifest or no manifests at this time. Thanks again. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 2:03 PM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Heat is trying to extract self-registration information from the DLLs. To do this, it uses the RegOverridePredefKey API to get a clean version of the HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE keys so that the actual machine environment isn't affected, and to simplify working out what was written. It then calls the DLL's DllSelfRegister entry point to get it to perform its self-registration to the surrogate keys. From this it fills out the Class and Registry tables as appropriate. Unfortunately, these keys are completely clean, and various self-registration code will fail if some other registry keys and values they depend on are missing. Here, it's that the side-by-side code in the Windows loader is looking for registry information about the side-by-side DLLs, and failing to find it, and presumably that Sun's self-registration code is looking for the same. If you're shipping C++ DLLs you should know what the correct GUIDs are for the classes and type libraries - they'll be in your source code somewhere. Author this manually, don't use heat - that's for tools which autogenerate GUIDs like VB6. Also, heat is something intended to be run once to capture an initial script, it's not really meant for running on every build. As for the Java runtime, if you're shipping it yourself, use Sun's installer. Then Sun can service it correctly. Always ship third-party components according to the developer's guidance. The component rules mean that unless you're extremely careful, you'll end up breaking someone else's application when yours is uninstalled. (Hopefully third-time-lucky) -- Mike Dimmick From: Steven Chin [mailto:[EMAIL PROTECTED] Sent: Thu 21/09/2006 15:30 To: Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Hi Mike, Heat runs but many of our DLLs in our product have a manifest in them indicating this dependency. I noticed that we have at least a dozen DLLs with manifests requiring VC80.CRT" version="8.0.50608.0 but the pop-up error saying it cannot find MSVCR80.DLL only comes up 4 times. Maybe it is something else. We are not trying to include the Visual C Runtime in our package. How would we ignore this dependency from Heat? A pop up appears requiring user intervention and I am running heat from a perl script so as to have the build be automated. We are shipping a copy of the JRE we are using and when heat gets to those DLLs it causes a pop up 7 times indicating “Java Plug-in 1.5.0._07 is not installed properly”. I actually have this version of JDK installed on my system and use it with my IDE’s and Tomcat. Do I need the path to these DLLs in the system’s path for heat not to complain? From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 9:35 AM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Sorry, I was assuming that the problem was that heat.exe wouldn't run because MSVCR80.DLL was missing, but I see that Heat is a .NET Framework executable. I have to assume that you're trying to include the Visual C Runtime in your package. You should ignore this dependency from Heat. The supported method of redistributing the VS2005 C runtime within an MSI is to use a element to merge in the Microsoft_VC80_CRT_x86.msm merge module. -- Mike Dimmick From: Steven Chin [mailto:[EMAIL PROTECTED] Sent: 21 September 2006 14:11 To: Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll I checked and I do have that policy file and but I don’t think the redirect is working. heat still cannot find MSVCR80.DLL. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 4:51 AM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Yes, it does indeed do this. However, you should have a publisher policy installed on your machine which redirects to 8.0.50727.42
Re: [WiX-users] heat cannot find MSVCR80.dll
Hi Mike, We run heat for each build because there are dozens of groups that add or subtract files from the different subcomponents for this one product and they don’t tell the install group about them when they add or subtract a file from the product. Out of the 9789 files only a small fraction of them are DLLs. I have a perl script that changes certain parameters in the XML that can’t be done by variables or selected by if branches and any important GUIDs are in an include file as variables. I replaced the manifest with yours and I still got the same four pop ups. I wish the error message indicated which DLLs were causing the pop ups. When I have time I will see if I can get an environment to build 3.0 and see if I can debug this. Thanks for your help. From: Mike Holcomb [mailto:[EMAIL PROTECTED] Sent: Friday, September 29, 2006 2:12 PM To: Steven Chin; Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] heat cannot find MSVCR80.dll Why are you running heat.exe each time you build? I would think you just run it once, and then modify the source files to fit into your build environment. I was able to get heat working with DLLs that had a dependency on MSVCR80.dll with a heat.exe.manifest that contains the following: WiX Toolset Harvester Place that beside heat.exe and have the 8.0 vcredist installed, and it should work. Thanks, Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Chin Sent: Friday, September 29, 2006 9:56 AM To: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] heat cannot find MSVCR80.dll Thanks for the info Mike. I think it has more to do with the manifests in the DLLs and lack of manifests in some. If I remove a manifest from a DLL that has one of the VC80.CRT dependencies then I will get more of these pop ups. I know that I have 34 DLLs that have VC80.CRT dependencies that don’t have manifests but if I try to add the manifests to the DLLs I will get 54 pop up errors. Because of this problem I am going to try using tallow and the 2.0 tools. Tallow has no problems with the DLLS and their manifest or no manifests at this time. Thanks again. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 2:03 PM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Heat is trying to extract self-registration information from the DLLs. To do this, it uses the RegOverridePredefKey API to get a clean version of the HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE keys so that the actual machine environment isn't affected, and to simplify working out what was written. It then calls the DLL's DllSelfRegister entry point to get it to perform its self-registration to the surrogate keys. From this it fills out the Class and Registry tables as appropriate. Unfortunately, these keys are completely clean, and various self-registration code will fail if some other registry keys and values they depend on are missing. Here, it's that the side-by-side code in the Windows loader is looking for registry information about the side-by-side DLLs, and failing to find it, and presumably that Sun's self-registration code is looking for the same. If you're shipping C++ DLLs you should know what the correct GUIDs are for the classes and type libraries - they'll be in your source code somewhere. Author this manually, don't use heat - that's for tools which autogenerate GUIDs like VB6. Also, heat is something intended to be run once to capture an initial script, it's not really meant for running on every build. As for the Java runtime, if you're shipping it yourself, use Sun's installer. Then Sun can service it correctly. Always ship third-party components according to the developer's guidance. The component rules mean that unless you're extremely careful, you'll end up breaking someone else's application when yours is uninstalled. (Hopefully third-time-lucky) -- Mike Dimmick From: Steven Chin [mailto:[EMAIL PROTECTED] Sent: Thu 21/09/2006 15:30 To: Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat cannot find MSVCR80.dll Hi Mike, Heat runs but many of our DLLs in our product have a manifest in them indicating this dependency. I noticed that we have at least a dozen DLLs with manifests requiring VC80.CRT" version="8.0.50608.0 but the pop-up error saying it cannot find MSVCR80.DLL only comes up 4 times. Maybe it is something else. We are not trying to include the Visual C Runtime in our package. How would we ignore this dependency from Heat? A pop up appea
[WiX-users] light.exe hangs
I am running light.exe from binaries-2.0.3309.0.zip and it seems hangs when trying to build a 125 MB merge module. I was running with -v0 and -notidy options and could see that after all the Cabbing the last thing it logged was: Importing streams. Importing binary stream from 'C:\WINNT\system32\rpcrt4.dll'. Importing binary stream from 'C:\WINNT\system32\oleaut32.dll'. Importing binary stream from 'C:\WINNT\system32\msvcrt.dll'. Importing binary stream from 'C:\WINNT\system32\gdi32.dll'. Importing binary stream from 'C:\WINNT\system32\comdlg32.dll'. Importing binary stream from 'C:\WINNT\system32\odbc32.dll'. Importing binary stream from 'C:\WINNT\system32\kernel32.dll'. Importing binary stream from 'C:\WINNT\system32\ntdll.dll'. Importing binary stream from 'C:\WINNT\system32\shlwapi.dll'. Importing binary stream from 's:/Ainstall/matlab/pbr/mcr/../../install/bin/win32 \frameworktest\frameworktest.dll'. Importing binary stream from 'C:\WINNT\system32\advapi32.dll'. Importing binary stream from 'C:\WINNT\system32\odbccp32.dll'. Importing binary stream from 's:/Ainstall/matlab/pbr/mcr/../../install/bin/win32 \uninstallmcrpath\uninstallmcrpath.dll'. Importing binary stream from 'C:\WINNT\system32\shell32.dll'. Importing binary stream from 'C:\WINNT\system32\user32.dll'. Importing binary stream from 'C:\WINNT\system32\ole32.dll'. Importing binary stream from 'C:\WINNT\system32\msi.dll'. It never got to print out "Laying out media." It also may have hung the machine since nothing is responding at this point. This only happens sometimes. It works fine on other machines. Has anyone seen this before? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] light.exe hangs
Thanks for the catch Mike. I originally put those dlls in there because they were needed by my make files to build my custom DLLs. I thought putting them in the merge module would ensure my DLL would have them available if they weren't and these would be used if it wasn't on the system. We don't support Windows NT so I thought I would be safe with Windows File Protection not allowing them to be put down and force the installer to use find the ones in the system. You are correct that I should not have them in there so I will take them out. I haven't used a later version of WiX since the last time we did a release, since it wasn't broke I didn't feel the need to upgrade to the newer one. I will see how the latest version of Wix works and see if we can use that. From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 5:56 PM To: Steven Chin; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] light.exe hangs Er... I really hope that message doesn't mean what I think it means. Why the heck are you including a ton of operating system binaries in your merge module? None of them will install on a modern machine, because Windows File Protection will prevent them being installed; on a Windows NT 4.0 machine, you'll kill it stone dead if you try to replace ntdll.dll (which must be an exact match with the kernel build, or the system likely won't boot). There are a few updated components that can be installed on NT 4.0, for example OLEAUT32, but if you need them, you should be using the merge modules (generally from Visual Studio 6 SP6). I believe you should use a element under the element to indicate that your merge module requires these other modules. Note that if you're using VS6SP6 merge modules, see http://installsite.org/pages/en/bugs_msi.htm#wimsm for information on known issues with these merge modules. Also, that version of light is extremely old - the current version on the SourceForge project site is 2.0.4820.0 (15 months newer) and the current 2.0 weekly is 2.0.4908.0 (released on Monday). -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Chin Sent: 11 January 2007 19:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] light.exe hangs I am running light.exe from binaries-2.0.3309.0.zip and it seems hangs when trying to build a 125 MB merge module. I was running with -v0 and -notidy options and could see that after all the Cabbing the last thing it logged was: Importing streams. Importing binary stream from 'C:\WINNT\system32\rpcrt4.dll'. Importing binary stream from 'C:\WINNT\system32\oleaut32.dll'. Importing binary stream from 'C:\WINNT\system32\msvcrt.dll'. Importing binary stream from 'C:\WINNT\system32\gdi32.dll'. Importing binary stream from 'C:\WINNT\system32\comdlg32.dll'. Importing binary stream from 'C:\WINNT\system32\odbc32.dll'. Importing binary stream from 'C:\WINNT\system32\kernel32.dll'. Importing binary stream from 'C:\WINNT\system32\ntdll.dll'. Importing binary stream from 'C:\WINNT\system32\shlwapi.dll'. Importing binary stream from 's:/Ainstall/matlab/pbr/mcr/../../install/bin/win32 \frameworktest\frameworktest.dll'. Importing binary stream from 'C:\WINNT\system32\advapi32.dll'. Importing binary stream from 'C:\WINNT\system32\odbccp32.dll'. Importing binary stream from 's:/Ainstall/matlab/pbr/mcr/../../install/bin/win32 \uninstallmcrpath\uninstallmcrpath.dll'. Importing binary stream from 'C:\WINNT\system32\shell32.dll'. Importing binary stream from 'C:\WINNT\system32\user32.dll'. Importing binary stream from 'C:\WINNT\system32\ole32.dll'. Importing binary stream from 'C:\WINNT\system32\msi.dll'. It never got to print out "Laying out media." It also may have hung the machine since nothing is responding at this point. This only happens sometimes. It works fine on other machines. Has anyone seen this before? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
