If you're writing regular COM components in C++, you should manually edit the .wxs to maintain it. You know what is being created, you should replicate it. Reverse-engineering is fragile. Heat is intended for one-off use to generate an initial template .wxs file.
You can use the Class table to take away some of the pain of creating the registry entries, although Rob Mensching has some reservations with this apparently. I'm not quite sure why. The SDK currently calls out the Typelib table as having problems with rollback. Using the Class table creates an _advertised_ class, which I believe will potentially run repair when instantiated if the component's dependencies are the wrong versions (it also allows an administrator to advertise the package; when the class is instantiated it will be installed if only advertised, not yet installed - install-on-first-use). If registering .NET assemblies for COM Interop, use regasm to generate a .reg file and convert that to .wxs code. I don't think the Class table can be made to register a .NET assembly properly. If strong-name signing the assembly, install it to the GAC with the Assembly='.net' parameter; if not strong-name signing, use the /codebase option to regasm and set the CodeBase registry value in your .wxs file to the path you installed the DLL to. (This isn't really supported by the .NET Framework team for deployment but it does work). The .NET Framework will generate GUIDs based on a hash of the assembly identity and class or interface name, but you can control the GUIDs used with a [Guid] attribute, and this is better for keeping binary compatibility for COM. It may be better to avoid auto-generated class interfaces and actually define your interfaces yourself, applying a [Guid] attribute - I can't see a way to control the GUID of an auto-generated class interface. Use the [ClassInterface] attribute to turn off the automatic generation of a class interface. Alternatively you can use the [ComCompatibleVersion] attribute at the assembly level to indicate that all the classes and interfaces in the assembly are compatible with those in an earlier version of the assembly. This causes the Framework to use that version number when computing the GUIDs and therefore the GUIDs are stable across versions. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Appelgren Sent: 22 September 2006 13:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing COM components Hi, I'm looking at using wix to create an installer for an application that consists of both .NET assemblies and COM. As far as I can tell if I want to try wix3 I'm supposed to use heat to generate wxs files for the COM components and their primary interop assemblies. During the development there's probably going to be changes the the COM interfaces, mainly additions, how do I best capture those changes after the initial heat harvesting? Manually editing the wxs files seems very errorprone. Is there a better/recommended way to keep the wxs and COM interfaces in sync? /Johan ------------------------------------------------------------------------ - 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=DEVDE V _______________________________________________ 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.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users