|
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] 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: <?xml version="1.0"
encoding="UTF-8" standalone="yes"?> <assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"> <assemblyIdentity
name="Microsoft.Tools.WindowsInstallerXml.Tools.Heat"
version="3.0.0.0" processorArchitecture="x86"
type="win32"></assemblyIdentity> <description>WiX
Toolset Harvester</description> <dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
version="8.0.50608.0" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly> </dependency> <trustInfo
xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security> </trustInfo> </assembly> 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 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] 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] 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] 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 <Merge> element to
merge in the Microsoft_VC80_CRT_x86.msm merge module. -- Mike Dimmick From: Steven
Chin [mailto:[EMAIL PROTECTED] I checked and I do have that policy file
and but I don’t think the redirect is working. <bindingRedirect
oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/> heat still cannot find MSVCR80.DLL. From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 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 Visual Studio 2005 Released version 8.0.50727.42 creates
output DLLs with a manifest that says it depends upon <assemblyIdentity
type="win32" name="Microsoft.VC80.CRT"
version="8.0.50608.0" 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
