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.html<http://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=100&url=/
>> _______________________________________________
>> 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=100&url=/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to