error C1083: Cannot open type library file: 'vcclient\addobj.dll': Error loading type library/DLL.

[ajitm]

Hello!

I have created one simple Com dll. I am trying to load that DLL in my VC++ client application by

#import "addobj.dll"
statement but getting following error. That DLL was secessfully build and registered too but I dont understand why following error occures

"error C1083: Cannot open type library file: '\vcclient\addobj.dll': Error loading type library/DLL."

can anybody knows what is the problem here??

[andywestken]

No idea, really.

But the fact the complaint is about addobj.dll, rather than sample.dll, suggests that your typelib might be importing from addobj dll (does your midl file have any importlib directives?)

Do you know about OleView.exe? I would use it open your typelib and see if it has a dependency on addobj.dll.

You also need to identify what this other dll is, if you don't already know.

You might also want to check the various registry entries.

Andy

[ajitm]

Actuly I am trying to write one sample COM application by refering code at following link

http://www.codeguru.com/cpp/com-tech/activex/tutorials/article.php/c5567/Step-by-Step-COM-Tutorial.htm

I checked my .tlb file using OleView.exe file. I found that, following strike thr lines are additional as compare to working .tlb file

[
uuid(73E068F2-E36A-4792-839F-924FAE675899),
version(0.0),
helpstring("Interfaces for Code-Guru algorithm implementations ."),
custom(DE77BA64-517C-11D1-A2DA-0000F8773CE9, 117441067),
custom(DE77BA63-517C-11D1-A2DA-0000F8773CE9, 1371190007),
custom(DE77BA65-517C-11D1-A2DA-0000F8773CE9, Created by MIDL version 7.00.0555 at Fri Jun 14 11:36:45 2013

is this causing above problem??

following libraries are imported in my library

importlib("stdole32.tlb");
importlib("stdole2.tlb");

Many thanks in advance

[andywestken]

You can ignore the custom midl attributes, they are benign.

(They are the version (in binary form), the time and date the midl compiler was run to generate the tlb file (also in binary form), and a string providing the same information.)

So, the answer to:

is this [these attributes] causing above problem??

is... Nope!

And stdole32.tlb and stdole2.tlb turn up all the time, so they're not the problem (if they were missing, a lot of things would go wrong!)

I have downloaded and built and run the demo project from the tutorial you mention. I had to "hack" the code a little bit to get it to work, but it ran OK for me. (VC++ 2010 wouldn't load the original .dsp files, so I had to recreate the project, and added some pointless .cpp files)

Did you add the folder where your copy of addobj.dll is located to the include path for the VCClient project? (I had to do that to get it to build)

Andy

PS I am not esp. impressed with this tutorial :-/ Esp. as it didn't build until I tweaked the code (issing files, incorrect class name, etc)

[andywestken]

BTW - which IDE/compiler are you using?

Andy

PS Note that the article working from is pretty old, as you no doubt noticed; from March 2001 !!

And I've also notice a few significant flaws in the code, including the implementation of IClassFactory::CreateInstance. As coded it's

HRESULT __stdcall CAddFactory::CreateInstance(IUnknown* pUnknownOuter,
                                           const IID& iid,
                                           void** ppv) 
    {
    //
    //This method lets the client manufacture components en masse
    //The class factory provides a mechanism to control the way
    //the component is created. Within the class factory the 
    //author of the component may decide to selectivey enable
    //or disable creation as per license agreements 
    //
    //

    // Cannot aggregate.
	if (pUnknownOuter != NULL)
	    {
		return CLASS_E_NOAGGREGATION ;
	    }

    //
    // Create an instance of the component.
    //
	CAddObj* pObject = new CAddObj ;
	if (pObject == NULL)
	    {
		return E_OUTOFMEMORY ;
	    }

    //
    // Get the requested interface.
    //
	return pObject->QueryInterface(iid, ppv) ;
    }

The problem is the very last call, the QueryInterface. If someone asks for an interface that CAddObj does not support, the newly create object (here, pointed to by pObject) will not be correctly deleted. The standard solution to this problem is to call AddRef() before calling QueryInterface, and Release() afterwards. That is,

HRESULT __stdcall CAddFactory::CreateInstance(IUnknown* pUnknownOuter,
                                           const IID& iid,
                                           void** ppv) 
    {
    //
    //This method lets the client manufacture components en masse
    //The class factory provides a mechanism to control the way
    //the component is created. Within the class factory the 
    //author of the component may decide to selectivey enable
    //or disable creation as per license agreements 
    //

    //
    // Cannot aggregate.
    //
	if (pUnknownOuter != NULL)
	    {
		return CLASS_E_NOAGGREGATION ;
	    }

    //
    // Create an instance of the component.
    //
	CAddObj* pObject = new CAddObj ;
	if (pObject == NULL)
	    {
		return E_OUTOFMEMORY ;
	    }

    //
    // Increment ref count to 1 (object created with count of 0)
    //
        pObject->AddRef();

    //
    // Get the requested interface. If successful, ref count is increased to 2
    //
        HRESULT hr = pObject->QueryInterface(iid, ppv) ;

    //
    // Decrement ref count by 1. If QueryInterface succeeded, it ends up 
    // as a value or 1. But if QueryInterface failed, the count will drop to
    // zero triggering the object's deletion.
    //
        pObject->Release();

        return hr;
    }