Automatic generation cannot pick up the intent of your settings, only the raw registry values. Often you'll find that self-registration will register many more settings than should really be made - for example, I have a COM DLL written in VB6, and its self-registration (as captured by tallow) registers all of VB6's settings as well! This is bad because Windows Installer will then most likely remove VB6's settings when my component is uninstalled.
Tallow v2 also didn't translate the path registered into a [#mydll.dll] reference, it left it as the raw path registered by the DLL, which could break on the end-user's machine depending on where it's captured from or where it's installed to. This DLL's self-registration actually failed when run as a limited user even when called by tallow (which gives proxy keys which should be writable by the calling user). I don't imagine that heat.exe is going to be any better at just capturing those changes that should be made, because it's a problem in the self-registration code, not in tallow or heat themselves. There are a number of 'bugs' on SourceForge entered against tallow or heat where it's actually the DLL's DllRegisterServer that isn't working properly when it doesn't find other registry entries (the proxy keys that the harvester tools create are empty). We recently had a case where the Windows Side-by-Side Win32 Assemblies technology couldn't find MSVCR80.DLL because its registry keys that record which assemblies are installed weren't present in the proxy keys. Basically I'm starting from a position that DllRegisterServer can't be trusted to do the right thing. I'm only going to use tallow or heat when I can't rely on knowing in advance what GUIDs are going to be generated by the development tool, which I don't with VB6 in any of its compatibility modes (when extending an interface), then I'm going to edit the resulting .wxs to eliminate anything that shouldn't be in there. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Appelgren Sent: 26 September 2006 09:58 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing COM components Thank you for your response. In what way would automatic generation be more fragile? Isn't all the information available for an automated approach? When it comes to converting one format to another the computer is usually better than me at getting it right. /Johan On 9/22/06, Mike Dimmick <[EMAIL PROTECTED]> wrote: > 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=DEV > DE > 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=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
