Develop Reference

Do I absolutely need to call ReleaseComObject on every MSHTML object?

I'm using MSHTML with a WebBrowser control because it gives me access to things the WebBrowser doesn't such as text nodes. I've seen several posts here and on the web where people say you must call ReleaseComObject for every COM object you reference. So, say I do this:
var doc = myBrowser.Document.DomDocument as IHTMLDocument2;
Do I need to release doc? How body in this code:
var body = (myBrowser.Document.DomDocument as IHTMLDocument2).body;
Aren't these objects wrapped by a RCW that would release them as soon as there are no more references to them? If not, would it be a good idea to create a wrapper for each of them with a finalizer (instead of using Dispose) that would release them as soon as the garbage collector kicks in (such that I don't need to worry about manually disposing them)?
The thing is, my application has a memory leak and I believe is related to this. According to ANTS memory profiler, one of the functions (among many others that happen to use MSHTML objects) that is holding a reference to a bunch of Microsoft.CSharp.RuntimeBinder.Semantics.LocalVariableSymbol objects which are on the top list of objects using memory in Generation 2 is this one:
internal static string GetAttribute(this IHTMLDOMNode element, string name)
{
var attribute = element.IsHTMLElement() ? ((IHTMLElement)element).getAttribute(name) : null;
if (attribute != null) return attribute.ToString();
return "";
}
Not sure what's wrong here since attribute is just a string.
Here is another function that is shown on the ANTS profiler's Instance Retention Graph (I added a bunch of FinalReleaseComObjects but is still shown):
private void InjectFunction(IHTMLDocument2 document)
{
if (null == Document) throw new Exception("Cannot access current document's HTML or document is not an HTML.");
try
{
IHTMLDocument3 doc3 = document as IHTMLDocument3;
IHTMLElementCollection collection = doc3.getElementsByTagName("head");
IHTMLDOMNode head = collection.item(0);
IHTMLElement scriptElement = document.createElement("script");
IHTMLScriptElement script = (IHTMLScriptElement)scriptElement;
IHTMLDOMNode scriptNode = (IHTMLDOMNode)scriptElement;
script.text = CurrentFuncs;
head.AppendChild(scriptNode);
if (Document.InvokeScript(CurrentTestFuncName) == null) throw new Exception("Cannot inject Javascript code right now.");
Marshal.FinalReleaseComObject(scriptNode);
Marshal.FinalReleaseComObject(script);
Marshal.FinalReleaseComObject(scriptElement);
Marshal.FinalReleaseComObject(head);
Marshal.FinalReleaseComObject(collection);
//Marshal.FinalReleaseComObject(doc3);
}
catch (Exception ex)
{
throw ex;
}
}
I added the ReleaseComObject but the function seems to still be holding a reference to something. Here is how my function looks like now:
private void InjectFunction(IHTMLDocument2 document)
{
if (null == Document) throw new Exception("Cannot access current document's HTML or document is not an HTML.");
try
{
IHTMLDocument3 doc3 = document as IHTMLDocument3;
IHTMLElementCollection collection = doc3.getElementsByTagName("head");
IHTMLDOMNode head = collection.item(0);
IHTMLElement scriptElement = document.createElement("script");
IHTMLScriptElement script = (IHTMLScriptElement)scriptElement;
IHTMLDOMNode scriptNode = (IHTMLDOMNode)scriptElement;
script.text = CurrentFuncs;
head.AppendChild(scriptNode);
if (Document.InvokeScript(CurrentTestFuncName) == null) throw new Exception("Cannot inject Javascript code right now.");
Marshal.FinalReleaseComObject(scriptNode);
Marshal.FinalReleaseComObject(script);
Marshal.FinalReleaseComObject(scriptElement);
Marshal.FinalReleaseComObject(head);
Marshal.FinalReleaseComObject(collection);
Marshal.ReleaseComObject(doc3);
}
catch (Exception ex)
{
MessageBox.Show("Couldn't release!");
throw ex;
}
}
The MessageBox.Show("Couldn't release!"); line is never hit so I assume everything is been released properly. Here is what ANTS shows:
I have no idea what that site container thing is.

The RCW will release the COM object when the RCW is finalized, so you don't need to create a wrapper that does this. You call ReleaseComObject because you don't want to wait around for the finalization; this is the same rationale for the Dispose pattern. So creating wrappers that can be Disposed isn't a bad idea (and there are examples out there
For var doc = myBrowser.Document.DomDocument ...;, you should also capture .Document in a separate variable and ReleaseComObject it as well. Any time you reference a property of a COM object which produces another object, make sure to release it.
In GetAttribute, you're casting the element to another interface. In COM programming, that adds another reference. You'll need to do something like var htmlElement = (IHTMLElement) element; so you can release that as well.
Edit - this is the pattern to use when working with COM objects:
IHTMLElement element = null;
try
{
element = <some method or property returning a COM object>;
// do something with element
}
catch (Exception ex) // although the exception type should be as specific as possible
{
// log, whatever
throw; // not "throw ex;" - that makes the call stack think the exception originated right here
}
finally
{
if (element != null)
{
Marshal.ReleaseComObject(element);
element = null;
}
}
This should really be done for every COM object reference you have.

Probably this article brings in some light:
MSDN on how COM refcounting works and some basic rules when to call AddRef and Release
In your case, Release is ReleaseComObject

Calling dispose() on a reference to an IDisposable

I have some code to add attachments to an email. I'm adding them via the Stream overload of the Attachment class constructor. The code to do it looks like this:
List<UploadedDocument> docs = DataBroker.GetUploadedDocs(Convert.ToInt32(HttpContext.Current.Session["offer_id"].ToString()));
//no need to keep this in session
HttpContext.Current.Session["offer_id"] = null;
int counter = 1;
foreach (UploadedDocument doc in docs)
{
stream = new MemoryStream(doc.doc);
attach = new Attachment(stream, "Attachment-" + counter.ToString());
message.Attachments.Add(attach);
}
Where doc.doc is a byte array. I want to properly dispose of each attachment and stream, but I can't do it until the message has been sent, so I was thinking about just adding them to a List<Attachment> and List<Stream> and then iterating through and calling dispose.
Something like this:
List<Attachment> attachments;
List<Stream> streams;
//...
foreach(UploadedDocument doc in docs)
{
stream = new MemoryStream(doc.doc);
streams.Add(stream);
attach = new Attachment(stream,"Name");
attachments.Add(attach);
message.Attachments.Add(attach);
}
//other processing
emailClient.Send(message);
if(attachments != null)
{
foreach(Attachment attachment in attachments)
{
attachment.Dispose();
}
}
if(streams != null)
{
foreach(MemoryStream myStream in streams)
{
myStream.Dispose();
}
}
But something tells me that won't dispose them properly if there is still a reference floating around that hasn't gotten garbage collected or something. Any thoughts?

The simplest way to handle this is to just call Dispose() on the MailMessage.
MailMessage.Dispose will automatically dispose all attachments, which in turn will close/Dispose() all of the underlying streams.
//other processing
emailClient.Send(message);
message.Dispose(); // Or just wrap this entire block in a using statement

This is already implemented by MailMessage.Dispose method:
protected virtual void Dispose(bool disposing)
{
if (disposing && !this.disposed)
{
this.disposed = true;
if (this.views != null)
{
this.views.Dispose();
}
if (this.attachments != null)
{
this.attachments.Dispose();
}
if (this.bodyView != null)
{
this.bodyView.Dispose();
}
}
}
Just wrap usage of MailMessage into using statement and all resources, used by the MailMessage will be released after you leave using block:
using(var message = new MailMessage(from, to))
{
foreach (UploadedDocument doc in docs)
{
stream = new MemoryStream(doc.doc);
attach = new Attachment(stream, "Attachment-" + counter.ToString());
message.Attachments.Add(attach);
}
emailClient.Send(message);
}

There are already replies on right way (MailMessage.Dispose), so on "dispose them properly if there is still a reference...":
Dispose will (expected too) release resources at the moment of the call irrespective of who have references to the object. One of common approaches is to also have inner flag in the object that implements Dispose that will block any further calls by throwing "Object Disposed" exception.
You can (and probably already did) observe this behavior if you Dispose your streams before done using them. I.e. in your mail case you may try to dispose stream immediately after message.Attachments.Add(attach); which most likely will lead to "stream disposed" exception later during Send call.
Note that there are some objects like MemoryStream that have specially defined behavior after Dispose. I.e. MemoryStream blocks all calls except ToArray/Lenght/GetBuffer since one of the main purposes of this class is to give you resulting byte array of a stream. As side effect MemoryStream's Dispose is essentially only setting flag to block other calls (which is fine as this class does not have any native resources).

Is it OK doing a return from inside using block

I am doing a code review, and have found alot of code with the following format:
public MyResponse MyMethod(string arg)
{
using (Tracer myTracer = new Tracer(Constants.TraceLog))
{
MyResponse abc = new MyResponse();
// Some code
return abc;
}
}
When I run a code analysis I get a CA2000 warning Microsoft.Reliability
Should the code be rewritten as:
public MyResponse MyMethod(string arg)
{
MyResponse abc = new MyResponse();
using (Tracer myTracer = new Tracer(Constants.TraceLog))
{
// Some code
}
return abc;
}
Or does it not matter?
Edit
The line on which it is reporting the warning is:
MyResponse abc = new MyResponse();
MyResponse is a standard Dataset.
The full error message is:
Warning 150 CA2000 : Microsoft.Reliability : In method 'xxxxx(Guid, Guid)', object 'MyResponse ' is not disposed along all exception paths. Call System.IDisposable.Dispose on object 'MyResponse ' before all references to it are out of scope.

No, it doesn't matter.
The finally block that's implicitly generated by the using statement to handle disposal will execute no matter where you put the return.
Are you sure that the CA2000 relates to myTracer and not abc? I would guess that the warning is occurring because MyResponse implements IDisposable and you're not disposing abc before returning. (Either way, your suggested rewrite should make no difference to the warning.)

Your rewrite will not fix that CA2000 warning, because the problem is not the Tracer object, but the MyResponse object.
The documentation states:
The following are some situations where the using statement is not enough to protect IDisposable objects and can cause CA2000 to occur.
Returning a disposable object requires that the object is constructed in a try/finally block outside a using block.
To fix the warning without messing with the stack trace of your exceptions (<- click, it's a link), use this code:
public MyResponse MyMethod(string arg)
{
MyResponse tmpResponse = null;
MyResponse response = null;
try
{
tmpResponse = new MyResponse();
using (Tracer myTracer = new Tracer(Constants.TraceLog))
{
// Some code
}
response = tmpResponse;
tmpResponse = null;
}
finally
{
if(tmpResponse != null)
tmpResponse .Dispose();
}
return response;
}
Why? Please see the example in the linked documentation.

The warning is probably about MyResponse, which is IDisposable.
Why does the warning appear?
If a MyResponse object is constructed, but code later in the method causes an exception to be thrown, then all references to this object will be lost (we only had one, and didn't manage to return it). This means that Dispose cannot be called on the object anymore, and we will be relying on the class finalizer to clean up any resources.
Does it matter?
Generally speaking, it will only matter if:
The IDisposable encapsulates a resource that might be needed "soon" by other parts of the program or by another process
An exception is thrown before the method returns, to trigger the "problem"
That resource is not released by the finalizer soon enough, or for some reason the finalizer never runs but your application doesn't go down
So no, it shouldn't really matter.
How to fix it?
public MyResponse MyMethod(string arg)
{
MyResponse abc = null;
try {
abc = new MyResponse();
using (Tracer myTracer = new Tracer(Constants.TraceLog))
{
// Some code
return abc;
}
}
catch {
if (abc != null) {
abc.Dispose();
}
throw;
}
}
This ensures that if control exits the method by means of an exception, abc is either null or has been properly disposed.
Update
It turns out when using this way of handling things, an exception explicitly thrown from inside MyMethod will be rethrown and have the line number of the first stack frame mutated to point to the throw; statement.
Practically this means that if you have multiple throw statements inside MyResponse, and they throw the same type of exception with the same message, you will not be able to tell which throw was responsible exactly when you catch the exception.
This is IMHO a purely academic problem, but I mention it for completeness.

It doesn't really matter. But, contrary to #Aliostad, I think version 2, with the return outside of the using block is better style.
My rationale goes like this:
The using block denotes something that is "opened" and "closed". This is a kind of cheep transaction. Closing the using block says we have done our work and it is safe now to continue with other stuff, like returning.

This warning is probably related to the principle of "single exit point". It is discussed here: http://c2.com/cgi/wiki?SingleFunctionExitPoint

How to dispose of an object that is iterated through via its Next property?

I have an object that uses some underlying native resources, and has a pointer to the next instance, which I iterate through similar to:
MyObject begin = null;
try
{
begin = GetFirst();
while (begin != null)
{
MyObject next = begin.Next();
// do something with begin
begin.Dispose();
begin = next;
}
}
finally
{
if (begin != null)
{
begin.Dispose();
}
}
I get the code analysis problem:
CA2202: Microsoft.Usage: Object 'begin' can be disposed more than once in method 'x()'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object.
Any idea how I can get rid of this error without suppressing it?

It certainly seems to me that your last block of code is unnecessary. If begin != null, then your while loop should have continued, no?
UPDATE: It looks like you're trying to ensure the last obtained value for begin is disposed in case an exception is thrown. Try this:
MyObject begin = GetFirst();
while (begin != null)
{
MyObject next;
using (begin)
{
next = begin.Next();
// do something with begin
}
begin = next;
}
Note that in the above suggestion, it could actually still happen that you end up with an undisposed object: the last value assigned to next, before the end of the using block. This scenario wasn't covered in your original question, so I haven't addressed it in the above suggestion. It's something to consider, though, if that's a potential problem.

It appears that Code Analysis considers it possible for an exception to occur during the Dispose() method. Were that to be the case, you would enter the finally block with an already-disposed-albeit-non-null reference to begin.
Note that I would only prefer this approach to #Dan's if you plan to wrap the call to begin.Dispose() in additional error trapping and handling. IMO, Dan's solution is more elegant.
Here is a try-finally approach that removes the warning:
MyObject begin = GetFirst();
MyObject next = null;
while (begin != null)
{
try
{
next = begin.Next();
// do something with begin
}
finally
{
begin.Dispose();
begin = next;
}
}

You obviously have some mechanism for identifying the first item in the chain, perhaps some other object or some static that is storing the first item?
How about in your code that is originally calling dispose:
GetFirst().Dispose();
Then the only responsibility for the dispose method is to dispose the current item and it's children:
public void Dispose()
{
if (Next() != null)
{
Next().Dispose();
}
}
This eliminates any need to loop within the dispose method. I would also take a look at the dispose pattern

What does using(object obj = new Object()) mean?

What does this statement means in C#?
using (object obj = new object())
{
//random stuff
}

It means that obj implements IDisposible and will be properly disposed of after the using block. It's functionally the same as:
{
//Assumes SomeObject implements IDisposable
SomeObject obj = new SomeObject();
try
{
// Do more stuff here.
}
finally
{
if (obj != null)
{
((IDisposable)obj).Dispose();
}
}
}

using (object obj = new object())
{
//random stuff
}
Is equivalent to:
object obj = new object();
try
{
// random stuff
}
finally {
((IDisposable)obj).Dispose();
}

why does it exist tho.
It exists for classes where you care about their lifetime, in particular where the class wraps a resource in the OS and you want to release it immediately. Otherwise you would have to wait for the CLR's (non deterministic) finalizers.
Examples, file handles, DB connections, socket connections, ....

it is a way to scope an object so the dispose method is called on exit. It is very useful for database connections in particuler. a compile time error will occur if the object does not implement idisposable

using ensures the allocated object is properly disposed after the using block, even when an unhandled exception occurs in the block.