Problem with CoFreeUnusedLibraries/CoCreateInstance

[Bernd Unger]

Hi Com+'s!

I have a problem with com's function CoFreeUnusedLibraries. It works fine if i
call it directly, but if you read in its documentation you can call CoLoadLibrary
with a flag bAutoFree. But if i use CoCreateInstance i cannot supply this
parameter.

Has anybody an idea? Is this a COM bug?

Bye
Bernd

[Igor Tandetnik]

CoCreateInstance is supposed to call CoLoadLibrary with bAutoFree set to
TRUE when creating an instance served by in-proc server. Have you found
something that suggests it doesn't?
--
With best wishes,
Igor Tandetnik

"Bernd Unger" <b...@viewpoint-online.com> wrote in message
news:b58b01c0d6d6$e2d7c1f0$9ee62ecf@tkmsftngxa05...

[Alexander Nickolov]

CoFreeUnusedLibraries doesn't automatically release the unused
COM DLLs. You have to call it periodically. There's a timeout of
about 10 minutes from a DLL's DllCanUnloadNow starting to
return S_OK to the moment the DLL is actually unloaded. This
timeout is there to prevent a race condition in unloading the
DLL (although 10 minutes is way too much IMO...).

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@geocities.com
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Bernd Unger" <b...@viewpoint-online.com> wrote in message
news:b58b01c0d6d6$e2d7c1f0$9ee62ecf@tkmsftngxa05...

[Bernd Unger]

Yes i think so. We have a global (urgh) object in the com dll. I found that this
object was not destroyed if i released the last interface of the com server. So i
tried to call CoFreeUnusedLibrares and - guess - everything was released
immediately on that call...

If bAutofree is not set in CoCreateInstance - i do not understand the sense of
that stuff...

Bye
Bernd

.

[Bernd Unger]

Ok - i read some of that things in the msdn, but in my application i can see in
the debugger in combination with the process viewer that the dll is really
unloaded directly after the call of CoFreeUnusedLibraries and thats what i want.
In my application i know if i do the last release of the interface that i can
securely unload everything - there are no other threads using this com server.

So i think its ok, that a programmer can tell the server to go away at a defined
point in his application.

This "periodically call stuff" i read too in the msdn, but i disagree here
absolutly. It tastes a bit like polling - should i write each second line a
CoFreeUnusedLibraries to reduce the memory footprint of my application? Is that
really what the API designers suggests here? Dont think so...
So the bAutoFree flag seem to be the right thing, bad that i cannot set it in
CoCreateInstance ;-(

Bye
Bernd

.

[Igor Tandetnik]

This behavior is by design. The COM DLLs are NOT automatically unloaded as
soon as the last reference is released. The client has to periodically call
CoFreeUnusedLibrares. This function checks all the DLLs that were loaded
with CoLoadLibrary with bAutoFree set to TRUE as to whether they can be
unloaded (by calling DllCanUnloadNow). That's exactly what you see.

I don't quite see the cause of your confusion. The documentation for
CoLoadLibrary states in no uncertain terms:

bAutoFree
[in] If TRUE, indicates that this library is freed when it is no longer
needed, through a call to either the CoFreeUnusedLibraries or CoUninitialize
functions. If FALSE, the library should be explicitly freed with the
CoFreeLibrary function.

--
With best wishes,
Igor Tandetnik

"Bernd Unger" <b...@viewpoint-online.com> wrote in message

news:2f9a01c0d78a$00012e70$b1e62ecf@tkmsftngxa04...

[Bernd Unger]

Ok! You are right - i now understand the documenation...
Sometimes somebody has to explain it clearly and then i understand it.
Sorry for the inconvenience.

My Problem was to read the section of bAutoFree exactly. My opintion was, that
somebody does call CoFreeUnusedLibrary for me (would be nice).

Thanks for your answer.
Bye
Bernd

Bye
Bernd

..

.