If I understand correctly, I believe Bob is saying that the component GUIDs in your installer should also be stable, which cannot currently be achieved with tallow.
The Windows Installer SDK suggests that if you change the contents of a component to be incompatible with previous versions of the component, you should change the component GUID. Otherwise you should keep the same component ID. However, if you do this, you should install the new component somewhere else, otherwise if both old and new components are installed, then the old component uninstalled, the new resource will be removed. That's the point of Rob's blog post. Quite how this interacts with assemblies installed to the GAC I'm not sure, since their install location depends on the strong name (version, culture, public key token). Should a new version of such an assembly be considered the same component as a previous version of the assembly, or a new component, since in fact a new version of an assembly is not automatically compatible with an old version (either publisher policy or .config file <bindingRedirect> must be used to force old clients to the new version)? This - putting the assembly in the GAC - is the recommended way of using COM Interop, BTW. You can use the /codebase flag to regasm (which will create a Codebase value) which allows COM Interop to use a non-GAC assembly, but I had some problems with this when using publisher policy to redirect some references from the non-GAC assembly to a newer version of primary interop assemblies (.NET-to-COM). This was done so that I didn't have to distribute every version of PIAs that had ever previously shipped, although this may not have been the best choice in retrospect. On the other hand, if you have multiple packages shipping these components installing into the GAC, you _must_ use the same installer component GUIDs, for the same reason as in Rob's blog post. -- Mike Dimmick -----Original Message----- From: Jarl Friis [mailto:[EMAIL PROTECTED] Sent: 04 October 2006 07:22 To: Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using a generated (by tallow.exe) fragment file in acomponent Bob Arnson <[EMAIL PROTECTED]> writes: > Jarl Friis wrote: >> appropriate <Component> element). I have expected to be able to avoid >> that for the standard reasons: >> It's time consuming. >> It does not require intelligence. >> It's error prone; In half-a-year, when I actually do make an >> > Problem is: It does require intelligence. See, for example: > http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx. This blog is discussing GUIDs for components, the guids that I talk about which is found in an output from "regasm.exe /regfile MyAssembly.dll" are COM-related GUIDs, such as class IDs and interface IDs. As Mike wrote these are new when (assembly name, version, culture, public key token) are changed, where version means value of [AssemblyVersion] or [ComCompatibleVersion] if present. hence I could limit the intelligence to control these parameters. If I got something wrong please enlight me, as I still don't see the requirement for intelligence in this task. Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis ------------------------------------------------------------------------- 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
