IDisposable with COM
-
I have an application that uses a COM object to make a connection to an application. I need to make sure that when my application ends that I call the EndSession and CloseConnection methods of this COM object. I was reading this article: Implementing IDisposable and the Dispose Pattern Properly[^] as I think this is what I would need to do to make sure my closing code always gets called, but it doesn't seem to happen when I stop debugging. The application that I am connecting to still thinks my program is connected. It seems like when I stop debugging (or if I have a program crash, that the Dispose methods don't get called. I also tried to add a Finalizer but that causes a System.Runtime.InteropServices.InvalidComObjectException stating that the COM object that has been separated from it's underlying RCW cannot be used.
private bool disposed;
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (_Session != null) // _Session is the COM object.
{
_Session.EndSession(); // These are the COM functions to close and end the
_Session.CloseConnection(); // session that must be called, but this is where I
_Session = null; // get the InvalidComObjectException.
}
disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);}
~SessionConnection() // This was added, which seems to be the root cause of the COM exception
{
Dispose(false);
}I'm not sure what is the best way to ensure that the EndSession and CloseConnection methods of my COM object get called even if my program crashes or I stop debugging.
-
I have an application that uses a COM object to make a connection to an application. I need to make sure that when my application ends that I call the EndSession and CloseConnection methods of this COM object. I was reading this article: Implementing IDisposable and the Dispose Pattern Properly[^] as I think this is what I would need to do to make sure my closing code always gets called, but it doesn't seem to happen when I stop debugging. The application that I am connecting to still thinks my program is connected. It seems like when I stop debugging (or if I have a program crash, that the Dispose methods don't get called. I also tried to add a Finalizer but that causes a System.Runtime.InteropServices.InvalidComObjectException stating that the COM object that has been separated from it's underlying RCW cannot be used.
private bool disposed;
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (_Session != null) // _Session is the COM object.
{
_Session.EndSession(); // These are the COM functions to close and end the
_Session.CloseConnection(); // session that must be called, but this is where I
_Session = null; // get the InvalidComObjectException.
}
disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);}
~SessionConnection() // This was added, which seems to be the root cause of the COM exception
{
Dispose(false);
}I'm not sure what is the best way to ensure that the EndSession and CloseConnection methods of my COM object get called even if my program crashes or I stop debugging.
I doesn't "seem" like you are sure if Dispose() is getting called so you should add a "log entry" in Dispose() to be sure. Your "session" instance looks private. You could try (pardon the pun), a higher level "try ... finally", where the finally always runs and checks your object for null, disposes it, etc. Then there are application level exception handlers and "exits" ... you need to log to understand which paths your particular app can end on.
-
I have an application that uses a COM object to make a connection to an application. I need to make sure that when my application ends that I call the EndSession and CloseConnection methods of this COM object. I was reading this article: Implementing IDisposable and the Dispose Pattern Properly[^] as I think this is what I would need to do to make sure my closing code always gets called, but it doesn't seem to happen when I stop debugging. The application that I am connecting to still thinks my program is connected. It seems like when I stop debugging (or if I have a program crash, that the Dispose methods don't get called. I also tried to add a Finalizer but that causes a System.Runtime.InteropServices.InvalidComObjectException stating that the COM object that has been separated from it's underlying RCW cannot be used.
private bool disposed;
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (_Session != null) // _Session is the COM object.
{
_Session.EndSession(); // These are the COM functions to close and end the
_Session.CloseConnection(); // session that must be called, but this is where I
_Session = null; // get the InvalidComObjectException.
}
disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);}
~SessionConnection() // This was added, which seems to be the root cause of the COM exception
{
Dispose(false);
}I'm not sure what is the best way to ensure that the EndSession and CloseConnection methods of my COM object get called even if my program crashes or I stop debugging.
When you launch the code from inside Visual Studio, it's launched, the debugger is attached and you debug on your merry way. If you hit Stop inside Visual Studio, your code is stopped, wherever it is, and removed from memory. Your Dispose code never gets executed. The only way to make sure it does is if you exit your application as a user would, gracefully.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
When you launch the code from inside Visual Studio, it's launched, the debugger is attached and you debug on your merry way. If you hit Stop inside Visual Studio, your code is stopped, wherever it is, and removed from memory. Your Dispose code never gets executed. The only way to make sure it does is if you exit your application as a user would, gracefully.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak:thumbsup: That's what I was going to say! The only thing I'd add is that the same thing will happen if you use Task Manager to kill the process. So if this is causing a problem with "Stop debugging" it'll also cause the same problem if the user terminates the app.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
When you launch the code from inside Visual Studio, it's launched, the debugger is attached and you debug on your merry way. If you hit Stop inside Visual Studio, your code is stopped, wherever it is, and removed from memory. Your Dispose code never gets executed. The only way to make sure it does is if you exit your application as a user would, gracefully.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave KreskowiakI never knew that about the debugger, thanks! But then does this mean that GC doesn't do any cleanup? Or is Visual Studio maintaining the information so it knows to release any allocated memory? Is this something to do with the VS Hosting Process? If I open a file within a using statement, it seems like stopping the debugger is still releasing the file handle (at least I think so, I'm still very new). Are there any recommendations / best practices when dealing with situations like this?
-
I never knew that about the debugger, thanks! But then does this mean that GC doesn't do any cleanup? Or is Visual Studio maintaining the information so it knows to release any allocated memory? Is this something to do with the VS Hosting Process? If I open a file within a using statement, it seems like stopping the debugger is still releasing the file handle (at least I think so, I'm still very new). Are there any recommendations / best practices when dealing with situations like this?
There is no cleanup of the orphaned COM stuff. It's just left hanging. When the code is stopped abruptly, the GC doesn't even run. Your process is stopped cold and the memory the app and its data was occupying freed and returned to Windows. The GC cannot clean up non-managed resources anyway. It can only cleanup managed stuff. The closest it can get is to free up the managed COM-wrapper that's is hanging onto the unmanaged COM references, but this doesn't free up those unmanaged resources. They are just orphaned. The debugger doesn't release anything at all. It's just attached to the process, not executing or controlling it in any meaningful way.
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak
