locked
CCW not being auto-created - why?

    Question

  • I'm running a 32 bit ver of win7 in a vm. I am trying to reference 5 com dlls (VB6) in my .net project. These dlls (and their dependencies) are registered ok since I can use them natively as they form a part of another app and that app is working fine.

    I try to set a reference to any of them directly in vs and I get the error message - Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).

    However, if I set a reference to another com component (which I don't want to reference but which in turn does reference these libs) I find that the references to these com dlls (which I do want to reference) gets set correctly in vs. I then just need to remove the ref to the unwanted dll and everything seems to be good to go.

    If I look at the GUID and version details of one of the successfully referenced component, they appear to be the same as the GUID and version that appears in the caption of the error form, when I unsuccessfully try and set a reference to the same component directly.

    BTW I have tried repairing the VS installation to no avail

    I was wondering if someone could explain what I am doing wrong.

    EDIT

    So I ran

    tlbimp mylib.dll
    

    and it returned a TI1006 error - Output would overwrite the input file. So following suggestions found, I then issued

    tlbimp mylib.dll /OUT:interop.mylib.dll
    

    and this then returned the error

    TlbImp : warning TI3011 : Type library importer has encountered an interface not derived from IUnknown: '_HiddenInterface'. The interface is skipped. TlbImp : error TI1033 : Cannot find type 'ADODB._Recordset_Deprecated' in 'ADODB, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. There could be a mismatch between the referenced assembly and the type library.

    But I'm not sure if this is a red herring since this lib could be referenced when successfully referencing the different higher level dll. I have tried with a dll which doesn't reference ADODB and that seems to work using tlbimp. So, e.g.

    tlbimp myNONADODBlib.dll /OUT:interop.myNONADODBlib.dll
    

    works from the commandline. However

    tlbimp myNONADODBlib.dll
    

    still generates the error TI1006 - output file will overwrite input file, and I cannot reference this into my .net project

    EDIT:

    There seems to be a problem with ADO and Win7 SP1. http://support.microsoft.com/kb/2517589 which would account for the deprecated error message (TI1033) I was getting, but not why VS was failing to create a CCW for the dll I can manually create a CCW via tlbimp.

    EDIT (12/03/28 10:40):

    So I have rebuilt the com dll with the suggested tlb. I can now successfully run

    tlbimp mylib.dll
    

    without getting any error messages and it appears to complete successfully. However, when I try and add a reference to that dll in VS, I still get the same original error message ( Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))). I have checked the registry and the registration looks ok i.e. it is pointing to the correct path - I'm wondering if it is a permissions-type issue - but I am running vs as admin.

    Many thx

    Simon.







    • Edited by Simon Woods Wednesday, March 28, 2012 11:40 AM More info
    Friday, March 16, 2012 2:16 PM

Answers

  • So I ended up creating a completely new win7 vm with vs2010 and everything worked ok. So not sure what could have caused it.
    Friday, March 30, 2012 12:39 PM

All replies

  • Hi

    Register it first: http://msdn.microsoft.com/en-us/library/tt0cf3sx(v=vs.100).aspx 

    Actually, you need to register the .tlb file with this tool, rather than .dll. you need to register the .dll file with regsvr32. Sorry for missleading.

    You can see the usage:

    tlbimp tlbFile [options]

    the first argument is absolutely a .tlb file. So please try it again.


    Ghost,
    Call me ghost for short, Thanks
    To get the better anwser, it should be a better question.


    • Proposed as answer by Mike FengModerator Monday, March 26, 2012 12:37 PM
    • Unproposed as answer by Simon Woods Tuesday, March 27, 2012 12:49 PM
    • Edited by CrazyGhost_Von Wednesday, March 28, 2012 2:03 AM The previous is wrong
    Monday, March 19, 2012 9:24 AM
  • Thx Ghost

    Regasm what? the COM dlls? They are obviously already registered since the app which uses them runs fine. AIUI,  regasm registers net dlls for com use? (Just in case, I did try regasm-ing my dll and it failed with "not a valid /net assembly")

    S

    Tuesday, March 27, 2012 9:42 AM
  • Hi Simon,

    Since my previous post is wrong, so I edit it with my new thougt, please check it again.

    Have a nice day.


    Ghost,
    Call me ghost for short, Thanks
    To get the better anwser, it should be a better question.

    Wednesday, March 28, 2012 2:04 AM
  • Thx very much again, Ghost

    I have updated the original with a bit more info. I have been running ProcMon when trying to register the com component in vs. It looks like it is looking for the reference (and other references not related to my own com components[1]) in the current user part of the registry but if I check the registry, there are no registrations for the com component there but only on the local machine area. I'm not quite sure what is going on since I am running VS  as administrator. Other work colleagues seem to be able to run this same setup (Win7SP1,VS2010SP1 etc) and successfully reference the COM dlls. I too can reference the com dlls from a VS2010 setup on an XP vm machine I have, so it is looking to me like a corruption of some sort - but I'm not sure where and  I have already tried a complete uninstall/re-install of VS.

    Thx again for your time

    S

    1 eg C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\fpeditax.dll\1

    Wednesday, March 28, 2012 11:50 AM
  • Sorry, I think my last comment I think is a red herring. ProcMon shows similar behaviour to my other vm where adding a com ref to a vs project does work.
    • Edited by Simon Woods Thursday, March 29, 2012 6:46 AM
    Thursday, March 29, 2012 6:46 AM
  • So I ended up creating a completely new win7 vm with vs2010 and everything worked ok. So not sure what could have caused it.
    Friday, March 30, 2012 12:39 PM
  • Hi simon,

    It is good you have found a workaround and keep moving. Sometimes, the cause is hard to find.

    Have a nice day :)


    Ghost,
    Call me ghost for short, Thanks
    To get the better anwser, it should be a better question.

    Saturday, March 31, 2012 2:04 AM
  • Thx for your time, Ghost
    Monday, April 02, 2012 8:36 AM