Re: [WiX-users] COM registration weirdness
Is this code significantly different than what is in heat? Can we improve heat as well? I didn't look at heat's sourcecode when I wrote my utility, but it uses the same registry redirection technique. I've looked at RegistryHarvester.cs and I can't see where it deals with the Class/TypeLib tables. I guess it can't be too hard to modify the code to filter out the appropriate VB6 entries that I listed. Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
I appreciate the feedback. In the short term, I've added the SelfRegCost attribute to the file tags for the non-.Net COM DLLs, and that seems to work fine. As for the DLLs themselves, I have no idea what langauge they were written in. We're using them within a legacy VB6 app, and wiring in new functionality with .Net COM DLLs. The non-.Net stuff is all third party things that we've licensed, so I have no source code for that stuff. It's quite possible that somehting is happening outside of the norm with them guys, since none of them seem to be what I would call high-quality software products. So, on the the .Net COM Interop registration... any idea why the basic output from heat wouldn't be doing the trick? What might it be missing? Should I just do a regasm /reg and then convert that to WiX code? Thanks, Troy On Mon, Sep 29, 2008 at 9:15 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] , Rob Mensching [EMAIL PROTECTED] writes: If anyone does figure it out, it'd be good to understand what is going on. I don't know VB (let alone VB6) and things work great for my C++/ATL based COM objects. By the time its a COM object, VB6 or C++ it doesn't make any difference. I would run RegMon and FileMon while you hand register the COM object on a system where its never been registered before. Then check to make sure it isn't doing things inside its DllRegisterServer that its not supposed to be doing (through filemon). Its only supposed to be setting registry values that deal with COM registration, but sometimes people get lazy and do all sorts of crazy stuff in there. I don't know if VB6 lets you control that entry point or just does it for you based on the kind of project you made. At any rate, all that's happening when you register the COM object with Windows Installer is that its handling those registry entries for you. If you duplicate all of the registry entries, then it should work fine. The key is going to be running some sort of utility that can tell you how that component is interacting with the system when its DllRegisterServer entry point is called. Ultimately you could (ugh) step through the assembly code as it executes to identify the missing piece. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.xmission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
It's both. The application is written in VB6. It uses COM DLLs written in various languages, including C++, VB6, and .NET. The installer needs to be able to register all of these things. The non-.Net COM DLLs seem to be doing alright with the SelfRegCost attribute applied, but now the .Net DLLs are having trouble. I've tried various ways to get them working. What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib actions. I opened the MSI up in ORCA, and realized that they are not in my InstallExecuteSequence table. That makes sense why it wasn't working with Class/Progid etc elements in the components. The action was never getting called that dealt with those things. I assumed those actions would be included, and that I didn't to explicitly add them. I'm going to give it a try with the correct methodology again, this time with the correct actions in the sequence and see if that does the trick. If so, I can get rid of the self registration stuff, AND the duct tape batch file full of regasm calls. Conveniently, re-ghosting the test box and building the installer take about the same amount of time.. sigh This application is a beast, and the installer has to tame it. What a project At least I have a nice view of downtown Portland at night from the 11th floor of this building. Thanks, Troy On Tue, Sep 30, 2008 at 8:10 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: So, in my efforts to resolve the .Net COM issues, [...] Earlier, this thread was talking about registering a VB6 control. Now you're talking about registering a .NET assembly for COM interop. So which is it? I've registered .NET assemblies for COM interop with no problems by taking the output of /regfile. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.xmission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
0. Are you sure you needed to add all those actions? They should have been added for you automatically if you are using the advertised tables. Also, you don't need to add Sequence numbers to have a standard action added at the standard location. Just the name should be sufficient... however, none of that should be necessary. 1. I hope that candle provided a reasonable error message when the Class/@Server was missing. Did it? 2. Yeah, that is something heat does not do correctly today. Heat should get the @Server right in the future as well... heat needs work. smile/ -Original Message- From: Troy Howard [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 23:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness Ok, I found a process that works... First, I had to explicitly add: InstallExecuteSequence UnregisterClassInfo Sequence=2700 / UnregisterProgIdInfo Sequence=2900/ UnregisterTypeLibraries Sequence=2300/ RegisterClassInfo Sequence='4600' / RegisterProgIdInfo Sequence='4800' / RegisterTypeLibraries Sequence='5500' / /InstallExecuteSequence then for each .net com dll, i ran heat against it to generate a wxs. I then fixedup those wxs files in the following manner: 1. Wrap the Class/ProgID/etc tags inside the File tag so that class/@server gets set 2. Update the registry values that referred to mscoree.dll so that they each have a unique id in the Id attribute. That combination get me functioning .Net COM DLLs, and now that I fully understand what's happening, it makes sense. The default sequence doesn't include the com registration actions that read the class table/etc. So those have to be added. The heat output doesn't nest the class tags in the file tag, so server attribute doesn't know what it's target is. The registry values for mscoree.dll are in conflict with the autogenerated ones made form the class tag, because they both use autogenerated ids, which are a hash of componentId, root, key, and name... And so they need to be differentiate by assigning a unique id. I'm quite relieved I got it worked out. Thanks, Troy On Tue, Sep 30, 2008 at 9:51 PM, Troy Howard [EMAIL PROTECTED] wrote: It's both. The application is written in VB6. It uses COM DLLs written in various languages, including C++, VB6, and .NET. The installer needs to be able to register all of these things. The non-.Net COM DLLs seem to be doing alright with the SelfRegCost attribute applied, but now the .Net DLLs are having trouble. I've tried various ways to get them working. What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib actions. I opened the MSI up in ORCA, and realized that they are not in my InstallExecuteSequence table. That makes sense why it wasn't working with Class/Progid etc elements in the components. The action was never getting called that dealt with those things. I assumed those actions would be included, and that I didn't to explicitly add them. I'm going to give it a try with the correct methodology again, this time with the correct actions in the sequence and see if that does the trick. If so, I can get rid of the self registration stuff, AND the duct tape batch file full of regasm calls. Conveniently, re-ghosting the test box and building the installer take about the same amount of time.. sigh This application is a beast, and the installer has to tame it. What a project At least I have a nice view of downtown Portland at night from the 11th floor of this building. Thanks, Troy On Tue, Sep 30, 2008 at 8:10 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: So, in my efforts to resolve the .Net COM issues, [...] Earlier, this thread was talking about registering a VB6 control. Now you're talking about registering a .NET assembly for COM interop. So which is it? I've registered .NET assemblies for COM interop with no problems by taking the output of /regfile. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.xmission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Rob Mensching [EMAIL PROTECTED] writes: MSXML3 [I think] used to have SelfReg and it a ccounted for a percentage point or two of installation failures for Office... that was lot of money wasted on SelfReg. Wow. That is an awesome data point! -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Bob Arnson [EMAIL PROTECTED] writes: Neil Sleightholm wrote: My untested theory is that when you call DllRegisterServer on a VB6 DLL it either calls DllRegisterServer on MSVBVM60.dll or the code from it is embedded into the VB6 dll. In my experience, self-reg code gets extra-aggressive in response to bug reports to respond to symptoms rather than fixing underlying causes. I would agree with that 100%. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
First, you should not be packaging someone else's resources in your MSI. You should be getting a Merge Module that has all of the COM and DLL and most importantly the *correct* Component GUIDs. That's what Merge Modules were designed for. You might want to tell Microsoft that and get a merge module for RICHTX32.OCX and the latest version of some of their OCX's :-) rantBack in the real world I have found very few third party components come with merge modules and the ones that do, CrystalReports for example, are so buggy they are virtually unusable./rant Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: Should I just do a regasm /reg and then convert that to WiX code? That's what I've done in the past and it worked just fine. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: This application is a beast, and the installer has to tame it. What a project At least I have a nice view of downtown Portland at night from the 11th floor of this building. When I removed self-reg components, it was on a large application that installed thousands of files and pretty much everything else that you could install except fonts. It had lots of custom actions and a couple of them attempted to register assemblies with regasm instead of using the Registry table in the MSI. Well, this approach just caused lots of problems over time. One by one, all the problems were eliminated by moving the registration to the Registry table and not attempting to run registration code at install time. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Neil wrote:
I have tried a
few times to remove the unrelated code and never successfully
got the component to work or to leave the machine working on
uninstall. Have you ever generated the WiX registry code for
VB6 COM component? Has anyone?
Neil,
I have. I wrote a custom build task that extracts the registration
information at build time [1].
The registration entry point is called with some registry redirection in
place, and then I harvest the created registry entries removing the
following:
- CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
- Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
{000204EF---C000-0046}, plus any Interfaces that
reference these two type libraries.
This works for me.
regards,
John
[1] I know this is very much frowned upon, but I always create major
upgrades and don't create patches... YMMV
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Regarding SelfReg, or not I'm not completely sure I drink the Kool-Aid
on this one. So, I understand that SelfRegCost violates transactability
rules (spell checker says transactability is not a word shrug) due to MSI
and how it handles that... But what then IS the recommended way to deal with
the scenario where you have a COM DLL that you didn't write and can't get a
different version of that does some wacky stuff in DllRegisterServer...
How should those DLLs be handled? If we use SelfRegCost, everything works
after a successful install, but at a rollback, or uninstall, there's no way
to undo it. What if there were CAs for RegSvr32/RegAsm, that were built-in
and easy to use, and then you could make sure that was happening correctly,
at the right times? This is similar to the duct-tape batch file solution
(one batch for install, one for uninstall), or bunch of QtExec actions to
those programs with appropriate cmdline params. The main thing seems to be
that they are scheduled at the right time, so that uninstall calls regsvr32
/u.
I understand that modifying system state outside of MSI's system is a
no-no, but if you're stuck with a DLL that operates that way, so be it.
Regarding the situation that I just finished with, I would like to have a
deeper understanding of the term Advertise that is being used in WiX/MSI
contexts. What does this mean exactly, in relation to COM DLLs?
Rob M mentioned that: ... those actions are only necessary if you are using
the Advertised features of COM registration otherwise it's all just Registry
rows.
I read the blog post he linked to about why advertising is bad, but it lacks
a definition of what advertising is. Does that definition exist somewhere?
With context regarding COM?
Thanks,
Troy
On Thu, Oct 2, 2008 at 1:09 AM, John Hall
[EMAIL PROTECTED]wrote:
Neil wrote:
I have tried a
few times to remove the unrelated code and never successfully
got the component to work or to leave the machine working on
uninstall. Have you ever generated the WiX registry code for
VB6 COM component? Has anyone?
Neil,
I have. I wrote a custom build task that extracts the registration
information at build time [1].
The registration entry point is called with some registry redirection in
place, and then I harvest the created registry entries removing the
following:
- CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
- Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
{000204EF---C000-0046}, plus any Interfaces that
reference these two type libraries.
This works for me.
regards,
John
[1] I know this is very much frowned upon, but I always create major
upgrades and don't create patches... YMMV
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Regarding SelfReg, or not I'm not completely sure I drink the Kool-Aid on this one. So, I understand that SelfRegCost violates transactability rules (spell checker says transactability is not a word shrug) due to MSI and how it handles that... But what then IS the recommended way to deal with the scenario where you have a COM DLL that you didn't write and can't get a different version of that does some wacky stuff in DllRegisterServer... How should those DLLs be handled? If we use SelfRegCost, everything works after a successful install, but at a rollback, or uninstall, there's no way to undo it. What if there were CAs for RegSvr32/RegAsm, that were built-in and easy to use, and then you could make sure that was happening correctly, at the right times? This is similar to the duct-tape batch file solution (one batch for install, one for uninstall), or bunch of QtExec actions to those programs with appropriate cmdline params. The main thing seems to be that they are scheduled at the right time, so that uninstall calls regsvr32 /u. I understand that modifying system state outside of MSI's system is a no-no, but if you're stuck with a DLL that operates that way, so be it. Troy, If I remember correctly, you also get into other problems if the DLL has dependencies on other DLLs that you're installing, particularly those put into the SXS store - they're not available until after InstallFinalize. The most obvious case here is the VC runtime. Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Here is an example: http://www.x2systems.com/files/ocx.txt. The objects I have most problems with are not my own, they are redistributable components and often Microsoft ones. I think John Hall may have found the relevant bits to remove, all I need to do now is find a way of getting that into Heat. Neil -Original Message- From: Richard [mailto:[EMAIL PROTECTED] Sent: 01 October 2008 23:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: Richard The answer to that is pretty simple -- you ignore anything that's not related to your component. I think you are missing the point (or I am), how do I know it is not related? Well, the things that are related to your COM object are laid out in the COM specification. I'm assuming since its your COM object, that you know the CLSIDs, IIDs, etc., that go with your object. In VB6 you don't edit the COM registration so you don't know the details. True, but you do decide the ProgId that exposes your COM object and for the places where COM is registering a server, it is coupled to the filename of the DLL containing the server, so you can link things back that way. There will also be a type library associated with your COM object, to support VB6's dispinterface style late binding. The type library for a VB6 COM object is always contained in the DLL of the object, so that's also coupled back to your object through the filename. I have a fairly simple ocx and heat generates 182 lines of WiX code for it! Can you post a URL to the generated WiX code from heat? I'd like to see what kind of stuff its generating. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
That's one of many reasons SelfReg is evil. I really should write the blog entry about this... there are just so many facets it'll take forever. sigh/ -Original Message- From: John Hall [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2008 03:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness Regarding SelfReg, or not I'm not completely sure I drink the Kool-Aid on this one. So, I understand that SelfRegCost violates transactability rules (spell checker says transactability is not a word shrug) due to MSI and how it handles that... But what then IS the recommended way to deal with the scenario where you have a COM DLL that you didn't write and can't get a different version of that does some wacky stuff in DllRegisterServer... How should those DLLs be handled? If we use SelfRegCost, everything works after a successful install, but at a rollback, or uninstall, there's no way to undo it. What if there were CAs for RegSvr32/RegAsm, that were built-in and easy to use, and then you could make sure that was happening correctly, at the right times? This is similar to the duct-tape batch file solution (one batch for install, one for uninstall), or bunch of QtExec actions to those programs with appropriate cmdline params. The main thing seems to be that they are scheduled at the right time, so that uninstall calls regsvr32 /u. I understand that modifying system state outside of MSI's system is a no-no, but if you're stuck with a DLL that operates that way, so be it. Troy, If I remember correctly, you also get into other problems if the DLL has dependencies on other DLLs that you're installing, particularly those put into the SXS store - they're not available until after InstallFinalize. The most obvious case here is the VC runtime. Regards, John - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
First, you should not be packaging someone else's resources in your MSI. You
should be getting a Merge Module that has all of the COM and DLL and most
importantly the *correct* Component GUIDs. That's what Merge Modules were
designed for. If you're not getting a Merge Module and the producer shares the
resource with other people you're now very much in jeopardy of entering DLL
Hell.
Second, if you're screwed then you're screwed. Personally, I always start
pushing for crappy resources to get pushed out of the product. Setup failures
are deadly for customers. They almost always turn into support calls (and
everyone I've talked to, support calls are an undesirable expense). Of course,
sometimes the developer on setup doesn't get to make that call. smile/
If you want people to help brainstorm how to work around a particular issue
then understand that most people here will suggest fixing the core issue rather
than avoiding it. So be very clear that you've exhausted all options and be
very specific about what you're trying to accomplish. Workaround suggestions
are often very specific to the scenario so if you're not clear the suggestions
you get might not work... or not work the way you want when you try to update
your app some months later. smile/
Finally, advertising is generally considered part of assigning/publishing in
Windows Installer. The MSI SDK has stuff about it. Based on my experience,
advertising shortcuts and extensions works well but COM advertising has some a
rather unpleasant user experience and side effects.
-Original Message-
From: Troy Howard [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 02:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness
Regarding SelfReg, or not I'm not completely sure I drink the Kool-Aid
on this one. So, I understand that SelfRegCost violates transactability
rules (spell checker says transactability is not a word shrug) due to MSI
and how it handles that... But what then IS the recommended way to deal with
the scenario where you have a COM DLL that you didn't write and can't get a
different version of that does some wacky stuff in DllRegisterServer...
How should those DLLs be handled? If we use SelfRegCost, everything works
after a successful install, but at a rollback, or uninstall, there's no way
to undo it. What if there were CAs for RegSvr32/RegAsm, that were built-in
and easy to use, and then you could make sure that was happening correctly,
at the right times? This is similar to the duct-tape batch file solution
(one batch for install, one for uninstall), or bunch of QtExec actions to
those programs with appropriate cmdline params. The main thing seems to be
that they are scheduled at the right time, so that uninstall calls regsvr32
/u.
I understand that modifying system state outside of MSI's system is a
no-no, but if you're stuck with a DLL that operates that way, so be it.
Regarding the situation that I just finished with, I would like to have a
deeper understanding of the term Advertise that is being used in WiX/MSI
contexts. What does this mean exactly, in relation to COM DLLs?
Rob M mentioned that: ... those actions are only necessary if you are using
the Advertised features of COM registration otherwise it's all just Registry
rows.
I read the blog post he linked to about why advertising is bad, but it lacks
a definition of what advertising is. Does that definition exist somewhere?
With context regarding COM?
Thanks,
Troy
On Thu, Oct 2, 2008 at 1:09 AM, John Hall
[EMAIL PROTECTED]wrote:
Neil wrote:
I have tried a
few times to remove the unrelated code and never successfully
got the component to work or to leave the machine working on
uninstall. Have you ever generated the WiX registry code for
VB6 COM component? Has anyone?
Neil,
I have. I wrote a custom build task that extracts the registration
information at build time [1].
The registration entry point is called with some registry redirection in
place, and then I harvest the created registry entries removing the
following:
- CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
- Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
{000204EF---C000-0046}, plus any Interfaces that
reference these two type libraries.
This works for me.
regards,
John
[1] I know this is very much frowned upon, but I always create major
upgrades and don't create patches... YMMV
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
Re: [WiX-users] COM registration weirdness
Is this code significantly different than what is in heat? Can we improve heat
as well?
-Original Message-
From: John Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 01:09
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness
Neil wrote:
I have tried a
few times to remove the unrelated code and never successfully
got the component to work or to leave the machine working on
uninstall. Have you ever generated the WiX registry code for
VB6 COM component? Has anyone?
Neil,
I have. I wrote a custom build task that extracts the registration
information at build time [1].
The registration entry point is called with some registry redirection in
place, and then I harvest the created registry entries removing the
following:
- CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
- Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
{000204EF---C000-0046}, plus any Interfaces that
reference these two type libraries.
This works for me.
regards,
John
[1] I know this is very much frowned upon, but I always create major
upgrades and don't create patches... YMMV
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Ok, I found a process that works... First, I had to explicitly add: InstallExecuteSequence UnregisterClassInfo Sequence=2700 / UnregisterProgIdInfo Sequence=2900/ UnregisterTypeLibraries Sequence=2300/ RegisterClassInfo Sequence='4600' / RegisterProgIdInfo Sequence='4800' / RegisterTypeLibraries Sequence='5500' / /InstallExecuteSequence then for each .net com dll, i ran heat against it to generate a wxs. I then fixedup those wxs files in the following manner: 1. Wrap the Class/ProgID/etc tags inside the File tag so that class/@server gets set 2. Update the registry values that referred to mscoree.dll so that they each have a unique id in the Id attribute. That combination get me functioning .Net COM DLLs, and now that I fully understand what's happening, it makes sense. The default sequence doesn't include the com registration actions that read the class table/etc. So those have to be added. The heat output doesn't nest the class tags in the file tag, so server attribute doesn't know what it's target is. The registry values for mscoree.dll are in conflict with the autogenerated ones made form the class tag, because they both use autogenerated ids, which are a hash of componentId, root, key, and name... And so they need to be differentiate by assigning a unique id. I'm quite relieved I got it worked out. Thanks, Troy On Tue, Sep 30, 2008 at 9:51 PM, Troy Howard [EMAIL PROTECTED] wrote: It's both. The application is written in VB6. It uses COM DLLs written in various languages, including C++, VB6, and .NET. The installer needs to be able to register all of these things. The non-.Net COM DLLs seem to be doing alright with the SelfRegCost attribute applied, but now the .Net DLLs are having trouble. I've tried various ways to get them working. What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib actions. I opened the MSI up in ORCA, and realized that they are not in my InstallExecuteSequence table. That makes sense why it wasn't working with Class/Progid etc elements in the components. The action was never getting called that dealt with those things. I assumed those actions would be included, and that I didn't to explicitly add them. I'm going to give it a try with the correct methodology again, this time with the correct actions in the sequence and see if that does the trick. If so, I can get rid of the self registration stuff, AND the duct tape batch file full of regasm calls. Conveniently, re-ghosting the test box and building the installer take about the same amount of time.. sigh This application is a beast, and the installer has to tame it. What a project At least I have a nice view of downtown Portland at night from the 11th floor of this building. Thanks, Troy On Tue, Sep 30, 2008 at 8:10 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: So, in my efforts to resolve the .Net COM issues, [...] Earlier, this thread was talking about registering a VB6 control. Now you're talking about registering a .NET assembly for COM interop. So which is it? I've registered .NET assemblies for COM interop with no problems by taking the output of /regfile. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.xmission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
All regsvr32 does is call DllRegisterServer on the DLL, what happens in here is voodoo! It is perfectly legal to d anything you want in this call and is the reason why self registration is frowned upon. I know a VB6 DLL is just doing standard COM stuff but it is way more complicated that any COM I have ever done in C++, for example, it supports all sorts of things to make binary compatibility work. There are also references back to the VB runtime. I'm not saying it is not possible to make it work by just writing registry entries but I have never got it to work, hence setting self reg (which I assume just calls DllRegisterServer) works for me. Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: Richard [mailto:[EMAIL PROTECTED] Sent: Wed 01/10/2008 04:08 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: By the time it's a COM object, VB6 or C++ it doesn't make any difference. That is a nice theory [...] Its not a theory. An OCX from VB6 is just a DLL with a well defined entry point for registering the COM object. That's *all* that regsrv32 does when you run it! No voodoo. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
That's *one* of the reasons SelfReg is frowned upon. smile/ The other big problem with SelfReg is that the Windows Installer doesn't rollback SelfReg. Another big problem with SelfReg is that they are more fragile than using the built in functionality in MSI. MSXML3 [I think] used to have SelfReg and it accounted for a percentage point or two of installation failures for Office... that was lot of money wasted on SelfReg. The only good thing about SelfReg is that it lets developers be lazy. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 03:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness All regsvr32 does is call DllRegisterServer on the DLL, what happens in here is voodoo! It is perfectly legal to d anything you want in this call and is the reason why self registration is frowned upon. I know a VB6 DLL is just doing standard COM stuff but it is way more complicated that any COM I have ever done in C++, for example, it supports all sorts of things to make binary compatibility work. There are also references back to the VB runtime. I'm not saying it is not possible to make it work by just writing registry entries but I have never got it to work, hence setting self reg (which I assume just calls DllRegisterServer) works for me. Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] From: Richard [mailto:[EMAIL PROTECTED] Sent: Wed 01/10/2008 04:08 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: By the time it's a COM object, VB6 or C++ it doesn't make any difference. That is a nice theory [...] Its not a theory. An OCX from VB6 is just a DLL with a well defined entry point for registering the COM object. That's *all* that regsrv32 does when you run it! No voodoo. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: All regsvr32 does is call DllRegisterServer on the DLL, what happens in = here is voodoo! It is perfectly legal to d anything you want in this = call and is the reason why self registration is frowned upon. Actually, no, its not perfectly legal to do anything you want in DllRegisterServer. You are *only* supposed to do COM registration there. Yeah, if you put other code in there, it will run. But that is not legal in terms of how you are supposed to implement this entry point into the DLL. I know a = VB6 DLL is just doing standard COM stuff but it is way more complicated = that any COM I have ever done in C++ [...] I'm guessing that means you've never done dispinterfaces in C++ or used other attributes of COM that are used by VB6. VB6 supports late binding on its COM servers, so there is a lot of infrastructure there to support dispinterfaces, Invoke, etc. of things to make binary compatibility work. There are also references = back to the VB runtime. I'm not saying it is not possible to make it = work by just writing registry entries but I have never got it to work, = hence setting self reg (which I assume just calls DllRegisterServer) = works for me. =20 The way to gather all the registry entries is to use a registry capture tool to capture all the changes made to the registry when regsvr32 is run on the DLL. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: [...] The default sequence doesn't include the com registration actions that read the class table/etc. IMO, that seems like a bug in WiX. IIRC, the recommended default install sequence *does* include all the registration related actions. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Note, those actions are only necessary if you are using the Advertised features of COM registration otherwise it's all just Registry rows. Also, I personally don't recommend advertising COM goo (http://robmensching.com/blog/archive/2007/03/12/RobMens-Recommendation-Do-not-advertise-COM-information-in-MSI.aspx) and I don't *think* heat generates advertised by default. -Original Message- From: Richard [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 08:18 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: [...] The default sequence doesn't include the com registration actions that read the class table/etc. IMO, that seems like a bug in WiX. IIRC, the recommended default install sequence *does* include all the registration related actions. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Glad you got this worked out. In my case, the problem was that I wasn't specifying ALLUSERS=1, so I was inadvertently doing a per-user install instead of a per-machine install. When the Windows service (running as LocalSystem) tried to instantiate one of the COM objects, it couldn't find the registration for it because it was registered in the CLSID branch of HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE. Interestingly, ProcMon (the successor to RegMon) was no help here, as all of the registration calls were being sent to HKEY_CLASSES_ROOT, which does not differentiate between which elements are going to the user hive and which to the local machine hive. Dumping the registry and comparing was the only way I could find the problem. -Original Message- From: Troy Howard [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 2:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness Ok, I found a process that works... First, I had to explicitly add: InstallExecuteSequence UnregisterClassInfo Sequence=2700 / UnregisterProgIdInfo Sequence=2900/ UnregisterTypeLibraries Sequence=2300/ RegisterClassInfo Sequence='4600' / RegisterProgIdInfo Sequence='4800' / RegisterTypeLibraries Sequence='5500' / /InstallExecuteSequence then for each .net com dll, i ran heat against it to generate a wxs. I then fixedup those wxs files in the following manner: 1. Wrap the Class/ProgID/etc tags inside the File tag so that class/@server gets set 2. Update the registry values that referred to mscoree.dll so that they each have a unique id in the Id attribute. That combination get me functioning .Net COM DLLs, and now that I fully understand what's happening, it makes sense. The default sequence doesn't include the com registration actions that read the class table/etc. So those have to be added. The heat output doesn't nest the class tags in the file tag, so server attribute doesn't know what it's target is. The registry values for mscoree.dll are in conflict with the autogenerated ones made form the class tag, because they both use autogenerated ids, which are a hash of componentId, root, key, and name... And so they need to be differentiate by assigning a unique id. I'm quite relieved I got it worked out. Thanks, Troy On Tue, Sep 30, 2008 at 9:51 PM, Troy Howard [EMAIL PROTECTED] wrote: It's both. The application is written in VB6. It uses COM DLLs written in various languages, including C++, VB6, and .NET. The installer needs to be able to register all of these things. The non-.Net COM DLLs seem to be doing alright with the SelfRegCost attribute applied, but now the .Net DLLs are having trouble. I've tried various ways to get them working. What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib actions. I opened the MSI up in ORCA, and realized that they are not in my InstallExecuteSequence table. That makes sense why it wasn't working with Class/Progid etc elements in the components. The action was never getting called that dealt with those things. I assumed those actions would be included, and that I didn't to explicitly add them. I'm going to give it a try with the correct methodology again, this time with the correct actions in the sequence and see if that does the trick. If so, I can get rid of the self registration stuff, AND the duct tape batch file full of regasm calls. Conveniently, re-ghosting the test box and building the installer take about the same amount of time.. sigh This application is a beast, and the installer has to tame it. What a project At least I have a nice view of downtown Portland at night from the 11th floor of this building. Thanks, Troy On Tue, Sep 30, 2008 at 8:10 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: So, in my efforts to resolve the .Net COM issues, [...] Earlier, this thread was talking about registering a VB6 control. Now you're talking about registering a .NET assembly for COM interop. So which is it? I've registered .NET assemblies for COM interop with no problems by taking the output of /regfile. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.x mission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users
Re: [WiX-users] COM registration weirdness
Richard
This has gone off topic a bit but yes I have done complex c/c++
registrations and have monitored what happens when com is registered and
it all made sense until I monitored a VB6 DLL.
For example, it always seems to rewrite this (among many many more):
Key:
HKCR\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32
Value=C:\Windows\system32\MSVBVM60.DLL
Which I think is part of the VB runtime and I certainly wouldn't want my
install to remove it.
My untested theory is that when you call DllRegisterServer on a VB6 DLL
it either calls DllRegisterServer on MSVBVM60.dll or the code from it is
embedded into the VB6 dll.
The key issue here is what do you need to exclude when registering a VB6
DLL or is it possible to monitor it so we find the key information. Can
you recommend a registry monitoring tool that works for VB6 DLL?
Neil
-Original Message-
From: Richard [mailto:[EMAIL PROTECTED]
Sent: 01 October 2008 16:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED],
Neil Sleightholm [EMAIL PROTECTED] writes:
All regsvr32 does is call DllRegisterServer on the DLL, what happens
in =
here is voodoo! It is perfectly legal to d anything you want in this =
call and is the reason why self registration is frowned upon.
Actually, no, its not perfectly legal to do anything you want in
DllRegisterServer. You are *only* supposed to do COM registration
there.
Yeah, if you put other code in there, it will run. But that is not
legal in terms of how you are supposed to implement this entry point
into the DLL.
I know a =
VB6 DLL is just doing standard COM stuff but it is way more
complicated =
that any COM I have ever done in C++ [...]
I'm guessing that means you've never done dispinterfaces in C++ or
used other attributes of COM that are used by VB6. VB6 supports late
binding on its COM servers, so there is a lot of infrastructure there
to support dispinterfaces, Invoke, etc.
of things to make binary compatibility work. There are also references
=
back to the VB runtime. I'm not saying it is not possible to make it =
work by just writing registry entries but I have never got it to work,
=
hence setting self reg (which I assume just calls DllRegisterServer) =
works for me. =20
The way to gather all the registry entries is to use a registry
capture tool to capture all the changes made to the registry when
regsvr32 is run on the DLL.
--
The Direct3D Graphics Pipeline -- DirectX 9 draft available for
download
http://www.xmission.com/~legalize/book/download/index.html
Legalize Adulthood! http://blogs.xmission.com/legalize/
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Neil Sleightholm wrote: My untested theory is that when you call DllRegisterServer on a VB6 DLL it either calls DllRegisterServer on MSVBVM60.dll or the code from it is embedded into the VB6 dll. In my experience, self-reg code gets extra-aggressive in response to bug reports to respond to symptoms rather than fixing underlying causes. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Rob Mensching [EMAIL PROTECTED] writes: Note, those actions are only necessary if you are using the Advertised features of COM registration otherwise it's all just Registry rows. True. So let me state it another way -- is there an ICE that fails if your COM tables are populated but your action sequences don't contain the COM registration actions? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Evans, Jim [EMAIL PROTECTED] writes: Interestingly, ProcMon (the successor to RegMon) was no help here, as all of the registration calls were being sent to HKEY_CLASSES_ROOT, which does not differentiate between which elements are going to the user hive and which to the local machine hive. Dumping the registry and comparing was the only way I could find the problem. ...but it would have told you what was wrong if you also ran ProcMon on your install and compared the output. You would have seen that one set things in HKCR and the other set things in HKCU. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: The key issue here is what do you need to exclude when registering a VB6 DLL or is it possible to monitor it so we find the key information. Can you recommend a registry monitoring tool that works for VB6 DLL? The answer to that is pretty simple -- you ignore anything that's not related to your component. It sounds to me like DllRegisterServer on a VB6 DLL helps you by making sure that your dependencies (the VB6 runtime) is also registered. This was a problem in the early days when the VB6 runtime was something you had to add onto windows. I'm not certain which OS started including the VB6 DLLs as part of system, but IIRC they all include the runtime dependencies now so you shouldn't ever need to do that part. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Richard The answer to that is pretty simple -- you ignore anything that's not related to your component. I think you are missing the point (or I am), how do I know it is not related? In VB6 you don't edit the COM registration so you don't know the details. I have a fairly simple ocx and heat generates 182 lines of WiX code for it! I have tried a few times to remove the unrelated code and never successfully got the component to work or to leave the machine working on uninstall. Have you ever generated the WiX registry code for VB6 COM component? Has anyone? Neil -Original Message- From: Richard [mailto:[EMAIL PROTECTED] Sent: 01 October 2008 21:11 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: The key issue here is what do you need to exclude when registering a VB6 DLL or is it possible to monitor it so we find the key information. Can you recommend a registry monitoring tool that works for VB6 DLL? The answer to that is pretty simple -- you ignore anything that's not related to your component. It sounds to me like DllRegisterServer on a VB6 DLL helps you by making sure that your dependencies (the VB6 runtime) is also registered. This was a problem in the early days when the VB6 runtime was something you had to add onto windows. I'm not certain which OS started including the VB6 DLLs as part of system, but IIRC they all include the runtime dependencies now so you shouldn't ever need to do that part. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: Richard The answer to that is pretty simple -- you ignore anything that's not related to your component. I think you are missing the point (or I am), how do I know it is not related? Well, the things that are related to your COM object are laid out in the COM specification. I'm assuming since its your COM object, that you know the CLSIDs, IIDs, etc., that go with your object. In VB6 you don't edit the COM registration so you don't know the details. True, but you do decide the ProgId that exposes your COM object and for the places where COM is registering a server, it is coupled to the filename of the DLL containing the server, so you can link things back that way. There will also be a type library associated with your COM object, to support VB6's dispinterface style late binding. The type library for a VB6 COM object is always contained in the DLL of the object, so that's also coupled back to your object through the filename. I have a fairly simple ocx and heat generates 182 lines of WiX code for it! Can you post a URL to the generated WiX code from heat? I'd like to see what kind of stuff its generating. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: Have you ever generated the WiX registry code for VB6 COM component? Has anyone? Oh, I almost forgot -- yes, I have registered VB6 COM components manually by populating the Class, etc., tables. I haven't done it with WiX; I did it by editing an MSI with Orca directly. (When I did this, WiX didn't exist yet.) So yes, I know it can be done and it can work reliably. We never had any problems with the VB6 components that we registered in this way. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
By the time it's a COM object, VB6 or C++ it doesn't make any difference. That is a nice theory and I believed it but just couldn't get my head around registering VB6 COM DLL's (C++ are fine) in the end I ended up using self registration (SelfRegCost=1). I'm sure there is some voodoo going on with VB6 COM DLL's but I couldn't figure it! Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
So, in my efforts to resolve the .Net COM issues, I've tried out this process: 1. Generate .reg files with regasm /regFile 2. Convert .reg files to .wxs using tallow (WiX2) 3. Fixup .wxs files using WixCop (WiX3). 4. Fixup those fixed-upped files removing the nested and duplicate registry entries. 5. Rebuild... Unfortunately, that's not working either. After installation, the application that uses these DLLs just hangs when attempting to call them. Before, when the registration was failing completely, the application would error out with an Cannot create ActiveX object type of error or Automation error... etc.. Now, it just silently hangs without producing an error, but also without functioning... If I register the DLLs on the target machine after that install using regasm manually, everything works just fine. I'm sort of at a loss on this one. I've tried everything I can think of, and everything I've heard suggested on the 'net.. Is it always this complicated to register .Net COM DLLs? Did I miss the easy route somehow? Thanks, Troy On Mon, Sep 29, 2008 at 9:29 PM, Troy Howard [EMAIL PROTECTED] wrote: I appreciate the feedback. In the short term, I've added the SelfRegCost attribute to the file tags for the non-.Net COM DLLs, and that seems to work fine. As for the DLLs themselves, I have no idea what langauge they were written in. We're using them within a legacy VB6 app, and wiring in new functionality with .Net COM DLLs. The non-.Net stuff is all third party things that we've licensed, so I have no source code for that stuff. It's quite possible that somehting is happening outside of the norm with them guys, since none of them seem to be what I would call high-quality software products. So, on the the .Net COM Interop registration... any idea why the basic output from heat wouldn't be doing the trick? What might it be missing? Should I just do a regasm /reg and then convert that to WiX code? Thanks, Troy On Mon, Sep 29, 2008 at 9:15 PM, Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] , Rob Mensching [EMAIL PROTECTED] writes: If anyone does figure it out, it'd be good to understand what is going on. I don't know VB (let alone VB6) and things work great for my C++/ATL based COM objects. By the time its a COM object, VB6 or C++ it doesn't make any difference. I would run RegMon and FileMon while you hand register the COM object on a system where its never been registered before. Then check to make sure it isn't doing things inside its DllRegisterServer that its not supposed to be doing (through filemon). Its only supposed to be setting registry values that deal with COM registration, but sometimes people get lazy and do all sorts of crazy stuff in there. I don't know if VB6 lets you control that entry point or just does it for you based on the kind of project you made. At any rate, all that's happening when you register the COM object with Windows Installer is that its handling those registry entries for you. If you duplicate all of the registry entries, then it should work fine. The key is going to be running some sort of utility that can tell you how that component is interacting with the system when its DllRegisterServer entry point is called. Ultimately you could (ugh) step through the assembly code as it executes to identify the missing piece. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.htmlhttp://www.xmission.com/%7Elegalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Troy Howard [EMAIL PROTECTED] writes: So, in my efforts to resolve the .Net COM issues, [...] Earlier, this thread was talking about registering a VB6 control. Now you're talking about registering a .NET assembly for COM interop. So which is it? I've registered .NET assemblies for COM interop with no problems by taking the output of /regfile. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Neil Sleightholm [EMAIL PROTECTED] writes: By the time it's a COM object, VB6 or C++ it doesn't make any difference. That is a nice theory [...] Its not a theory. An OCX from VB6 is just a DLL with a well defined entry point for registering the COM object. That's *all* that regsrv32 does when you run it! No voodoo. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Hi Jim,
Did you ever figure this out?
I'm in basically the same situation. I have a VB6 application that uss
numerous third party COM DLLs, and some in-house .Net COM DLLs. I've
included all the appropriate bits of WiX code (AFAICT), but the registration
doesn't seem to be effective. Running regsvr32 and regasm on the assemblies
after installer gets everything working though.
At this point, I'm thinking I'll have to run a batch file at the end of the
install to call regsvr32/regasm just to the the thing out the door on
schedule.
I'm in the process of migrating from an existing Installshield setup to WiX,
and we did it with a batch file in the IS installer. One of the big things
were were hoping to get out of WiX was to make this happen correctly,
instead of with a duct tape batch file.
Does anyone have an insight that I might be missing?
My basic process for getting the WiX code for this was to run heat again the
files, generating a wxs, then edit those wxs fragments to compile correctly.
This involved moving the class/progid/typelib/interface declarations inside
of the file tag, and removing extra registry keys that were in conflict with
those tags (IE. removing tags like
RegistryValue Root=HKCR
Key=CLSID\{082EE6CC-A371-37A6-BF8A-090D9BD50A10}\InprocServer32
Value=mscoree.dll Type=string Action=write /)... etc.
Thanks,
Troy
On Tue, Sep 2, 2008 at 3:05 PM, Evans, Jim [EMAIL PROTECTED]wrote:
I know this isn't the exact forum for this, but I'm really confused and
don't know where else to turn. I'm in the process of moving our
installer to an msi-based install using WiX. Our application is fairly
complex, including .NET assemblies, a client-side application, Windows
services that run on a server, a web portal, and COM components on the
server that the service and web portal use. It's these COM components
that are giving me fits. I've created WiX install elements for the COM
components (Typelib, Class, ProgId, Interface, etc.), and as far
as I can tell the COM registration is correct. All of the COM registry
entries are getting created by the installer. However, my COM components
cannot be used by their consumers after the installation.
If I use regsvr32 to unregister and reregister the .dll, the COM
components work properly. These are VB6 dlls in the main, but I don't
think that has anything to do with it. I've watched what regsvr32 does
using procmon, and it does look like it's registering my Interface
information twice, but I can't see how that would affect things. I'm
going to try a full registry comparison next, but I was wondering if
anybody here has run into anything like this?
--Jim Evans
Numara Software, Inc.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
If anyone does figure it out, it'd be good to understand what is going on. I
don't know VB (let alone VB6) and things work great for my C++/ATL based COM
objects.
-Original Message-
From: Troy Howard [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2008 19:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] COM registration weirdness
Hi Jim,
Did you ever figure this out?
I'm in basically the same situation. I have a VB6 application that uss
numerous third party COM DLLs, and some in-house .Net COM DLLs. I've
included all the appropriate bits of WiX code (AFAICT), but the registration
doesn't seem to be effective. Running regsvr32 and regasm on the assemblies
after installer gets everything working though.
At this point, I'm thinking I'll have to run a batch file at the end of the
install to call regsvr32/regasm just to the the thing out the door on
schedule.
I'm in the process of migrating from an existing Installshield setup to WiX,
and we did it with a batch file in the IS installer. One of the big things
were were hoping to get out of WiX was to make this happen correctly,
instead of with a duct tape batch file.
Does anyone have an insight that I might be missing?
My basic process for getting the WiX code for this was to run heat again the
files, generating a wxs, then edit those wxs fragments to compile correctly.
This involved moving the class/progid/typelib/interface declarations inside
of the file tag, and removing extra registry keys that were in conflict with
those tags (IE. removing tags like
RegistryValue Root=HKCR
Key=CLSID\{082EE6CC-A371-37A6-BF8A-090D9BD50A10}\InprocServer32
Value=mscoree.dll Type=string Action=write /)... etc.
Thanks,
Troy
On Tue, Sep 2, 2008 at 3:05 PM, Evans, Jim [EMAIL PROTECTED]wrote:
I know this isn't the exact forum for this, but I'm really confused and
don't know where else to turn. I'm in the process of moving our
installer to an msi-based install using WiX. Our application is fairly
complex, including .NET assemblies, a client-side application, Windows
services that run on a server, a web portal, and COM components on the
server that the service and web portal use. It's these COM components
that are giving me fits. I've created WiX install elements for the COM
components (Typelib, Class, ProgId, Interface, etc.), and as far
as I can tell the COM registration is correct. All of the COM registry
entries are getting created by the installer. However, my COM components
cannot be used by their consumers after the installation.
If I use regsvr32 to unregister and reregister the .dll, the COM
components work properly. These are VB6 dlls in the main, but I don't
think that has anything to do with it. I've watched what regsvr32 does
using procmon, and it does look like it's registering my Interface
information twice, but I can't see how that would affect things. I'm
going to try a full registry comparison next, but I was wondering if
anybody here has run into anything like this?
--Jim Evans
Numara Software, Inc.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Rob Mensching [EMAIL PROTECTED] writes: If anyone does figure it out, it'd be good to understand what is going on. I don't know VB (let alone VB6) and things work great for my C++/ATL based COM objects. By the time its a COM object, VB6 or C++ it doesn't make any difference. I would run RegMon and FileMon while you hand register the COM object on a system where its never been registered before. Then check to make sure it isn't doing things inside its DllRegisterServer that its not supposed to be doing (through filemon). Its only supposed to be setting registry values that deal with COM registration, but sometimes people get lazy and do all sorts of crazy stuff in there. I don't know if VB6 lets you control that entry point or just does it for you based on the kind of project you made. At any rate, all that's happening when you register the COM object with Windows Installer is that its handling those registry entries for you. If you duplicate all of the registry entries, then it should work fine. The key is going to be running some sort of utility that can tell you how that component is interacting with the system when its DllRegisterServer entry point is called. Ultimately you could (ugh) step through the assembly code as it executes to identify the missing piece. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Richard wrote: RegMon will reveal all. You can get it from the sysinternals portion of Microsoft's web site. Not always. As I said from my original post, I monitored the installation using ProcMon (the successor to RegMon), and it looked like everything was okay. The problem turned out to be per-user vs. per-machine install. HKEY_CLASSES_ROOT isn't for the entire machine unless you specify ALLUSERS=1, and ProcMon was masking that problem as all of my registry calls looked like they were correctly going to HKCR. As sports columnist Bill Simmons would say, The lesson, as always, I'm an idiot. I've got a couple of more questions, but I'll ask them under separate messages. --Jim Evans Numara Software, Inc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] COM registration weirdness
I know this isn't the exact forum for this, but I'm really confused and don't know where else to turn. I'm in the process of moving our installer to an msi-based install using WiX. Our application is fairly complex, including .NET assemblies, a client-side application, Windows services that run on a server, a web portal, and COM components on the server that the service and web portal use. It's these COM components that are giving me fits. I've created WiX install elements for the COM components (Typelib, Class, ProgId, Interface, etc.), and as far as I can tell the COM registration is correct. All of the COM registry entries are getting created by the installer. However, my COM components cannot be used by their consumers after the installation. If I use regsvr32 to unregister and reregister the .dll, the COM components work properly. These are VB6 dlls in the main, but I don't think that has anything to do with it. I've watched what regsvr32 does using procmon, and it does look like it's registering my Interface information twice, but I can't see how that would affect things. I'm going to try a full registry comparison next, but I was wondering if anybody here has run into anything like this? --Jim Evans Numara Software, Inc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
I had the same problem and switched to self-registering servers, i.e. setting SelfRegCost attribute on corresponding file elements. I know this approach is not officially recommended but it is hard to see what some third-party COM servers do with the Registry. -Original Message- From: Evans, Jim [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2008 6:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] COM registration weirdness I know this isn't the exact forum for this, but I'm really confused and don't know where else to turn. I'm in the process of moving our installer to an msi-based install using WiX. Our application is fairly complex, including .NET assemblies, a client-side application, Windows services that run on a server, a web portal, and COM components on the server that the service and web portal use. It's these COM components that are giving me fits. I've created WiX install elements for the COM components (Typelib, Class, ProgId, Interface, etc.), and as far as I can tell the COM registration is correct. All of the COM registry entries are getting created by the installer. However, my COM components cannot be used by their consumers after the installation. If I use regsvr32 to unregister and reregister the .dll, the COM components work properly. These are VB6 dlls in the main, but I don't think that has anything to do with it. I've watched what regsvr32 does using procmon, and it does look like it's registering my Interface information twice, but I can't see how that would affect things. I'm going to try a full registry comparison next, but I was wondering if anybody here has run into anything like this? --Jim Evans Numara Software, Inc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Evans, Jim [EMAIL PROTECTED] writes: I know this isn't the exact forum for this, but I'm really confused and don't know where else to turn. I'm in the process of moving our installer to an msi-based install using WiX. Our application is fairly complex, including .NET assemblies, a client-side application, Windows services that run on a server, a web portal, and COM components on the server that the service and web portal use. It's these COM components that are giving me fits. I've created WiX install elements for the COM components (Typelib, Class, ProgId, Interface, etc.), and as far as I can tell the COM registration is correct. All of the COM registry entries are getting created by the installer. However, my COM components cannot be used by their consumers after the installation. The way I debug this is to run regmon while running the install, or sifting through HKCR after the install is done to check that my entries were processed. Also check your verbose log and make sure that the COM registration is associated with a component that is actually being installed. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
In article [EMAIL PROTECTED], Tony Juricic [EMAIL PROTECTED] writes: I know this approach is not officially recommended but it is hard to see what some third-party COM servers do with the Registry. RegMon will reveal all. You can get it from the sysinternals portion of Microsoft's web site. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
