We Keep Coding

In C# does (new Obj()).foo() dispose of Obj when the parenthesis scope is exited?

I am happy using IDisposable and using blocks but often I find myself writing (new Obj()).Foo(); to avoid the extra instantiation code and naming etc. Does this instance hang in memory until the end of the function scope or is it disposed of directly after the enclosing parenthesis is exited...? Is there an alternative I am missing? An equivalent to implementing IDisposable for concrete objects that I want to use once and throw away?

IDisposable is not related whit when the memory allocated for the object is released. In both cases the memory is released when the Garbage Collector decides to release it.
IDisposable is used for objects that need to execute some action in order to release the resources it allocates outside them. For example if the objects open a Database connection, you must release it as soon as you don't need it anymore.
So IDisposable gives you one thing:
A way to release the resources as soon as you want, by calling the Dispose() method or using the using clause
So it's ok to do:
new Obj()).Foo();
And has no sense to make Obj implements IDisposable if it does not uses any resource that must be deallocated.

If an object implements IDisposable, it is imperative that you Dispose() the object in your own code, either explicitly (and within a try/finally construct, too!) or with the using syntax, and do not simply let the reference(s) fall out of scope.
EDIT: I feel like I used an awful lot of words to get around to explaining the most important aspect of all this, which is that the only reason an object should implement IDisposable is if it holds handles to other objects that are unmanaged (the CLR doesn't know about them) or scarce (due to resources/cost/licensing/etc.). So if an object implements IDisposable, you MUST call Dispose() YOURSELF, as soon as possible. The CLR will not do it for you. And if you implement IDisposable on your own classes, you need to be implementing a finalizer on them, too.
Simply letting a reference fall out of scope does not cause the GC to run immediately, and you have no guarantees whatsoever that a GC is going to occur any time soon. You can explicitly trigger a GC with code, but that is typically going to hurt overall performance more than help it.
If there is not much memory pressure, for instance, the CLR may wait a long time before running the GC. There just isn't a pressing need for it to run in a situation where there is light or zero contention for resources. If it ran too often, it would impact the performance of your applications negatively
The GC does not call Dispose(). The GC calls an object's finalizer if it has one. The finalizer is a special method using syntax similar to a C++ destructor, but which really is not a destructor in that sense.
So if an object implements IDisposable, but does not implement a finalizer, the GC will never release that object's resources. The object will cause both memory leaks and unresolvable resource contention.
Nor does calling Dispose() from your own code trigger a GC.
The finalizer is a last-ditch backup mechanism to try to ensure that a class holding scarce or expensive resources does eventually let go of them even if consumers of the class fail to explicitly release those resources.
IDisposable is really just a common convention, implemented with a handy well-known interface contract, to let callers generically request that any class holding scarce resources release those resources immediately.
The standard pattern is that the finalizer calls the Dispose() method (actually, it typically calls Dispose(false) and I'm intentionally ignoring that detail). The Dispose() method will release all the scarce resources, then it can call GC.SuppressFinalize() so that the GC can free the object's memory more quickly when it gets around to running.
The old tried and true "acquire late/release early" semantics apply here.
You should read up on how the GC uses multiple passes or "generations" to clean up objects with finalizers.
The GC can get rid of regular objects (objects where all the resources are managed by the CLR) in one pass. If there are no in-scope references to an object, the GC can basically just delete it.
But if an object has a finalizer (and GC.SuppressFinalize() has not been called), the GC uses at least 2 passes or generations to release the object. In the first generation, it marks the object for finalization. In the second generation (which happens the next time the GC runs), it actually calls the finalizer, and at that point the object is finally eligible to have its memory released.
The scarce/expensive resources we're talking about are typically things like network sockets, file handles, database or other server connections which may be limited or expensive or resource-intensive or all three, etc. This is also true of virtually all "unmanaged" (non .NET CLR) resources, including things like Win32 window handles, file handles, network sockets and so on. Such resources require deterministic cleanup. You need to let go of them as quick as you can, but the CLR is going to take its sweet time getting around to cleaning this stuff up. You have to do it yourself.
But if your class isn't using any of these types of scarce/expensive/"unmanaged" resources, then there is probably no reason to implement IDisposable on it at all.

Disposing MemoryCache in Finalizer throws AccessViolationException

EDIT
See edit note at the bottom of the question for additional detail.
Original question
I have a CacheWrapper class which creates and holds onto an instance of the .NET MemoryCache class internally.
MemoryCache hooks itself into AppDomain events, so it will never be garbage-collected unless it is explicitly disposed. You can verify this with the following code:
Func<bool, WeakReference> create = disposed => {
var cache = new MemoryCache("my cache");
if (disposed) { cache.Dispose(); }
return new WeakReference(cache);
};
// with false, we loop forever. With true, we exit
var weakCache = create(false);
while (weakCache.IsAlive)
{
"Still waiting...".Dump();
Thread.Sleep(1000);
GC.Collect();
GC.WaitForPendingFinalizers();
}
"Cleaned up!".Dump();
Because of the behavior, I believe that my MemoryCache instance should be treated as an unmanaged resource. In other words, I should ensure that it is disposed in the finalizer of CacheWrapper (CacheWrapper is itself Disposable follows the standard Dispose(bool) pattern).
However, I am finding that this causes issues when my code runs as part of an ASP.NET app. When the application domain is unloaded, the finalizer runs on my CacheWrapper class. This in turn attempts to dispose the MemoryCache instance. This is where I run into issues. It seems that Dispose attempts to load some configuration information from IIS, which fails (presumably because I'm in the midst of unloading the app domain, but I'm not sure. Here's the stack dump I have:
MANAGED_STACK:
SP IP Function
000000298835E6D0 0000000000000001 System_Web!System.Web.Hosting.UnsafeIISMethods.MgdGetSiteNameFromId(IntPtr, UInt32, IntPtr ByRef, Int32 ByRef)+0x2
000000298835E7B0 000007F7C56C7F2F System_Web!System.Web.Configuration.ProcessHostConfigUtils.GetSiteNameFromId(UInt32)+0x7f
000000298835E810 000007F7C56DCB68 System_Web!System.Web.Configuration.ProcessHostMapPath.MapPathCaching(System.String, System.Web.VirtualPath)+0x2a8
000000298835E8C0 000007F7C5B9FD52 System_Web!System.Web.Hosting.HostingEnvironment.MapPathActual(System.Web.VirtualPath, Boolean)+0x142
000000298835E940 000007F7C5B9FABB System_Web!System.Web.CachedPathData.GetPhysicalPath(System.Web.VirtualPath)+0x2b
000000298835E9A0 000007F7C5B99E9E System_Web!System.Web.CachedPathData.GetConfigPathData(System.String)+0x2ce
000000298835EB00 000007F7C5B99E19 System_Web!System.Web.CachedPathData.GetConfigPathData(System.String)+0x249
000000298835EC60 000007F7C5BB008D System_Web!System.Web.Configuration.HttpConfigurationSystem.GetApplicationSection(System.String)+0x1d
000000298835EC90 000007F7C5BAFDD6 System_Configuration!System.Configuration.ConfigurationManager.GetSection(System.String)+0x56
000000298835ECC0 000007F7C63A11AE System_Runtime_Caching!Unknown+0x3e
000000298835ED20 000007F7C63A1115 System_Runtime_Caching!Unknown+0x75
000000298835ED60 000007F7C639C3C5 System_Runtime_Caching!Unknown+0xe5
000000298835EDD0 000007F7C7628D86 System_Runtime_Caching!Unknown+0x86
// my code here
Is there any known solution to this? Am I correct in thinking that I do need to dispose the MemoryCache in the finalizer?
EDIT
This article validates Dan Bryant's answer and discusses many of the interesting details. In particular, he covers the case of StreamWriter, which faces a similar scenario to mine because it wants to flush it's buffers upon disposal. Here's what the article says:
Generally speaking, finalizers may not access managed objects.
However, support for shutdown logic is necessary for
reasonably-complex software. The Windows.Forms namespace handles this
with Application.Exit, which initiates an orderly shutdown. When
designing library components, it is helpful to have a way of
supporting shutdown logic integrated with the existing
logically-similar IDisposable (this avoids having to define an
IShutdownable interface without any built-in language support). This
is usually done by supporting orderly shutdown when
IDisposable.Dispose is invoked, and an abortive shutdown when it is
not. It would be even better if the finalizer could be used to do an
orderly shutdown whenever possible.
Microsoft came up against this problem, too. The StreamWriter class
owns a Stream object; StreamWriter.Close will flush its buffers and
then call Stream.Close. However, if a StreamWriter was not closed, its
finalizer cannot flush its buffers. Microsoft "solved" this problem by
not giving StreamWriter a finalizer, hoping that programmers will
notice the missing data and deduce their error. This is a perfect
example of the need for shutdown logic.
All that said, I think that it should be possible to implement "managed finalization" using WeakReference. Basically, have your class register a WeakReference to itself and a finalize action with some queue when the object is created. The queue is then monitored by a background thread or timer which calls the appropriate action when it's paired WeakReference gets collected. Of course, you'd have to be careful that your finalize action doesn't inadvertantly hold onto the class itself, thus preventing collection altogether!

You can't Dispose managed objects in the finalizer, as they might have already been finalized (or, as you've seen here, portions of the environment may no longer be in the state you're expecting.) This means that if you contain a class which must be Disposed explicitly, your class must also be Disposed explicitly. There's no way to 'cheat' and make the Disposal automatic. Unfortunately, garbage collection is, in cases like this, a leaky abstraction.

I would suggest that objects with finalizers should generally not be exposed to the outside world, and should only hold strong references to things which are actually needed for finalization and are not exposed to anything in the outside world that is not expecting them to be used for that purpose. Public-facing types should not have finalizers themselves, but should instead encapsulate cleanup logic within privately-held instances of finalizable classes whose purpose is to encapsulate such logic.
The only time it really makes sense for a finalizer to attempt to clean up a resource which is owned by another object is when the other object is designed to interface with the finalizer. I can't think of any places where Framework classes have engineered in the proper hooks, but will offer an example how Microsoft could have engineered them to do so.
A File object could offer an event with thread-safe subscribe and unsubscribe methods which would fire (notifying the last subscriber first) when the File object receives either a Dispose call or a finalize request. The event would fire between the time Finalize is called and the time the encapsulated file is actually closed, and could be used by a an external buffering class as a signal that it needs to give the File any information which it has received but not yet passed along.
Note that to make such a thing work properly and safely, it would be necessary that the part of the File object which has the finalizer not be exposed to the public, and that it use a long weak reference to ensure that if it runs while the public-facing object is still alive, it will reregister itself for finalization. Note that if the only reference to a WeakReference object is stored in a finalizable object, its Target property may be invalidated if the finalizable object becomes eligible for finalization even if the actual target of the reference is still alive. Defective design, IMHO, and one which must be worked around somewhat carefully.
It's possible to design objects with finalizers that can cooperate (the easiest way to do it, generally, is to only have one object in the group sport a finalizer), but if things aren't designed to cooperate with finalizers, the best that one can do is generally have a finalizer sound an alarm indicating "This object wasn't supposed to be Disposed but wasn't; because it wasn't, resources are going to leak, and there's nothing to be done about it except fix the code to dispose the object properly in future".

Is it possible the GC called in the destructor of a class implemented IDisposable?

-----------Edit1----------
Sorry for my poor english, seems the original question can't make sense for many people, so I greatly simplified the question just to two sentence:
In msdn code sample of IDisposable pattern in MSDN, Putting releasing un-managed resource code in destructor was for the purpose of when user forgot to call the Dispose() to release the resource, the GC still can help to release at least un-managed resource, but, when a class used some un-managed resources, it must registered (implicitly or explicitly) current instance (or fields) to GC handle table and then would never be GCed, so how the code in destructor get executed in this situation?
-----------End Edit1-------
We know the famous IDisposable pattern which could see lots in web like: IDisposable pattern in MSDN
In samples, as I understood, the purpose of destructor works for the case: If user forgot explicitly call Dispose(), then GC will help and release un-managed resources.
But I just wondering that destructor in any case could get called by GC without user code explicitly call Dispose() first?
The guess was based on reason of Implementing IDisposable and had an explicit destructor:
This class used some un-managed resources. No matter by P/Invoke or managed API (BCL), As I know, both way need add a GC handle entry to GC handle table which avoid GCed, thus the destructor would never be called by GC.
So we should never expect luck on resources automatically release? and why put that in sample code?

There are a lot of questions here. Let's try to answer all of them.
In the MSDN code sample of the IDisposable pattern code to release unmanaged resources is put in the destructor. This ensure that when a user forgots to call Dispose() to release the resource, the GC still releases the unmanaged resources.
Correct.
But when a class uses some unmanaged resources, it must have registered the current instance to GC handle table and then would never be GCed.
I don't understand this sentence. What is the "GC handle table" that you speak of?
Can you show some sample code that demonstrates your scenario?
How does the code in destructor get executed in this situation?
Briefly the GC works like this. The GC knows the "roots"; these are the references that are definitely alive. The GC first marks all the objects as dead. Then it marks the roots as alive. Then it marks everything the roots refer to as alive, and then every that they refer to as alive, and so on. That is everything reachable from a root is alive. Then the GC kills everything that is still marked as dead.
Now, if a dead object is finalizable -- if it has a destructor that has not run yet -- then the GC does NOT kill the object. The object is put on a list of objects to be finalized, and this list is a root, so the object is alive again. Later on, another thread runs the destructors of every object on the finalization queue and removes them from the queue, and marks them as no longer requiring finalization.
The next time the GC runs, if the object is still dead then it is collected and the finalizer is not run again.
Can the destructor get called by the GC without user code explicitly call Dispose() first?
Yes. That's the whole point of the destructor.

GC uses a mechanism called finalization to handle such classes that implement IDisposable.
If you properly implement the class, then when Dispose was not called, GC will take care of the object when it is out of scope, and the finalizer will be called by GC. The finalizer is called implicitly, and at a unpredictable time.
More technical details can be found from books such as CLR via C#, or articles such as http://msdn.microsoft.com/en-us/magazine/cc163392.aspx

Are destructor methods used implicitly by the garbage collector, and dispose methods used by developers to explicitly dispose of objects?

I can see there's already a lot of threads regarding dispose vs. destructor methods but I just want to make sure that I'm understanding them correctly before I move on.
Are destructor methods used implicitly by the garbage collector for when objects are no longer referenced (i.e. no longer needed) and dispose methods used by us developers to explicitly dispose of objects that may not be handled by the garbage collector?
Also - I'm reading into all this now and it seems that it's a case of one or the other with these methods. So for example given the following code:
class DansClass : IDisposable
{
public void Dispose()
{
GC.SuppressFinalize(this);
Console.WriteLine("Disposing...");
}
-DansClass()
{
Console.WriteLine("Destructing...");
}
}
The output will be:
Destructing...
Understandable, as we've suppressed the finalize (destructor) so we only see the Dispose output.
But if I comment out the SuppressFinalize() method the output is:
Disposing...
Why isn't the destructor called as well?

Well the behavior you're seeing is because Finalizers (what you're refering to as a Destructor is also known as a Finalizer in .Net) are queued up to run in the background by the Garbage Collector.
Eventually it will be called (although in some instances it may not). You can force their execution, however, to understand what is going on:
// Assuming you remove the GC.SuppressFinalize call
myDisposable.Dispose();
GC.WaitForPendingFinalizers();
// Output:
// Disposing...
// Destructing...
You only need to implement the pattern when you have external resources, or encapsulate members which contain external resources. Finalizers should only be implemented when you have external, unmanaged resources.
Proper implementation of the IDisposable pattern requires:
Dispose cleans up both unmanaged and managed resources
Finalizer cleans up hanging, unmanaged resources (if none exist, it is not needed)
Neither may throw an exception, Dispose must be callable more than once
The Finalizer should call the Dispose implementation
Domain specific termination methods, like Close, should be functionally equivalent to Dispose if both exist

Dispose methods, finalizers, and C#'s ironically-named destructors, exist because many objects ask other entities to do things on their behalf until further notice (typically granting exclusive use of something like a file, a region of memory, communications stream, hardware device, GDI handle, etc.); if an object issuing such a request were to disappear without those other entities know their services are no longer required, anything that had been set aside on behalf of the abandoned object would remain uselessly inaccessible.
The IDisposable.Dispose method provides a nice consistent way of telling an object that it will no longer be asked to do anything would require the assistance of other entities, and that any other entities which were doing anything on its behalf should be told to stop doing so. If IDisposable.Dispose is called properly, objects can minimize the extent to which outside entities have to act on their behalf.
Unfortunately, for various reasons (most being easily avoidable; some not), objects are sometimes abandoned without IDisposable.Dispose having been called. This will result in outside entities having to uselessly keep acting, at least for awhile, on behalf of the objects which are abandoned. To avoid having outside entities act forever on behalf of outside entities, the system can notify objects that they have been abandoned, thus giving them a chance to inform outside entities of this fact. Whenever an object whose class overrides Object.Finalize is created, it will be placed in a special list of objects that want to be notified if they are abandoned. Existence on this list, by itself, is not enough to make an object be considered "live", but before the garbage collector removes dead objects from memory it will check whether they are on the notify-before-destruction list. All dead objects which are on the list will be moved from the list of objects requesting notification if/when they are abandoned to a list of objects needing to be notified that they have been abandoned. Placement on this second list will cause the dead objects, and any objects to which they hold references, to be considered "alive" again, at least until the notification has been performed. When they are moved to the second list, however, they are removed from the first list so that if they are later found to be dead again, they will be swept from memory without further notice.
After the garbage collection completes, if any objects are in the list of objects needing to be notified of abandonment, the system will call the Object.Finalize method of each such object. Typically, once Object.Finalize has been called on such an object, there won't be any more rooted references to it and it will vanish on the next garbage collection. It is possible, however, for objects to be resurrected.
In vb.net and, so far as I know, most .net languages, one overrides Object.Finalize by simply declaring an override in the usual fashion. For whatever reason, the creators of C# decided to forbid that. Instead, in C#, one must use a language structure, ironically called a "Destructor", to override Finalize so that objects which are found to be abandoned will not be destroyed without notice, but instead be given a chance to clean up.
There are many tricky wrinkles in the actual operation of Object.Finalize, and it is best to avoid relying upon it except when absolutely necessary. The ironically-named "destructors" don't actually destroy objects, but rather delay their destruction. Calling GC.SuppressFinalize() on an object will remove it from the list of objects requesting notification when they are abandoned; provided that Dispose is called on an object, and it in turn calls GC.SuppressFinalize() as its last operation, there isn't any particular harm in having an object override Finalize or declare a "destructor", but in general it's best to only override Finalize (or declare "destructors") in relatively simple classes.

IDisposable with destructor: requires thread-safe implementation?

This is pretty much only for me to make sure, I got this right:
We have a large resource class implementing the IDisposal pattern. It should (by design) be implemented in a way, that enables it to get called more than one time (even if we try to call it exactly one time of course). We also implement a finalizer, which also calls the Dispose() method - just as backup. If called manually, Dispose() will also call GC.SuppressFinalize(this).
There are several examples of disposal patterns around. Most of them call GC.SuppressFinalize(this) at the end of the disposing code. Some claim, it would be better, to call it at the beginning of the Dispose() method, before any cleaning. Latter argue, this would make sure, the GC doesn't call the finalizer concurrently, while we are still cleaning up.
Question:
It seems, placing GC.SuppressFinalize at the beginning doesn't do any better? We still have a race condition, right? So is it true, that we rather should implement Dispose() in a thread safe way instead?

The GC only cleans up objects that are not 'reachable'.
A class in which code is executing is still 'reachable' because it's this pointer is on the stack. So while dispose is executing, the finalizer won't be called.
So it does not matter if you call SuppressFinalize at the begin or end.
As commentors below indicated, the CLR implementation does not appear to guarantee that your object does not get garbage collected/finalized while instance methods are executing. The only possible 'dependable' reference keeping the object alive is the one used to invoke the method on the object, but I don't know enough about the JIT internals to make statements about that, and it's behaviour might change.
I'm leaving the answer here for access to the discussion below.

While it is sometimes possible for an object to be finalized while a seemingly-live reference exists, that can only happen when nothing else is going to ever refer to the object. The GC.SuppressFinalize(this) actively refers to the present object 'this', thus guaranteeing that it will not be finalized until the GC.SuppressFinalize executes. Further, the fact that the object reference existed to dispose the object, and was available to the Dispose method, guarantees that the finalizer couldn't have been queued before Dispose started running unless the object was dead and a finalizer somewhere (either its own finalizer, or that of some other object) resurrected it.
Because there are some scenarios where an object could be scheduled for finalization and resurrected without ever being aware of it, it may not be a bad idea to protect a dispose and finalize against redundant operation. Microsoft's pattern is not a good one, however. Finalizable objects shouldn't hold references to any objects not needed for finalization. If an object would hold a mixture of managed and unmanaged resources, the unmanaged resources should be moved into their own classes (effectively turning them into managed resources), so then the main object would hold nothing but managed resources.

Dispose should not throw any exceptions.
I would make sure all the code in Dispose is thread safe so that if it gets called it will not do anything strange. Usually adding checks if variables are null already should do the trick.
In the microsoft examples i've only seen GC.SuppressFinalize at the end of the Dispose function.