Why aren't these objects being kept alive

[MikeP]

Hi there,

This is actually (probably) a C# or .NET issue. I'm working on an VS 2005
AddIn and at one point I'm caching all "EnvDTE80.ErrorItem" objects that
result from compiling one or more projects in an arbitrary solution (which
my own code carries out). These objects simply store each warning, error or
other message as seen in the "Error List" window in VS (when you build a
solution). Later on, when I attempt to look at the properties of some (but
not all) of these objects while debuugging, each property is throwing a
"System.Runtime.InteropServices.COMException". It doesn't happen at first
(right after compiling various projects) but only later on after all
compiling is complete. It appears to me (though I'm not certain) that the
properties are being generated on-the-fly and whatever underlying objects
they rely on to retrieve this info are dead by the time I need them. My
question is why? Shouldn't these objects be kept alive as long as my own
collection of "ErrorItem" objects remain alive? Isn't this how things work
in .NET? Thanks in advance..

[Samuel R. Neff]

That's how .NET works to keep .NET managed objects alive, yes.
However, in this case you're dealing with .NET wrappers of native
objects. Your references keep the .NET wrappers alive (and that's why
you don't get a null reference exception), but apparently the
underlying native objects are being destroyed (not necessarily because
they are out of scope, but more likely 'cause the routine that created
them no longer needs them and thus specifically destroys them).

I hope this helps explain the paradox you're seeing, but unfortunately
I don't have a solution to the underlying problem of needing that data
later on (unless you can cache it while it's available yourself--the
real data, not the references).

HTH,

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

On Fri, 7 Sep 2007 11:08:41 -0400, "MikeP" <no_spam@_nospam.com>
wrote:

>Hi there,

This is actually (probably) a C# or .NET issue. I'm working on an VS 2005
AddIn and at one point I'm caching all "EnvDTE80.ErrorItem" objects that
result from compiling one or more projects in an arbitrary solution (which
my own code carries out). These objects simply store each warning, error or
other message as seen in the "Error List" window in VS (when you build a
solution). Later on, when I attempt to look at the properties of some (but
not all) of these objects while debuugging, each property is throwing a
"System.Runtime.InteropServices.COMException". It doesn't happen at first
(right after compiling various projects) but only later on after all
compiling is complete. It appears to me (though I'm not certain) that the
properties are being generated on-the-fly and whatever underlying objects
they rely on to retrieve this info are dead by the time I need them. My
question is why? Shouldn't these objects be kept alive as long as my own
collection of "ErrorItem" objects remain alive? Isn't this how things work
in .NET? Thanks in advance..

[MikeP]

That's how .NET works to keep .NET managed objects alive, yes.

However, in this case you're dealing with .NET wrappers of native
objects. Your references keep the .NET wrappers alive (and that's why
you don't get a null reference exception), but apparently the
underlying native objects are being destroyed (not necessarily because
they are out of scope, but more likely 'cause the routine that created
them no longer needs them and thus specifically destroys them).

I hope this helps explain the paradox you're seeing, but unfortunately
I don't have a solution to the underlying problem of needing that data
later on (unless you can cache it while it's available yourself--the
real data, not the references).

Thanks for the reply. I still don't see why they're being prematurely killed
off however. The .NET wrappers should keep them alive since I'm keeping them
alive. Any underlying COM objects for instance should be maintained so long
as their reference count doesn't drop to zero. The .NET object itself
shouldn't allow that until I release it (or so the theory goes).