osdir.com
mailing list archive

Subject: Re: should i treat COM Objects as IDisposeable things - msg#00087

List: windows.devel.dotnet.cx

Date: Prev Next Index Thread: Prev Next Index
IDispatch has no bearing on this. The rules are the same regardless of
whether the object reference came back via late or early binding. The
significant part is that you obtained an object reference through
interop.

(And the same would apply if you got it from an enumerator too.)

And by the way, the reference counting is kind of similarish to COM, in
that, as you point out, things get addrefed when they are passed to you.
But they're actually not the same. Consider this C# class that
implements a COM interface:


public class Foo : ISomeComInterface
{
public void Spong(ISomeOtherComInterface bar)
{
bar.Quux();
}
}

Suppose that Spong is the only member of ISomeComInterface. (Other than
the basic IUnknown members, obviously.) This Spong method is passed
another COM interface as a parameter. And let's suppose that some
non-.NET client is going to call this Spong method on our .NET object
via COM interop.

The reference counting rules for COM are not the same as those for the
RCW in this case.

For COM, the rule here is that the interface is AddRefed for you before
it gets passed in, and is Released for you after you return. In other
words, you are not required to do any AddRefing or Releasing on a COM
object passed to you in this way *unless* you want to keep hold of a
reference to it after the call returns. In that case you would AddRef
it.

Compare this with the RCW reference count. As with COM, the RCW's
reference count will be incremented for you when the parameter is passed
in. But unlike in COM, it won't be decremented for you automatically
when you return.

You could sum up the difference like this:

* COM assumes you won't be holding onto the object reference when the
method returns
* The RCW assumes you *will* be holding onto the object reference when
the method returns.

So if you don't plan to keep hold of the object reference, then the
method should really look like this:


public void Spong(ISomeOtherComInterface bar)
{
bar.Quux();
Marshal.ReleaseComObject(bar);
}

According to the COM rules of reference counting, this would be a
programming error. But with RCWs, it's how you tell the system you're
not holding onto the object after the method returns.



--
Ian Griffiths
DevelopMentor

> -----Original Message-----
> From: Barrie Green
>
> Right that makes sense, and its rather like how com works I guess, the
> interface that comes back from the rcw is addrefed and I have to call
> ReleaseCOMObject (release) when I want it to go away.
>
> I think I still have a problem though because I'm using idispatch i.e.
I
> just have an object, and I'm late binding to it.
>
> Unless the same applies to copying:
>
> If I have an object that was created by Activator.CreateInstance and I
> copy
> it to another object, is that doing the internal addreffing for me?
>
> Like
>
> Object comObject = Activator.CreateInstance(.........);
> Object copycomObject = comObject;
>
> I was assuming that this would produce code that would not work for me
> when
> I did this
>
> Marshal.ReleaseCOMObject(comObject); // would this kill one object or
zap
> // the entire underlying wrapper?
> // some time later
> copycomObject.dostuff() // bang!
>
> bg
>
> -----Original Message-----
> From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx]
> Sent: 21 January 2005 14:47
> To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable
things
>
> Say you have a COM object that has an interface something like (heres
the
> RCW not the IDL)
>
> class MyCOMObject
> {
> Public MyOtherCOMObject GetOtherCOMObject();
> Public void GiveMeOtherCOMObject(MyOtherCOMObject p);
> Public MyOtherCOMObject GetOtherCOMObjectIJustGaveYou();
> }
>
> And you had client code like this:
>
> MyCOMObject foo = new MyCOMObject();
>
> MyOtherCOMObject bar1 = foo.GetOtherCOMObject();
> foo.GiveMeOtherCOMObject(bar1);
> MyOtherCOMObject bar2 = foo.GetOtherCOMObjectIJustGaveYou();
>
> I'm pretty sure that bar1 and bar2 refer to the same RCW but it will
have
> an
> internal ref count of 2 so I can do
>
> Marshal.ReleaseCOMObject(bar1);
>
> And still use bar2 as the ReleaseCOMObject call simply decrements the
RCW
> ref count. Its only when I do
>
> Marshal.ReleaseCOMObject(bar2);
>
> That the underlying COM object gets destroyed.
>
> Regards
>
> Richard Blewett - DevelopMentor
> Http://www.dotnetconsult.co.uk/weblog
> Http://www.dotnetconsult.co.uk
>
> > -----Original Message-----
> > From: Discussion relating to the specifics of the C# and
> > Managed C++ languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx]
> > On Behalf Of Barrie Green
> > Sent: 21 January 2005 14:32
> > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [DOTNET-CX] should i treat COM Objects as
> > IDisposeable things
> >
> > Sorry Richard that went straight over my head - what does
> > that mean in code (if I can be done simply ;)
> >
> > bg
> >
> > -----Original Message-----
> > From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx]
> > Sent: 21 January 2005 14:18
> > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [DOTNET-CX] should i treat COM Objects as
> > IDisposeable things
> >
> > As in sending the rcw back to the COM sode and then
> > retrieving it into another variable (I think this raised the
> > RCW ref count) - it definitely will if you get the reference
> > back to another apartment.
> >
> > Regards
> >
> > Richard Blewett - DevelopMentor
> > Http://www.dotnetconsult.co.uk/weblog
> > Http://www.dotnetconsult.co.uk
> >
> > > -----Original Message-----
> > > From: Discussion relating to the specifics of the C# and
> > Managed C++
> > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx]
> > > On Behalf Of Barrie Green
> > > Sent: 21 January 2005 13:42
> > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [DOTNET-CX] should i treat COM Objects as
IDisposeable
> > > things
> > >
> > > What do u mean by "marshalling a new ref through COM",
> > create another
> > > (COM) Object?
> > >
> > > Object o1 = activator.blahblah("progid"); // one ref Object
> > > o2 = activator.blahblah("progid"); // second ref
> > >
> > > Not this surely?
> > >
> > > bg
> > >
> > > -----Original Message-----
> > > From: Matthew W. Adams [mailto:mwa@xxxxxxxxxxxxxxxxxxxxxx]
> > > Sent: 21 January 2005 12:58
> > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [DOTNET-CX] should i treat COM Objects as
IDisposeable
> > > things
> > >
> > > Thanks Richard - much more succinctly put than me!
> > >
> > > Plus there's the all-new Whidbey API... is it called
> > > ReleaseComObjectFinal, or FinalReleaseComObject, or similar, which
> > > also forces a release, regardless of concurrency issues.
> > >
> > > Further, the RCW has an optimization that it *doesn't* addref for
> > > multiple users inside an MTA, so the ref count can be all to heck
> > > anyway, IIRC.
> > >
> > > M
> > >
> > > Matthew Adams
> > > Director of R&D
> > > Digital Healthcare Ltd
> > >
> > > > -----Original Message-----
> > > > From: Discussion relating to the specifics of the C# and
> > > Managed C++
> > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On Behalf
> > > Of Richard
> > > > Blewett
> > > > Sent: 21 January 2005 12:49
> > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as
> > IDisposeable
> > > things
> > > >
> > > > I think what Matthew is referring to is if you pass the
> > reference to
> > > the
> > > > RCW
> > > > around on the .NET side (rather than marshalling a new ref
through
> > > COM)
> > > > then
> > > > the RCW doesn't know about the new .NET ref and so can't up its
> > > internal
> > > > ref
> > > > count
> > > >
> > > > Richard Blewett - DevelopMentor
> > > > http://www.dotnetconsult.co.uk/weblog
> > > > http://www.dotnetconsult.co.uk
> > > >
> > > > > -----Original Message-----
> > > > > From: Discussion relating to the specifics of the C# and
> > > Managed C++
> > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx]
> > > > > On Behalf Of Ian Griffiths
> > > > > Sent: 21 January 2005 12:10
> > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as
> > > IDisposeable
> > > > > things
> > > > >
> > > > > I thought the RCW had its own reference count, one which was
> > > > > independent of the COM reference count.
> > > > >
> > > > > My understanding was that the RCW reference count gets
> > > incremented
> > > > > each time you marshal the COM object into the AppDomain
> > > through an
> > > > > interop boundary of some kind. It is decremented each
> > > time you call
> > > > > Marshal.ReleaseComObject. And the RCW doesn't really call
> > > > > IUnknown::Release on the underlying COM object until its own
> > > > > reference count drops to zero.
> > > > >
> > > > > So if you write code like this:
> > > > >
> > > > > // assume for this example that 'something'
> > > > > // is a COM object, so this next line is
> > > > > // making a COM interop call to a method that
> > > > > // returns a COM interface.
> > > > >
> > > > > ISomeInterface obj = something.GetComObject();
> > > > >
> > > > > obj.DoStuff();
> > > > > Marshal.ReleaseComObject(obj);
> > > > >
> > > > > The first line will increment the RCW's reference
> > count, and the
> > > > > final line will decrement it. If some other part of the
> > > program was
> > > > > using the same COM object, it would already have caused
> > the RCW's
> > > > > reference count to be 1 or more. So this snippet of code
> > > here won't
> > > > > cause the RCW ref count to drop to 0, meaning that it
> > won't cause
> > > > > the underlying COM object to be released.
> > > > >
> > > > > In other words, using Marshal.ReleaseComObject() doesn't
> > > necessarily
> > > > > mess things up for other users of the same RCW.
> > > > >
> > > > > At least I *thought* that was how it worked last time I
> > > wrote some
> > > > > tests...
> > > > >
> > > > > I've occasionally seen people do this:
> > > > >
> > > > > // Barf
> > > > > while (Marshal.ReleaseComObject(obj) > 0) { }
> > > > >
> > > > > Because ReleaseComObject always returns the current RCW
> > reference
> > > > > count (and this *is* guaranteed to be the case, unlike
> > the return
> > > > > value of
> > > > > IUnknown::Release) this is way of forcing the RCW to be
> > > torn down.
> > > > > And this definitely will mess you up if other bits of
> > > your program
> > > > > are using the same COM object. I'd never do this - if you
ever
> > > > > think you need to do this, a better solution is probably
> > > to work out
> > > > > why your RCW seems to have more outstanding references than
you
> > > > > thought it should...
> > > > >
> > > > > Of course there's also Marshal.Release() - that's an
> > > altogether more
> > > > > grungy thing though.
> > > > >
> > > > >
> > > > > --
> > > > > Ian Griffiths
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Matthew W. Adams
> > > > > >
> > > > > > But beware of using multiple instances of the COM object
> > > > > (via its RCW)
> > > > > > concurrently. I believe that the RCW can reuse the
> > > underlying COM
> > > > > object
> > > > > > it allocated on your behalf, and Marshal.ReleaseComObject
> > > > > will release
> > > > > > that underlying instance, regardless of the number of RCW
> > > references
> > > > > to
> > > > > > it.
> > > > > >
> > > > > > M
> > > > > >
> > > > > > Matthew Adams
> > > > > > Director of R&D
> > > > > > Digital Healthcare
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Discussion relating to the specifics of the C# and
> > > > > Managed C++
> > > > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On
> > > > > Behalf Of I D. G
> > > > > > > Sent: 20 January 2005 21:56
> > > > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx
> > > > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as
> > > > > IDisposeable
> > > > > > things
> > > > > > >
> > > > > > > As a general rule, yes, you should. (And yes,
> > > > > > Marshal.ReleaseComObject
> > > > > > > is the one to use.) If you don't you'll be waiting
> > > until the GC
> > > > > runs
> > > > > > > before your COM objects get released.
> > > > > > >
> > > > > > > There may be cases where this doesn't matter - it depends
on
> > > your
> > > > > COM
> > > > > > > objects. But unless you are absolutely certain that you
> > > > > don't care
> > > > > > when
> > > > > > > they get released, you need to make sure you release them
> > > > > manually.
> > > > > > > (And also, bear in mind that there are some costs
associated
> > > with
> > > > > > > interop wrappers. So even if you don't need the COM
objects
> > > > > > themselves
> > > > > > > to be released in a timely fashion, it might be
> > worth doing it
> > > > > anyway.
> > > > > > > (It would depend on how many you create, and how long you
> > > normally
> > > > > use
> > > > > > > them for.)
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ian Griffiths
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Barrie Green
> > > > > > > >
> > > > > > > > If I have a wrapper around a Com object like this
> > > > > > > >
> > > > > > > > class LateBoundCOMObject
> > > > > > > > {
> > > > > > > > object _comObject;
> > > > > > > >
> > > > > > > > public LateBoundCOMObject(string ProgID)
> > > > > > > > {
> > > > > > > >
> > > > > > Activator.CreateInstance(Type.GetTypeFromProgID(ProgID));
> > > > > > > > }
> > > > > > > >
> > > > > > > > public object Invoke(string methodName,
> > > params object
> > > []
> > > > > > args)
> > > > > > > > {
> > > > > > > > return Invoke(methodName,
> > > BindingFlags.InvokeMethod,
> > > > > > > args);
> > > > > > > > }
> > > > > > > >
> > > > > > > > public object Invoke(string methodName,
> > BindingFlags
> > > > > > > bindingFlags,
> > > > > > > > params object [] args)
> > > > > > > > {
> > > > > > > > return
> > > _comObject.GetType().InvokeMember(methodName,
> > > > > > > > bindingFlags, null, _comObject, args);
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > > Should I implement IDisposable and release/destroy the
> > > > > object in a
> > > > > > > > finalizer/dispose pattern? Or should I let the
> > > runtime do it -
> > > > > > > presumably
> > > > > > > > by
> > > > > > > > a collection?
> > > > > > > >
> > > > > > > > If yes should I use Marshal.ReleaseComObject - I'm sure
> > > > > I've seen
> > > > > > > > something bad about using this somewhere.
> > > > > > >
> > > > > > > ===================================
> > > > > > > This list is hosted by DevelopMentor(r)
> > > http://www.develop.com
> > > > > > >
> > > > > > > View archives and manage your subscription(s) at
> > > > > > > http://discuss.develop.com
> > > > > >
> > > > > > ===================================
> > > > > > This list is hosted by DevelopMentor(r)
> > http://www.develop.com
> > > > > >
> > > > > > View archives and manage your subscription(s) at
> > > > > > http://discuss.develop.com
> > > > >
> > > > > ===================================
> > > > > This list is hosted by DevelopMentor. http://www.develop.com
> > > > >
> > > > > View archives and manage your subscription(s) at
> > > > > http://discuss.develop.com
> > > > >
> > > > > --
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG Anti-Virus.
> > > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date:
> > > 19/01/2005
> > > > >
> > > > >
> > > >
> > > > --
> > > > No virus found in this outgoing message.
> > > > Checked by AVG Anti-Virus.
> > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date:
> > > 19/01/2005
> > > >
> > > > ===================================
> > > > This list is hosted by DevelopMentor(r) http://www.develop.com
> > > >
> > > > View archives and manage your subscription(s) at
> > > > http://discuss.develop.com
> > >
> > > ===================================
> > > This list is hosted by DevelopMentor(r) http://www.develop.com
> > >
> > > View archives and manage your subscription(s) at
> > > http://discuss.develop.com
> > >
> > > ===================================
> > > This list is hosted by DevelopMentor(r) http://www.develop.com
> > >
> > > View archives and manage your subscription(s) at
> > > http://discuss.develop.com
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Anti-Virus.
> > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date:
> > 19/01/2005
> > >
> > >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date:
19/01/2005
> >
> >
> > ===================================
> > This list is hosted by DevelopMentor(r) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
> >
> > ===================================
> > This list is hosted by DevelopMentor(r) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date:
19/01/2005
> >
> >
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005
>
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com



Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: should i treat COM Objects as IDisposeable things

Right not sure if this helps anyone but If I add public object GetIDispatch() { return Marshal.GetTypedObjectForIUnknown(Marshal.GetIUnknownForObject(_comobject),t ypeof(object)); } Yes I know yuk, but it seems to increment the ref count on the original object, because ReleaseCOmObject returns 1 after calling it (whereas before it was 0) So it would appear I'm safe if I pass around copies of my original object via the above method, and call ReleaseCOMObject on it via dispose. There is also Marshal.ChangeWrapperHandleStrength <ms-help://MS.MSDNQTR.2005JAN.1033/cpref/html/frlrfsystemruntimeinteropservi cesmarshalclasschangewrapperhandlestrengthtopic.htm> which could presumably be used? bg -----Original Message----- From: Barrie Green [mailto:barrie.green@xxxxxxxxxxxxxxxxxxxxx] Sent: 21 January 2005 15:43 To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable things I wonder if Marshal.GetIDispatchForObject will help for me? I'll give it a go. All - Thanks for the help bg -----Original Message----- From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] Sent: 21 January 2005 15:20 To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable things Yep, in this case the second reference is only happening within the realm of .NET. The interop plumbing knows nothing about it - therefore the refcount on the RCW is still one which is why yours explodes Regards Richatrd Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk > -----Original Message----- > From: Discussion relating to the specifics of the C# and > Managed C++ languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > On Behalf Of Barrie Green > Sent: 21 January 2005 15:02 > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable things > > Right that makes sense, and its rather like how com works I > guess, the interface that comes back from the rcw is addrefed > and I have to call ReleaseCOMObject (release) when I want it > to go away. > > I think I still have a problem though because I'm using > idispatch i.e. I just have an object, and I'm late binding to it. > > Unless the same applies to copying: > > If I have an object that was created by > Activator.CreateInstance and I copy it to another object, is > that doing the internal addreffing for me? > > Like > > Object comObject = Activator.CreateInstance(.........); > Object copycomObject = comObject; > > I was assuming that this would produce code that would not > work for me when I did this > > Marshal.ReleaseCOMObject(comObject); // would this kill one > object or zap // the entire underlying wrapper? > // some time later > copycomObject.dostuff() // bang! > > bg > > -----Original Message----- > From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] > Sent: 21 January 2005 14:47 > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable things > > Say you have a COM object that has an interface something > like (heres the RCW not the IDL) > > class MyCOMObject > { > Public MyOtherCOMObject GetOtherCOMObject(); > Public void GiveMeOtherCOMObject(MyOtherCOMObject p); > Public MyOtherCOMObject GetOtherCOMObjectIJustGaveYou(); } > > And you had client code like this: > > MyCOMObject foo = new MyCOMObject(); > > MyOtherCOMObject bar1 = foo.GetOtherCOMObject(); > foo.GiveMeOtherCOMObject(bar1); MyOtherCOMObject bar2 = > foo.GetOtherCOMObjectIJustGaveYou(); > > I'm pretty sure that bar1 and bar2 refer to the same RCW but > it will have an internal ref count of 2 so I can do > > Marshal.ReleaseCOMObject(bar1); > > And still use bar2 as the ReleaseCOMObject call simply > decrements the RCW ref count. Its only when I do > > Marshal.ReleaseCOMObject(bar2); > > That the underlying COM object gets destroyed. > > Regards > > Richard Blewett - DevelopMentor > Http://www.dotnetconsult.co.uk/weblog > Http://www.dotnetconsult.co.uk > > > -----Original Message----- > > From: Discussion relating to the specifics of the C# and > Managed C++ > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > On Behalf Of Barrie Green > > Sent: 21 January 2005 14:32 > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable > > things > > > > Sorry Richard that went straight over my head - what does > that mean in > > code (if I can be done simply ;) > > > > bg > > > > -----Original Message----- > > From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] > > Sent: 21 January 2005 14:18 > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable > > things > > > > As in sending the rcw back to the COM sode and then > retrieving it into > > another variable (I think this raised the RCW ref count) - it > > definitely will if you get the reference back to another apartment. > > > > Regards > > > > Richard Blewett - DevelopMentor > > Http://www.dotnetconsult.co.uk/weblog > > Http://www.dotnetconsult.co.uk > > > > > -----Original Message----- > > > From: Discussion relating to the specifics of the C# and > > Managed C++ > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > > On Behalf Of Barrie Green > > > Sent: 21 January 2005 13:42 > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable > > > things > > > > > > What do u mean by "marshalling a new ref through COM", > > create another > > > (COM) Object? > > > > > > Object o1 = activator.blahblah("progid"); // one ref Object > > > o2 = activator.blahblah("progid"); // second ref > > > > > > Not this surely? > > > > > > bg > > > > > > -----Original Message----- > > > From: Matthew W. Adams [mailto:mwa@xxxxxxxxxxxxxxxxxxxxxx] > > > Sent: 21 January 2005 12:58 > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable > > > things > > > > > > Thanks Richard - much more succinctly put than me! > > > > > > Plus there's the all-new Whidbey API... is it called > > > ReleaseComObjectFinal, or FinalReleaseComObject, or > similar, which > > > also forces a release, regardless of concurrency issues. > > > > > > Further, the RCW has an optimization that it *doesn't* addref for > > > multiple users inside an MTA, so the ref count can be all to heck > > > anyway, IIRC. > > > > > > M > > > > > > Matthew Adams > > > Director of R&D > > > Digital Healthcare Ltd > > > > > > > -----Original Message----- > > > > From: Discussion relating to the specifics of the C# and > > > Managed C++ > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On Behalf > > > Of Richard > > > > Blewett > > > > Sent: 21 January 2005 12:49 > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > IDisposeable > > > things > > > > > > > > I think what Matthew is referring to is if you pass the > > reference to > > > the > > > > RCW > > > > around on the .NET side (rather than marshalling a new > ref through > > > COM) > > > > then > > > > the RCW doesn't know about the new .NET ref and so can't up its > > > internal > > > > ref > > > > count > > > > > > > > Richard Blewett - DevelopMentor > > > > http://www.dotnetconsult.co.uk/weblog > > > > http://www.dotnetconsult.co.uk > > > > > > > > > -----Original Message----- > > > > > From: Discussion relating to the specifics of the C# and > > > Managed C++ > > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > > > > On Behalf Of Ian Griffiths > > > > > Sent: 21 January 2005 12:10 > > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > > IDisposeable > > > > > things > > > > > > > > > > I thought the RCW had its own reference count, one which was > > > > > independent of the COM reference count. > > > > > > > > > > My understanding was that the RCW reference count gets > > > incremented > > > > > each time you marshal the COM object into the AppDomain > > > through an > > > > > interop boundary of some kind. It is decremented each > > > time you call > > > > > Marshal.ReleaseComObject. And the RCW doesn't really call > > > > > IUnknown::Release on the underlying COM object until its own > > > > > reference count drops to zero. > > > > > > > > > > So if you write code like this: > > > > > > > > > > // assume for this example that 'something' > > > > > // is a COM object, so this next line is > > > > > // making a COM interop call to a method that > > > > > // returns a COM interface. > > > > > > > > > > ISomeInterface obj = something.GetComObject(); > > > > > > > > > > obj.DoStuff(); > > > > > Marshal.ReleaseComObject(obj); > > > > > > > > > > The first line will increment the RCW's reference > > count, and the > > > > > final line will decrement it. If some other part of the > > > program was > > > > > using the same COM object, it would already have caused > > the RCW's > > > > > reference count to be 1 or more. So this snippet of code > > > here won't > > > > > cause the RCW ref count to drop to 0, meaning that it > > won't cause > > > > > the underlying COM object to be released. > > > > > > > > > > In other words, using Marshal.ReleaseComObject() doesn't > > > necessarily > > > > > mess things up for other users of the same RCW. > > > > > > > > > > At least I *thought* that was how it worked last time I > > > wrote some > > > > > tests... > > > > > > > > > > I've occasionally seen people do this: > > > > > > > > > > // Barf > > > > > while (Marshal.ReleaseComObject(obj) > 0) { } > > > > > > > > > > Because ReleaseComObject always returns the current RCW > > reference > > > > > count (and this *is* guaranteed to be the case, unlike > > the return > > > > > value of > > > > > IUnknown::Release) this is way of forcing the RCW to be > > > torn down. > > > > > And this definitely will mess you up if other bits of > > > your program > > > > > are using the same COM object. I'd never do this - > if you ever > > > > > think you need to do this, a better solution is probably > > > to work out > > > > > why your RCW seems to have more outstanding > references than you > > > > > thought it should... > > > > > > > > > > Of course there's also Marshal.Release() - that's an > > > altogether more > > > > > grungy thing though. > > > > > > > > > > > > > > > -- > > > > > Ian Griffiths > > > > > > > > > > > -----Original Message----- > > > > > > From: Matthew W. Adams > > > > > > > > > > > > But beware of using multiple instances of the COM object > > > > > (via its RCW) > > > > > > concurrently. I believe that the RCW can reuse the > > > underlying COM > > > > > object > > > > > > it allocated on your behalf, and Marshal.ReleaseComObject > > > > > will release > > > > > > that underlying instance, regardless of the number of RCW > > > references > > > > > to > > > > > > it. > > > > > > > > > > > > M > > > > > > > > > > > > Matthew Adams > > > > > > Director of R&D > > > > > > Digital Healthcare > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Discussion relating to the specifics of the C# and > > > > > Managed C++ > > > > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On > > > > > Behalf Of I D. G > > > > > > > Sent: 20 January 2005 21:56 > > > > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > > > > IDisposeable > > > > > > things > > > > > > > > > > > > > > As a general rule, yes, you should. (And yes, > > > > > > Marshal.ReleaseComObject > > > > > > > is the one to use.) If you don't you'll be waiting > > > until the GC > > > > > runs > > > > > > > before your COM objects get released. > > > > > > > > > > > > > > There may be cases where this doesn't matter - it > depends on > > > your > > > > > COM > > > > > > > objects. But unless you are absolutely certain that you > > > > > don't care > > > > > > when > > > > > > > they get released, you need to make sure you release them > > > > > manually. > > > > > > > (And also, bear in mind that there are some costs > associated > > > with > > > > > > > interop wrappers. So even if you don't need the > COM objects > > > > > > themselves > > > > > > > to be released in a timely fashion, it might be > > worth doing it > > > > > anyway. > > > > > > > (It would depend on how many you create, and how long you > > > normally > > > > > use > > > > > > > them for.) > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ian Griffiths > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Barrie Green > > > > > > > > > > > > > > > > If I have a wrapper around a Com object like this > > > > > > > > > > > > > > > > class LateBoundCOMObject > > > > > > > > { > > > > > > > > object _comObject; > > > > > > > > > > > > > > > > public LateBoundCOMObject(string ProgID) > > > > > > > > { > > > > > > > > > > > > > > Activator.CreateInstance(Type.GetTypeFromProgID(ProgID)); > > > > > > > > } > > > > > > > > > > > > > > > > public object Invoke(string methodName, > > > params object > > > [] > > > > > > args) > > > > > > > > { > > > > > > > > return Invoke(methodName, > > > BindingFlags.InvokeMethod, > > > > > > > args); > > > > > > > > } > > > > > > > > > > > > > > > > public object Invoke(string methodName, > > BindingFlags > > > > > > > bindingFlags, > > > > > > > > params object [] args) > > > > > > > > { > > > > > > > > return > > > _comObject.GetType().InvokeMember(methodName, > > > > > > > > bindingFlags, null, _comObject, args); > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > Should I implement IDisposable and release/destroy the > > > > > object in a > > > > > > > > finalizer/dispose pattern? Or should I let the > > > runtime do it - > > > > > > > presumably > > > > > > > > by > > > > > > > > a collection? > > > > > > > > > > > > > > > > If yes should I use Marshal.ReleaseComObject - I'm sure > > > > > I've seen > > > > > > > > something bad about using this somewhere. > > > > > > > > > > > > > > =================================== > > > > > > > This list is hosted by DevelopMentor(r) > > > http://www.develop.com > > > > > > > > > > > > > > View archives and manage your subscription(s) at > > > > > > > http://discuss.develop.com > > > > > > > > > > > > =================================== > > > > > > This list is hosted by DevelopMentor(r) > > http://www.develop.com > > > > > > > > > > > > View archives and manage your subscription(s) at > > > > > > http://discuss.develop.com > > > > > > > > > > =================================== > > > > > This list is hosted by DevelopMentor. http://www.develop.com > > > > > > > > > > View archives and manage your subscription(s) at > > > > > http://discuss.develop.com > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Anti-Virus. > > > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > > 19/01/2005 > > > > > > > > > > > > > > > > > > -- > > > > No virus found in this outgoing message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > > 19/01/2005 > > > > > > > > =================================== > > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > > > View archives and manage your subscription(s) at > > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > 19/01/2005 > > > > > > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > 19/01/2005 > > > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > 19/01/2005 > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 > > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com

Next Message by Date: click to view message preview

Re: should i treat COM Objects as IDisposeable things

Furthermore, the ref count on an RCW can be more than 1. Call ReleaseComObject() only decrements the ref count 1 time and unless the ref count goes to 0, the COM object hangs around. See Adam Nathan's COM/NET interop book pg 300 for reasons for this. Because of this, I typically do: if (_comObject != null) while (Marshal.ReleaseComObject(_comObject) > 0); For Whidbey, MS has provided a new method in Marshal to do the loop above for you. It is called FinalReleaseComObject method. BTW, Adam once told me that calling ReleaseComObject on a RCW during finalization would work in the current implementation of .NET, it isn't something that is guaranteed to work in the future. -- Keith > -----Original Message----- > From: Shawn A. Van Ness [mailto:savanness@xxxxxxxxx] > Sent: Thursday, January 20, 2005 5:31 PM > Subject: Re: should i treat COM Objects as IDisposeable things > > Shawn, IMHO you should consider taking Rich Blewett's advice, and lose > the finalizer. > > Rationale: if your DisposableCom instance is unreachable, then so is > the RCW (your '_comObject' field) -- both instances will be finalized > at the same time, but in which order, who knows? -- and the RCW's > finalizer will call Release() on your behalf. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com

Previous Message by Thread: click to view message preview

Re: should i treat COM Objects as IDisposeable things

Right not sure if this helps anyone but If I add public object GetIDispatch() { return Marshal.GetTypedObjectForIUnknown(Marshal.GetIUnknownForObject(_comobject),t ypeof(object)); } Yes I know yuk, but it seems to increment the ref count on the original object, because ReleaseCOmObject returns 1 after calling it (whereas before it was 0) So it would appear I'm safe if I pass around copies of my original object via the above method, and call ReleaseCOMObject on it via dispose. There is also Marshal.ChangeWrapperHandleStrength <ms-help://MS.MSDNQTR.2005JAN.1033/cpref/html/frlrfsystemruntimeinteropservi cesmarshalclasschangewrapperhandlestrengthtopic.htm> which could presumably be used? bg -----Original Message----- From: Barrie Green [mailto:barrie.green@xxxxxxxxxxxxxxxxxxxxx] Sent: 21 January 2005 15:43 To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable things I wonder if Marshal.GetIDispatchForObject will help for me? I'll give it a go. All - Thanks for the help bg -----Original Message----- From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] Sent: 21 January 2005 15:20 To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable things Yep, in this case the second reference is only happening within the realm of .NET. The interop plumbing knows nothing about it - therefore the refcount on the RCW is still one which is why yours explodes Regards Richatrd Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk > -----Original Message----- > From: Discussion relating to the specifics of the C# and > Managed C++ languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > On Behalf Of Barrie Green > Sent: 21 January 2005 15:02 > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable things > > Right that makes sense, and its rather like how com works I > guess, the interface that comes back from the rcw is addrefed > and I have to call ReleaseCOMObject (release) when I want it > to go away. > > I think I still have a problem though because I'm using > idispatch i.e. I just have an object, and I'm late binding to it. > > Unless the same applies to copying: > > If I have an object that was created by > Activator.CreateInstance and I copy it to another object, is > that doing the internal addreffing for me? > > Like > > Object comObject = Activator.CreateInstance(.........); > Object copycomObject = comObject; > > I was assuming that this would produce code that would not > work for me when I did this > > Marshal.ReleaseCOMObject(comObject); // would this kill one > object or zap // the entire underlying wrapper? > // some time later > copycomObject.dostuff() // bang! > > bg > > -----Original Message----- > From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] > Sent: 21 January 2005 14:47 > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable things > > Say you have a COM object that has an interface something > like (heres the RCW not the IDL) > > class MyCOMObject > { > Public MyOtherCOMObject GetOtherCOMObject(); > Public void GiveMeOtherCOMObject(MyOtherCOMObject p); > Public MyOtherCOMObject GetOtherCOMObjectIJustGaveYou(); } > > And you had client code like this: > > MyCOMObject foo = new MyCOMObject(); > > MyOtherCOMObject bar1 = foo.GetOtherCOMObject(); > foo.GiveMeOtherCOMObject(bar1); MyOtherCOMObject bar2 = > foo.GetOtherCOMObjectIJustGaveYou(); > > I'm pretty sure that bar1 and bar2 refer to the same RCW but > it will have an internal ref count of 2 so I can do > > Marshal.ReleaseCOMObject(bar1); > > And still use bar2 as the ReleaseCOMObject call simply > decrements the RCW ref count. Its only when I do > > Marshal.ReleaseCOMObject(bar2); > > That the underlying COM object gets destroyed. > > Regards > > Richard Blewett - DevelopMentor > Http://www.dotnetconsult.co.uk/weblog > Http://www.dotnetconsult.co.uk > > > -----Original Message----- > > From: Discussion relating to the specifics of the C# and > Managed C++ > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > On Behalf Of Barrie Green > > Sent: 21 January 2005 14:32 > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable > > things > > > > Sorry Richard that went straight over my head - what does > that mean in > > code (if I can be done simply ;) > > > > bg > > > > -----Original Message----- > > From: Richard Blewett [mailto:richard@xxxxxxxxxxxxxxxxxxx] > > Sent: 21 January 2005 14:18 > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [DOTNET-CX] should i treat COM Objects as IDisposeable > > things > > > > As in sending the rcw back to the COM sode and then > retrieving it into > > another variable (I think this raised the RCW ref count) - it > > definitely will if you get the reference back to another apartment. > > > > Regards > > > > Richard Blewett - DevelopMentor > > Http://www.dotnetconsult.co.uk/weblog > > Http://www.dotnetconsult.co.uk > > > > > -----Original Message----- > > > From: Discussion relating to the specifics of the C# and > > Managed C++ > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > > On Behalf Of Barrie Green > > > Sent: 21 January 2005 13:42 > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable > > > things > > > > > > What do u mean by "marshalling a new ref through COM", > > create another > > > (COM) Object? > > > > > > Object o1 = activator.blahblah("progid"); // one ref Object > > > o2 = activator.blahblah("progid"); // second ref > > > > > > Not this surely? > > > > > > bg > > > > > > -----Original Message----- > > > From: Matthew W. Adams [mailto:mwa@xxxxxxxxxxxxxxxxxxxxxx] > > > Sent: 21 January 2005 12:58 > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > IDisposeable > > > things > > > > > > Thanks Richard - much more succinctly put than me! > > > > > > Plus there's the all-new Whidbey API... is it called > > > ReleaseComObjectFinal, or FinalReleaseComObject, or > similar, which > > > also forces a release, regardless of concurrency issues. > > > > > > Further, the RCW has an optimization that it *doesn't* addref for > > > multiple users inside an MTA, so the ref count can be all to heck > > > anyway, IIRC. > > > > > > M > > > > > > Matthew Adams > > > Director of R&D > > > Digital Healthcare Ltd > > > > > > > -----Original Message----- > > > > From: Discussion relating to the specifics of the C# and > > > Managed C++ > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On Behalf > > > Of Richard > > > > Blewett > > > > Sent: 21 January 2005 12:49 > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > IDisposeable > > > things > > > > > > > > I think what Matthew is referring to is if you pass the > > reference to > > > the > > > > RCW > > > > around on the .NET side (rather than marshalling a new > ref through > > > COM) > > > > then > > > > the RCW doesn't know about the new .NET ref and so can't up its > > > internal > > > > ref > > > > count > > > > > > > > Richard Blewett - DevelopMentor > > > > http://www.dotnetconsult.co.uk/weblog > > > > http://www.dotnetconsult.co.uk > > > > > > > > > -----Original Message----- > > > > > From: Discussion relating to the specifics of the C# and > > > Managed C++ > > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] > > > > > On Behalf Of Ian Griffiths > > > > > Sent: 21 January 2005 12:10 > > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > > IDisposeable > > > > > things > > > > > > > > > > I thought the RCW had its own reference count, one which was > > > > > independent of the COM reference count. > > > > > > > > > > My understanding was that the RCW reference count gets > > > incremented > > > > > each time you marshal the COM object into the AppDomain > > > through an > > > > > interop boundary of some kind. It is decremented each > > > time you call > > > > > Marshal.ReleaseComObject. And the RCW doesn't really call > > > > > IUnknown::Release on the underlying COM object until its own > > > > > reference count drops to zero. > > > > > > > > > > So if you write code like this: > > > > > > > > > > // assume for this example that 'something' > > > > > // is a COM object, so this next line is > > > > > // making a COM interop call to a method that > > > > > // returns a COM interface. > > > > > > > > > > ISomeInterface obj = something.GetComObject(); > > > > > > > > > > obj.DoStuff(); > > > > > Marshal.ReleaseComObject(obj); > > > > > > > > > > The first line will increment the RCW's reference > > count, and the > > > > > final line will decrement it. If some other part of the > > > program was > > > > > using the same COM object, it would already have caused > > the RCW's > > > > > reference count to be 1 or more. So this snippet of code > > > here won't > > > > > cause the RCW ref count to drop to 0, meaning that it > > won't cause > > > > > the underlying COM object to be released. > > > > > > > > > > In other words, using Marshal.ReleaseComObject() doesn't > > > necessarily > > > > > mess things up for other users of the same RCW. > > > > > > > > > > At least I *thought* that was how it worked last time I > > > wrote some > > > > > tests... > > > > > > > > > > I've occasionally seen people do this: > > > > > > > > > > // Barf > > > > > while (Marshal.ReleaseComObject(obj) > 0) { } > > > > > > > > > > Because ReleaseComObject always returns the current RCW > > reference > > > > > count (and this *is* guaranteed to be the case, unlike > > the return > > > > > value of > > > > > IUnknown::Release) this is way of forcing the RCW to be > > > torn down. > > > > > And this definitely will mess you up if other bits of > > > your program > > > > > are using the same COM object. I'd never do this - > if you ever > > > > > think you need to do this, a better solution is probably > > > to work out > > > > > why your RCW seems to have more outstanding > references than you > > > > > thought it should... > > > > > > > > > > Of course there's also Marshal.Release() - that's an > > > altogether more > > > > > grungy thing though. > > > > > > > > > > > > > > > -- > > > > > Ian Griffiths > > > > > > > > > > > -----Original Message----- > > > > > > From: Matthew W. Adams > > > > > > > > > > > > But beware of using multiple instances of the COM object > > > > > (via its RCW) > > > > > > concurrently. I believe that the RCW can reuse the > > > underlying COM > > > > > object > > > > > > it allocated on your behalf, and Marshal.ReleaseComObject > > > > > will release > > > > > > that underlying instance, regardless of the number of RCW > > > references > > > > > to > > > > > > it. > > > > > > > > > > > > M > > > > > > > > > > > > Matthew Adams > > > > > > Director of R&D > > > > > > Digital Healthcare > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Discussion relating to the specifics of the C# and > > > > > Managed C++ > > > > > > > languages [mailto:DOTNET-CX@xxxxxxxxxxxxxxxxxxx] On > > > > > Behalf Of I D. G > > > > > > > Sent: 20 January 2005 21:56 > > > > > > > To: DOTNET-CX@xxxxxxxxxxxxxxxxxxx > > > > > > > Subject: Re: [DOTNET-CX] should i treat COM Objects as > > > > > IDisposeable > > > > > > things > > > > > > > > > > > > > > As a general rule, yes, you should. (And yes, > > > > > > Marshal.ReleaseComObject > > > > > > > is the one to use.) If you don't you'll be waiting > > > until the GC > > > > > runs > > > > > > > before your COM objects get released. > > > > > > > > > > > > > > There may be cases where this doesn't matter - it > depends on > > > your > > > > > COM > > > > > > > objects. But unless you are absolutely certain that you > > > > > don't care > > > > > > when > > > > > > > they get released, you need to make sure you release them > > > > > manually. > > > > > > > (And also, bear in mind that there are some costs > associated > > > with > > > > > > > interop wrappers. So even if you don't need the > COM objects > > > > > > themselves > > > > > > > to be released in a timely fashion, it might be > > worth doing it > > > > > anyway. > > > > > > > (It would depend on how many you create, and how long you > > > normally > > > > > use > > > > > > > them for.) > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ian Griffiths > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Barrie Green > > > > > > > > > > > > > > > > If I have a wrapper around a Com object like this > > > > > > > > > > > > > > > > class LateBoundCOMObject > > > > > > > > { > > > > > > > > object _comObject; > > > > > > > > > > > > > > > > public LateBoundCOMObject(string ProgID) > > > > > > > > { > > > > > > > > > > > > > > Activator.CreateInstance(Type.GetTypeFromProgID(ProgID)); > > > > > > > > } > > > > > > > > > > > > > > > > public object Invoke(string methodName, > > > params object > > > [] > > > > > > args) > > > > > > > > { > > > > > > > > return Invoke(methodName, > > > BindingFlags.InvokeMethod, > > > > > > > args); > > > > > > > > } > > > > > > > > > > > > > > > > public object Invoke(string methodName, > > BindingFlags > > > > > > > bindingFlags, > > > > > > > > params object [] args) > > > > > > > > { > > > > > > > > return > > > _comObject.GetType().InvokeMember(methodName, > > > > > > > > bindingFlags, null, _comObject, args); > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > Should I implement IDisposable and release/destroy the > > > > > object in a > > > > > > > > finalizer/dispose pattern? Or should I let the > > > runtime do it - > > > > > > > presumably > > > > > > > > by > > > > > > > > a collection? > > > > > > > > > > > > > > > > If yes should I use Marshal.ReleaseComObject - I'm sure > > > > > I've seen > > > > > > > > something bad about using this somewhere. > > > > > > > > > > > > > > =================================== > > > > > > > This list is hosted by DevelopMentor(r) > > > http://www.develop.com > > > > > > > > > > > > > > View archives and manage your subscription(s) at > > > > > > > http://discuss.develop.com > > > > > > > > > > > > =================================== > > > > > > This list is hosted by DevelopMentor(r) > > http://www.develop.com > > > > > > > > > > > > View archives and manage your subscription(s) at > > > > > > http://discuss.develop.com > > > > > > > > > > =================================== > > > > > This list is hosted by DevelopMentor. http://www.develop.com > > > > > > > > > > View archives and manage your subscription(s) at > > > > > http://discuss.develop.com > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Anti-Virus. > > > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > > 19/01/2005 > > > > > > > > > > > > > > > > > > -- > > > > No virus found in this outgoing message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > > 19/01/2005 > > > > > > > > =================================== > > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > > > View archives and manage your subscription(s) at > > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > > 19/01/2005 > > > > > > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > 19/01/2005 > > > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: > 19/01/2005 > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 > > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com

Next Message by Thread: click to view message preview

Re: should i treat COM Objects as IDisposeable things

Furthermore, the ref count on an RCW can be more than 1. Call ReleaseComObject() only decrements the ref count 1 time and unless the ref count goes to 0, the COM object hangs around. See Adam Nathan's COM/NET interop book pg 300 for reasons for this. Because of this, I typically do: if (_comObject != null) while (Marshal.ReleaseComObject(_comObject) > 0); For Whidbey, MS has provided a new method in Marshal to do the loop above for you. It is called FinalReleaseComObject method. BTW, Adam once told me that calling ReleaseComObject on a RCW during finalization would work in the current implementation of .NET, it isn't something that is guaranteed to work in the future. -- Keith > -----Original Message----- > From: Shawn A. Van Ness [mailto:savanness@xxxxxxxxx] > Sent: Thursday, January 20, 2005 5:31 PM > Subject: Re: should i treat COM Objects as IDisposeable things > > Shawn, IMHO you should consider taking Rich Blewett's advice, and lose > the finalizer. > > Rationale: if your DisposableCom instance is unreachable, then so is > the RCW (your '_comObject' field) -- both instances will be finalized > at the same time, but in which order, who knows? -- and the RCW's > finalizer will call Release() on your behalf. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by