[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

.NET CLR 1.1 does not release the COM object reference.

johnxhc

5/16/2007 1:51:00 AM

We have a project in .NET 1.1 , some of the .NET methods take COM
interface reference pointer as a parameter, somehow we have to call
Marshal.ReleaseComObject to release the COM Object, otherwise the COM
object will never get release, Even we call gc.Collect()

But the same code compiles in .NET 2.0 works without the
Marshal.ReleaseComObject. (Unfortunately the project is supposed to
run on .NET 1.1.)


Is this a known problem? What is the remedy besides
Marshal.ReleaseComObject? (We know it is dangerous to call
Marshal.ReleaseComObject since we do not have total control of the
COM
interface pointer )


Thanks in advance.
John

7 Answers

Nicholas Paldino [.NET/C# MVP]

5/16/2007 2:03:00 AM

0

John,

Regardless of version, you should be calling ReleaseComObject on
references to COM objects that you have when you are done with them. COM
depends on reference counting, and while garbage collection will ultimately
take care of stray references that you have (and properly decrement the
reference count, which will ultimately handle the disposing of the COM
object that the Runtime Callable Wrapper holds on to), it isn't a good idea
to not release the objects when you are done with them.

In other words, don't remove the call in .NET 2.0 because you think it
works.

As for .NET 1.1, the ReleaseComObject method existed on the Marshal
class in that version of the framework, so there is no reason you can't use
it there.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com


<johnxhc@gmail.com> wrote in message
news:1179280286.509480.83450@n59g2000hsh.googlegroups.com...
> We have a project in .NET 1.1 , some of the .NET methods take COM
> interface reference pointer as a parameter, somehow we have to call
> Marshal.ReleaseComObject to release the COM Object, otherwise the COM
> object will never get release, Even we call gc.Collect()
>
> But the same code compiles in .NET 2.0 works without the
> Marshal.ReleaseComObject. (Unfortunately the project is supposed to
> run on .NET 1.1.)
>
>
> Is this a known problem? What is the remedy besides
> Marshal.ReleaseComObject? (We know it is dangerous to call
> Marshal.ReleaseComObject since we do not have total control of the
> COM
> interface pointer )
>
>
> Thanks in advance.
> John
>

Christian Fröschlin

5/16/2007 7:28:00 AM

0

johnxhc@gmail.com wrote:

> We have a project in .NET 1.1 , some of the .NET methods take COM
> interface reference pointer as a parameter, somehow we have to call
> Marshal.ReleaseComObject to release the COM Object, otherwise the COM
> object will never get release, Even we call gc.Collect()

The COM reference will be released in the finalizer, so to get
the same immediate effect as with Marshal.ReleaseComObject, try

GC.Collect()
GC.WaitForPendingFinalizers()

You should carefully consider where you place this code,
as calling a multiple waits simultaneously from different
threads may cause a deadlock.

johnxhc

5/16/2007 5:22:00 PM

0

Nicholas,Thanks so much for the reply, two more questions.
1) How come in .NET 1.1, the COM object is not released even after I
called gc.Collect multiple times as following

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

If the above code releases the COM object, I would not be so puzzled.

But in .NET 2.0 it was release right away.

2) In our code, we have one method, take the COM object, stored it in
an ArrayList, in the second method , we take the same COM object, here
we search the ArrayList, remove the COM object from the ArrayList, it
is here where I call the ReleaseComObject

For the same .Net method. One is called by VC++ client, I only need to
call ReleaseComObject once, but for the VB client I have to call
ReleaseComObject 3 times before the object is release

If I keep calling ReleaseComObject until the return value is 0, then
I will get an exception
"COM object that has been separated from its underlying RCW can not
be used."

That got me really worried , why 3 times ? Is it possible for me to
get the exception by calling ReleaseComObject 3 times? (Because we
have not control how the client is using our framework)

Please advice.
Thanks.

On May 15, 7:03 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> John,
>
> Regardless of version, you should be calling ReleaseComObject on
> references to COM objects that you have when you are done with them. COM
> depends on reference counting, and while garbage collection will ultimately
> take care of stray references that you have (and properly decrement the
> reference count, which will ultimately handle the disposing of the COM
> object that the Runtime Callable Wrapper holds on to), it isn't a good idea
> to not release the objects when you are done with them.
>
> In other words, don't remove the call in .NET 2.0 because you think it
> works.
>
> As for .NET 1.1, the ReleaseComObject method existed on the Marshal
> class in that version of the framework, so there is no reason you can't use
> it there.
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - m...@spam.guard.caspershouse.com
>
> <john...@gmail.com> wrote in message
>
> news:1179280286.509480.83450@n59g2000hsh.googlegroups.com...
>
>
>
> > We have a project in .NET 1.1 , some of the .NET methods take COM
> > interface reference pointer as a parameter, somehow we have to call
> > Marshal.ReleaseComObject to release the COM Object, otherwise the COM
> > object will never get release, Even we call gc.Collect()
>
> > But the same code compiles in .NET 2.0 works without the
> > Marshal.ReleaseComObject. (Unfortunately the project is supposed to
> > run on .NET 1.1.)
>
> > Is this a known problem? What is the remedy besides
> > Marshal.ReleaseComObject? (We know it is dangerous to call
> > Marshal.ReleaseComObject since we do not have total control of the
> > COM
> > interface pointer )
>
> > Thanks in advance.
> > John- Hide quoted text -
>
> - Show quoted text -


johnxhc

5/16/2007 5:59:00 PM

0

Nicholas ,
Thanks so much for the reply, two more following questions.
1) How come in .NET 1.1, the COM object is not released even after I
called gc.Collect multiple times as following

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

If the above code releases the COM object, I would not be so puzzled.

But in .NET 2.0 it was release right away.

2) In our code, we have one method, take the COM object, stored it in
an ArrayList, in the second method , we take the same COM object, here
we search the ArrayList, remove the COM object from the ArrayList, it
is here where I call the ReleaseComObject

For the same .Net method. One is called by VC++ client, I only need
to call ReleaseComObject once, but for the VB client I have to call
ReleaseComObject 3 times before the object is release

If I keep calling ReleaseComObject until the return value is 0, then
I will get an exception
"COM object that has been separated from its underlying RCW can not
be used."

That got me really worried , why 3 times ? Is it possible for me to
get the exception by calling ReleaseComObject 3 times? (Because we
have not control how the client is using our framework)

Please advice.
Thanks so much for your help.
John

On May 15, 7:03 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> John,
>
> Regardless of version, you should be calling ReleaseComObject on
> references to COM objects that you have when you are done with them. COM
> depends on reference counting, and while garbage collection will ultimately
> take care of stray references that you have (and properly decrement the
> reference count, which will ultimately handle the disposing of the COM
> object that the Runtime Callable Wrapper holds on to), it isn't a good idea
> to not release the objects when you are done with them.
>
> In other words, don't remove the call in .NET 2.0 because you think it
> works.
>
> As for .NET 1.1, the ReleaseComObject method existed on the Marshal
> class in that version of the framework, so there is no reason you can't use
> it there.
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - m...@spam.guard.caspershouse.com
>
> <john...@gmail.com> wrote in message
>
> news:1179280286.509480.83450@n59g2000hsh.googlegroups.com...
>
>
>
> > We have a project in .NET 1.1 , some of the .NET methods take COM
> > interface reference pointer as a parameter, somehow we have to call
> > Marshal.ReleaseComObject to release the COM Object, otherwise the COM
> > object will never get release, Even we call gc.Collect()
>
> > But the same code compiles in .NET 2.0 works without the
> > Marshal.ReleaseComObject. (Unfortunately the project is supposed to
> > run on .NET 1.1.)
>
> > Is this a known problem? What is the remedy besides
> > Marshal.ReleaseComObject? (We know it is dangerous to call
> > Marshal.ReleaseComObject since we do not have total control of the
> > COM
> > interface pointer )
>
> > Thanks in advance.
> > John- Hide quoted text -
>
> - Show quoted text -


johnxhc

5/16/2007 6:00:00 PM

0

Thanks.
Yes, we tried it, we still need to call RealeaseComObject to get it
working.
John
On May 16, 12:28 am, Christian Fröschlin <froesch...@mvtec.com> wrote:
> john...@gmail.com wrote:
> > We have a project in .NET 1.1 , some of the .NET methods take COM
> > interface reference pointer as a parameter, somehow we have to call
> > Marshal.ReleaseComObject to release the COM Object, otherwise the COM
> > object will never get release, Even we call gc.Collect()
>
> The COM reference will be released in the finalizer, so to get
> the same immediate effect as with Marshal.ReleaseComObject, try
>
> GC.Collect()
> GC.WaitForPendingFinalizers()
>
> You should carefully consider where you place this code,
> as calling a multiple waits simultaneously from different
> threads may cause a deadlock.


Nicholas Paldino [.NET/C# MVP]

5/16/2007 8:08:00 PM

0

See inline:

> 1) How come in .NET 1.1, the COM object is not released even after I
> called gc.Collect multiple times as following
>
> GC.Collect();
> GC.WaitForPendingFinalizers();
> GC.Collect();
>
> If the above code releases the COM object, I would not be so puzzled.
>
> But in .NET 2.0 it was release right away.

Without seeing the rest of the code, it is impossible to say, but the
only reason the COM reference would be sticking around is if something was
holding a reference to the wrapper and that wrapper had not been passed to
ReleaseComObject.

> 2) In our code, we have one method, take the COM object, stored it in
> an ArrayList, in the second method , we take the same COM object, here
> we search the ArrayList, remove the COM object from the ArrayList, it
> is here where I call the ReleaseComObject
>
> For the same .Net method. One is called by VC++ client, I only need
> to call ReleaseComObject once, but for the VB client I have to call
> ReleaseComObject 3 times before the object is release
>
> If I keep calling ReleaseComObject until the return value is 0, then
> I will get an exception
> "COM object that has been separated from its underlying RCW can not
> be used."
>
> That got me really worried , why 3 times ? Is it possible for me to
> get the exception by calling ReleaseComObject 3 times? (Because we
> have not control how the client is using our framework)

I don't think you should be calling ReleaseComObject three times. As a
matter of fact, you shouldn't be calling it at all in this case. If the
same object is going to be placed into the ArrayList, then you shouldn't be
calling ReleaseComObject on the object you take out, as it is going to
invalidate the wrapper that you are placing into the ArrayList in its place.
Basically, you should be releasing the object when you are done with it
(which you aren't in this case).


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

>
> Please advice.
> Thanks so much for your help.
> John
>
> On May 15, 7:03 pm, "Nicholas Paldino [.NET/C# MVP]"
> <m...@spam.guard.caspershouse.com> wrote:
>> John,
>>
>> Regardless of version, you should be calling ReleaseComObject on
>> references to COM objects that you have when you are done with them. COM
>> depends on reference counting, and while garbage collection will
>> ultimately
>> take care of stray references that you have (and properly decrement the
>> reference count, which will ultimately handle the disposing of the COM
>> object that the Runtime Callable Wrapper holds on to), it isn't a good
>> idea
>> to not release the objects when you are done with them.
>>
>> In other words, don't remove the call in .NET 2.0 because you think
>> it
>> works.
>>
>> As for .NET 1.1, the ReleaseComObject method existed on the Marshal
>> class in that version of the framework, so there is no reason you can't
>> use
>> it there.
>>
>> --
>> - Nicholas Paldino [.NET/C# MVP]
>> - m...@spam.guard.caspershouse.com
>>
>> <john...@gmail.com> wrote in message
>>
>> news:1179280286.509480.83450@n59g2000hsh.googlegroups.com...
>>
>>
>>
>> > We have a project in .NET 1.1 , some of the .NET methods take COM
>> > interface reference pointer as a parameter, somehow we have to call
>> > Marshal.ReleaseComObject to release the COM Object, otherwise the COM
>> > object will never get release, Even we call gc.Collect()
>>
>> > But the same code compiles in .NET 2.0 works without the
>> > Marshal.ReleaseComObject. (Unfortunately the project is supposed to
>> > run on .NET 1.1.)
>>
>> > Is this a known problem? What is the remedy besides
>> > Marshal.ReleaseComObject? (We know it is dangerous to call
>> > Marshal.ReleaseComObject since we do not have total control of the
>> > COM
>> > interface pointer )
>>
>> > Thanks in advance.
>> > John- Hide quoted text -
>>
>> - Show quoted text -
>
>


Willy Denoyette [MVP]

5/17/2007 12:28:00 PM

0

<johnxhc@gmail.com> wrote in message
news:1179338376.262658.203290@e65g2000hsc.googlegroups.com...
Thanks.
Yes, we tried it, we still need to call RealeaseComObject to get it
working.

Sure, RealeaseComObject is meant to decrease the reference count on the RCW,
the finalizer is meant to run the finalize method on the RCW whenever it's
reference count is 0. So, as long as the reference count is > 0, the
finalizer will do nothing.

Willy.