Develop Reference

Are Unity game objects managed or unmanaged resources?

I have a class which instantiates a few unity game objects in a scene hierarchy. This class implements IDisposable. Should I handle these game objects as they were managed or unmanaged resources?
I am following the Dispose pattern, so where should I put calls like GameObject.Destroy(myGameObject)?
Thank you
Edit:
Ok, lets say I want to destroy the game objects instantiated by this class when it goes out of scope. How would you proceed then?
Edit 2:
I was testing the dispose. And I have found a solution. It doesnt work automatically, because GameObject.Destroy(myGameObject) cant be called from different thread. It will throw an error CompareBaseObjectsInternal. So, when no longer needed I call myClass.Dispose(). Also it seems irrelevant whether I handle Unity GameObject as managed or unmanaged.
myMain()
{
DisposeTestClass test = new DisposeTestClass();
//...
test.Dispose();
}
class DisposeTestClass : System.IDisposable
{
public GameObject uselessGameobject { get; private set; }
public DisposeTestClass()
{
uselessGameobject = new GameObject("Useless gameobject");
}
#region IDisposable
private bool _disposed;
~DisposeTestClass()
{
Debug.Log("~DisposeTestClass()");
this.Dispose(false);
}
public void Dispose()
{
Debug.Log("Dispose()");
this.Dispose(true);
System.GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
Debug.Log("Dispose(bool)");
if(_disposed)
{
Debug.Log("Disposed. Return.");
return;
}
if(disposing)
{
Debug.Log("Disposing of managed resources...");
// clean up managed resources
/*
if(uselessGameobject != null)
{
GameObject.Destroy(uselessGameobject);
Debug.Log("Game object destroyed.");
}
else
{
Debug.Log("Game object is null.");
}*/
}
Debug.Log("Cleaning up unmanaged resources...");
// clean up unmanaged resources
if(uselessGameobject != null)
{
GameObject.Destroy(uselessGameobject);
Debug.Log("Game object destroyed.");
}
else
{
Debug.Log("Game object is null.");
}
// set the flag
Debug.Log("Setting the disposed flag.");
this._disposed = true;
}
#endregion
}
}

No, you shouldn't implement IDisposable. But you can :).
"so where should I put call GameObject.Destroy(myGameObject)" And when you want your objects to be destroyed? Actually that doesn't matter whether you call myContainer.Dispose() or GameObject.Destroy(gObj).
The only reason to implement IDisposable for you is to write "convient" code like:
using(var container = new MyContainer())
using(var somethingElse = new MyObject())
{
\\Logic for container and somethingElse
}
But in Unity this makes no sense. I can hardly imagine case when in an Update GameObjects are created and then destroyed.

Huh, I think you slightly misunderstood what IDisposable and using statement is used for. You shouldn't implement IDisposable everywhere just to get rid of an object - this is garbage collector role, it knows better when an object shoyld be disposed.
IDisposable and using statement are used as a try/finally statement(of course it is much more complicated under the hood) and ensure that an object is removed/resolved right after it is not used anymore. It is not always a managed/unmanaged resource issue.
Using using statement won't ensure that your game object will be disposed. It all depends on the fact whether there are another objects pointing to it. Since it looks like a root object, I believe it will be held as long as possible by GC. Note that even if GC call Dispose() on your object, as long as it is referenced, it will be stay on the special queue until it is released.
On the other hand if your GameObject is less the Game, more the Object, you shouldn't consider disposing it using IDisposable as long as it is not somehow connected with some connection/file/external resource. GC will claim memory as soon as your object is considered garbage. Just take into consideration, that IDisposable is something which CLR treats a bit different and is not always the way to go.
EDIT
According to your question from edit - basically when a objects goes out of scope, you do nothing - if GC considers it garbage, it will be removed with the closest GC collection that occur. That's why C# is considered managed language and why you do not release memory on your own.

Dispose and asynchrony [duplicate]

Let's say I have a class that implements the IDisposable interface. Something like this:
MyClass uses some unmanaged resources, hence the Dispose() method from IDisposable releases those resources. MyClass should be used like this:
using ( MyClass myClass = new MyClass() ) {
myClass.DoSomething();
}
Now, I want to implement a method that calls DoSomething() asynchronously. I add a new method to MyClass:
Now, from the client side, MyClass should be used like this:
using ( MyClass myClass = new MyClass() ) {
myClass.AsyncDoSomething();
}
However, if I don't do anything else, this could fail as the object myClass might be disposed before DoSomething() is called (and throw an unexpected ObjectDisposedException). So, the call to the Dispose() method (either implicit or explicit) should be delayed until the asynchronous call to DoSomething() is done.
I think the code in the Dispose() method should be executed in a asynchronous way, and only once all asynchronous calls are resolved. I'd like to know which could be the best way to accomplish this.
Thanks.
NOTE: For the sake of simplicity, I haven't entered in the details of how Dispose() method is implemented. In real life I usually follow the Dispose pattern.
UPDATE: Thank you so much for your responses. I appreciate your effort. As chakrit has commented, I need that multiple calls to the async DoSomething can be made. Ideally, something like this should work fine:
using ( MyClass myClass = new MyClass() ) {
myClass.AsyncDoSomething();
myClass.AsyncDoSomething();
}
I'll study the counting semaphore, it seems what I'm looking for. It could also be a design problem. If I find it convenient, I will share with you some bits of the real case and what MyClass really does.

It looks like you're using the event-based async pattern (see here for more info about .NET async patterns) so what you'd typically have is an event on the class that fires when the async operation is completed named DoSomethingCompleted (note that AsyncDoSomething should really be called DoSomethingAsync to follow the pattern correctly). With this event exposed you could write:
var myClass = new MyClass();
myClass.DoSomethingCompleted += (sender, e) => myClass.Dispose();
myClass.DoSomethingAsync();
The other alternative is to use the IAsyncResult pattern, where you can pass a delegate that calls the dispose method to the AsyncCallback parameter (more info on this pattern is in the page above too). In this case you'd have BeginDoSomething and EndDoSomething methods instead of DoSomethingAsync, and would call it something like...
var myClass = new MyClass();
myClass.BeginDoSomething(
asyncResult => {
using (myClass)
{
myClass.EndDoSomething(asyncResult);
}
},
null);
But whichever way you do it, you need a way for the caller to be notified that the async operation has completed so it can dispose of the object at the correct time.

Since C#8.0 you can use IAsyncDisposable.
using System.Threading.Tasks;
public class ExampleAsyncDisposable : IAsyncDisposable
{
public async ValueTask DisposeAsync()
{
// await DisposeAllTheThingsAsync();
}
}
Here is the reference to the official Microsoft documentation.

Async methods usually have a callback allowing you to do do some action upon completition. If this is your case it would be something like this:
// The async method taks an on-completed callback delegate
myClass.AsyncDoSomething(delegate { myClass.Dispose(); });
An other way around this is an async wrapper:
ThreadPool.QueueUserWorkItem(delegate
{
using(myClass)
{
// The class doesn't know about async operations, a helper method does that
myClass.DoSomething();
}
});

I consider it unfortunate that Microsoft didn't require as part of the IDisposable contract that implementations should allow Dispose to be called from any threading context, since there's no sane way the creation of an object can force the continued existence of the threading context in which it was created. It's possible to design code so that the thread which creates an object will somehow watch for the object becoming obsolete and can Dispose at its convenience, and so that when the thread is no longer needed for anything else it will stick around until all appropriate objects have been Disposed, but I don't think there's a standard mechanism that doesn't require special behavior on the part of the thread creating the Dispose.
Your best bet is probably to have all the objects of interest created within a common thread (perhaps the UI thread), try to guarantee that the thread will stay around for the lifetime of the objects of interest, and use something like Control.BeginInvoke to request the objects' disposal. Provided that neither object creation nor cleanup will block for any length of time, that may be a good approach, but if either operation could block a different approach may be needed [perhaps open up a hidden dummy form with its own thread, so one can use Control.BeginInvoke there].
Alternatively, if you have control over the IDisposable implementations, design them so that they can safely be fired asynchronously. In many cases, that will "just work" provided nobody is trying to use the item when it is disposed, but that's hardly a given. In particular, with many types of IDisposable, there's a real danger that multiple object instances might both manipulate a common outside resource [e.g. an object may hold a List<> of created instances, add instances to that list when they are constructed, and remove instances on Dispose; if the list operations are not synchronized, an asynchronous Dispose could corrupt the list even if the object being disposed is not otherwise in use.
BTW, a useful pattern is for objects to allow asynchronous dispose while they are in use, with the expectation that such disposal will cause any operations in progress to throw an exception at the first convenient opportunity. Things like sockets work this way. It may not be possible for a read operation to be exit early without leaving its socket in a useless state, but if the socket's never going to be used anyway, there's no point for the read to keep waiting for data if another thread has determined that it should give up. IMHO, that's how all IDisposable objects should endeavor to behave, but I know of no document calling for such a general pattern.

I wouldn't alter the code somehow to allow for async disposes. Instead I would make sure when the call to AsyncDoSomething is made, it will have a copy of all the data it needs to execute. That method should be responsible for cleaning up all if its resources.

You could add a callback mechanism and pass a cleanup function as a callback.
var x = new MyClass();
Action cleanup = () => x.Dispose();
x.DoSomethingAsync(/*and then*/cleanup);
but this would pose problem if you want to run multiple async calls off the same object instance.
One way would be to implement a simple counting semaphore with the Semaphore class to count the number of running async jobs.
Add the counter to MyClass and on every AsyncWhatever calls increment the counter, on exits decerement it. When the semaphore is 0, then the class is ready to be disposed.
var x = new MyClass();
x.DoSomethingAsync();
x.DoSomethingAsync2();
while (x.RunningJobsCount > 0)
Thread.CurrentThread.Sleep(500);
x.Dispose();
But I doubt that would be the ideal way. I smell a design problem. Maybe a re-thought of MyClass designs could avoid this?
Could you share some bit of MyClass implementation? What it's supposed to do?

Here's a more modern spin on this old question.
The real objective is to track the async Tasks and wait until they finish...
public class MyExample : IDisposable
{
private List<Task> tasks = new List<Task>();
public async Task DoSomething()
{
// Track your async Tasks
tasks.Add(DoSomethingElseAsync());
tasks.Add(DoSomethingElseAsync());
tasks.Add(DoSomethingElseAsync());
}
public async Task DoSomethingElseAsync()
{
// TODO: something else
}
public void Dispose()
{
// Block until Tasks finish
Task.WhenAll(tasks);
// NOTE: C# allows DisposeAsync()
// Use non-blocking "await Task.WhenAll(tasks)"
}
}
Consider turning it into a base class for re-usability.
And sometimes I use a similar pattern for static methods...
public static async Task MyMethod()
{
List<Task> tasks = new List<Task>();
// Track your async Tasks
tasks.Add(DoSomethingElseAsync());
tasks.Add(DoSomethingElseAsync());
tasks.Add(DoSomethingElseAsync());
// Wait for Tasks to complete
await Task.WhenAll(tasks);
}

So, my idea is to keep how many AsyncDoSomething() are pending to complete, and only dispose when this count reaches to zero. My initial approach is:
public class MyClass : IDisposable {
private delegate void AsyncDoSomethingCaller();
private delegate void AsyncDoDisposeCaller();
private int pendingTasks = 0;
public DoSomething() {
// Do whatever.
}
public AsyncDoSomething() {
pendingTasks++;
AsyncDoSomethingCaller caller = new AsyncDoSomethingCaller();
caller.BeginInvoke( new AsyncCallback( EndDoSomethingCallback ), caller);
}
public Dispose() {
AsyncDoDisposeCaller caller = new AsyncDoDisposeCaller();
caller.BeginInvoke( new AsyncCallback( EndDoDisposeCallback ), caller);
}
private DoDispose() {
WaitForPendingTasks();
// Finally, dispose whatever managed and unmanaged resources.
}
private void WaitForPendingTasks() {
while ( true ) {
// Check if there is a pending task.
if ( pendingTasks == 0 ) {
return;
}
// Allow other threads to execute.
Thread.Sleep( 0 );
}
}
private void EndDoSomethingCallback( IAsyncResult ar ) {
AsyncDoSomethingCaller caller = (AsyncDoSomethingCaller) ar.AsyncState;
caller.EndInvoke( ar );
pendingTasks--;
}
private void EndDoDisposeCallback( IAsyncResult ar ) {
AsyncDoDisposeCaller caller = (AsyncDoDisposeCaller) ar.AsyncState;
caller.EndInvoke( ar );
}
}
Some issues may occur if two or more threads try to read / write the pendingTasks variable concurrently, so the lock keyword should be used to prevent race conditions:
public class MyClass : IDisposable {
private delegate void AsyncDoSomethingCaller();
private delegate void AsyncDoDisposeCaller();
private int pendingTasks = 0;
private readonly object lockObj = new object();
public DoSomething() {
// Do whatever.
}
public AsyncDoSomething() {
lock ( lockObj ) {
pendingTasks++;
AsyncDoSomethingCaller caller = new AsyncDoSomethingCaller();
caller.BeginInvoke( new AsyncCallback( EndDoSomethingCallback ), caller);
}
}
public Dispose() {
AsyncDoDisposeCaller caller = new AsyncDoDisposeCaller();
caller.BeginInvoke( new AsyncCallback( EndDoDisposeCallback ), caller);
}
private DoDispose() {
WaitForPendingTasks();
// Finally, dispose whatever managed and unmanaged resources.
}
private void WaitForPendingTasks() {
while ( true ) {
// Check if there is a pending task.
lock ( lockObj ) {
if ( pendingTasks == 0 ) {
return;
}
}
// Allow other threads to execute.
Thread.Sleep( 0 );
}
}
private void EndDoSomethingCallback( IAsyncResult ar ) {
lock ( lockObj ) {
AsyncDoSomethingCaller caller = (AsyncDoSomethingCaller) ar.AsyncState;
caller.EndInvoke( ar );
pendingTasks--;
}
}
private void EndDoDisposeCallback( IAsyncResult ar ) {
AsyncDoDisposeCaller caller = (AsyncDoDisposeCaller) ar.AsyncState;
caller.EndInvoke( ar );
}
}
I see a problem with this approach. As the release of resources is asynchronously done, something like this might work:
MyClass myClass;
using ( myClass = new MyClass() ) {
myClass.AsyncDoSomething();
}
myClass.DoSomething();
When the expected behavior should be to launch an ObjectDisposedException when DoSomething() is called outside the using clause. But I don't find this bad enough to rethink this solution.

I've had to just go old-school. No, you can't use the simplified "using" block. But a Using block is simply syntactic sugar for cleaning up a semi-complex try/catch/finally block. Build your dispose as you would any other method, then call it in a finally block.
public async Task<string> DoSomeStuffAsync()
{
// used to be a simple:
// using(var client = new SomeClientObject())
// {
// string response = await client.OtherAsyncMethod();
// return response;
// }
//
// Since I can't use a USING block here, we have to go old-school
// to catch the async disposable.
var client = new SomeClientObject();
try
{
string response = await client.OtherAsyncMethod();
return response;
}
finally
{
await client.DisposeAsync();
}
}
It's ugly, but it is very effective, and much simpler than many of the other suggestions I've seen.

how to dispose C# base class when derived class constructor generates an error

If a C# derived IDisposable class constructor generates an error, how to dispose of the already fully constructed IDisposable base class?
Since all fields in the class hierarchy are initialized before any constructor executes, is it safe for the derived constructor to call base.Dispose()? It violates the rule of not calling virtual methods until object is fully constructed, but I can't think of another way to do it, and my searching hasn't turned up anything about this scenario.

My view is that constructors should be light, not relying on external resources/etc that might throw an exception. The constructor should do enough to verify Dispose() can be safely called. Consider using containment instead of inheritance, or having a factory method do the work that might throw.

All derived class constructors must call Dispose on the object being constructed if they exit via an exception. Further, it's very difficult to write leak-proof classes if field initializers construct IDisposable instances or can fail. Too bad, since requiring objects to be declared in one place, initialized in a second, and cleaned up in a third is not exactly a recipe for coherent code.
I would suggest that the best pattern is probably something like:
class foo : baseFoo , IDisposable
{
foo () : baseFoo
{
bool ok = false;
try
{
do_stuff();
ok = true; // Only after last thing that can cause failure
}
finally
{
if (!ok)
Dispose();
}
}
}
Note that C++/CLI automatically implements that pattern, and can also automatically handle cleanup of IDisposable fields. Too bad the language seems like a pain in other ways.
PS--With relatively few exceptions, mostly revolving around predictable-cost shared immutable objects (e.g. brushes, fonts, small bitmaps, etc.), code which relies upon Finalize to clean up objects is broken. If an IDisposable is created, it must be disposed unless the code which created it has particular knowledge about the consequences of deferring disposal to a finalizer.

For Managed resources, this should not be a problem, they will get Garbage Collected. For Unmanaged resources, make sure you have a Finalizer defined for your object, that will ensure the Unmanaged resources are cleaned up.
Also, throwing exceptions from a constructor is considered very bad manners, It's better to provide a Factory Method to do the construction and error handling or to equip your object with an Initialize method that will throw the actual exception. That way the construction always succeeds and you're not left with these type of issues.
Correct, Dispose isn't called by the Garbage Collector, but a Finalizer is, which in turn needs to call Dispose. It's a more expensive technique, except when used correctly. I didn't say so in my answer, did I ;).
You can call into the GC to force a collection run and you can wait for all pending finalizers. It's still better to not put the exception generating code in the construstor or by placing a try/catch around the code in the constructor to ensure Dispose is called on these files in case of an error. You can always rethrow the exception later.

This solution builds on the proposal by #supercat. Initialization of any member that might throw must be performed in the constructor's try/catch block. With that condition met an exception thrown from any constructor will correctly dispose a fully or partially constructed base or derived class.
In this test code uncomment each of the four exceptions in turn and the program will output which of the Disposable resources were not disposed properly due to the constructor throwing an exception. Then uncomment the two Dispose calls and observe that everything gets cleaned up as it should.
class DisposableResource : IDisposable
{
public DisposableResource(string id) { Id = id; }
~DisposableResource() { Console.WriteLine(Id + " wasn't disposed.\n"); }
public string Id { get; private set; }
public void Dispose() { GC.SuppressFinalize(this); }
}
class Base : IDisposable
{
public Base()
{
try
{
throw new Exception(); // Exception 1.
_baseCtorInit = new DisposableResource("_baseCtorInit");
// throw new Exception(); // Exception 2.
}
catch(Exception)
{
// Dispose(); // Uncomment to perform cleanup.
throw;
}
}
public virtual void Dispose()
{
if (_baseFieldInit != null)
{
_baseFieldInit.Dispose();
_baseFieldInit = null;
}
if (_baseCtorInit != null)
{
_baseCtorInit.Dispose();
_baseCtorInit = null;
}
}
private DisposableResource _baseFieldInit = new DisposableResource("_baseFieldInit");
private DisposableResource _baseCtorInit;
}
class Derived : Base
{
public Derived()
{
try
{
// throw new Exception(); // Exception 3.
_derivedCtorInit = new DisposableResource("_derivedCtorInit");
// throw new Exception();
}
catch (Exception)
{
// Dispose(); // Uncomment to perform cleanup.
throw;
}
}
public override void Dispose()
{
if (_derivedFieldInit != null)
{
_derivedFieldInit.Dispose();
_derivedFieldInit = null;
}
if (_derivedCtorInit != null)
{
_derivedCtorInit.Dispose();
_derivedCtorInit = null;
}
base.Dispose();
}
private DisposableResource _derivedFieldInit = new DisposableResource("_derivedFieldInit");
private DisposableResource _derivedCtorInit;
}
class Program
{
static void Main(string[] args)
{
try
{
Derived d = new Derived();
}
catch (Exception)
{
Console.WriteLine("Caught Exception.\n");
}
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.WriteLine("\n\nPress any key to continue...\n");
Console.ReadKey(false);
}
}

fxcop CA2213 error in vs2010

I have the following code:
A disposable class that contains two disposable members.
One of them is being initialized using new() method, and the other using static factory method.
I Also have static code analisys rules, with CA2213 as error.
public class DisposableClass : IDisposable
{
private WebClient m_DisposableMember1;
public WebClient DisposableMember1
{
get
{
if (m_DisposableMember1 == null)
{
m_DisposableMember1 = new WebClient();
}
return m_DisposableMember1;
}
}
private WebClient m_DisposableMember2;
public WebClient DisposableMember2
{
get
{
if (m_DisposableMember2 == null)
{
m_DisposableMember2 = Factory.Create();
}
return m_DisposableMember2;
}
}
#region Finalize/Dispose Pattern
private bool m_IsDisposed = false;
//Implement IDisposable.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~DisposableClass()
{
Dispose(false);
}
protected virtual void Dispose(bool disposing)
{
if (!m_IsDisposed)
{
if (disposing)
{
DisposableMember1.Dispose();
// DisposableMember2 in not disposed and not notified by fxCop
}
m_IsDisposed = true;
}
}
#endregion Finalize/Dispose Pattern
}
This is the simple factory class:
public static class Factory
{
public static WebClient Create()
{
return new WebClient();
}
}
When I call the Dispose() method of the DisposableMember1 property, I get CA2213.
When I call the Dispose() method of the m_DisposableMember1 member, I don't get this error.
More over, I don't get this error for m_DisposableMember2 (Wich was initialized using the static factory), and it is not being disposed.
Does anybody familiar with this issue? What can cause this behavior?

CA2213 is not particularly aggressive about identifying fields that ought to be disposed. Amongst other potential problems, it only considers fields that are directly assigned from a constructor invocation. Assignment of a field value via a property or from a source other than a constructor invocation do not result in the target field being included in the pool of "should be disposed" fields by the rule.

You are expecting a bit too much out of the smarts of this tool. That the property is an alias for the field is only obvious to human eyes. It requires pretty sophisticated analysis to let a tool see that. FxCop just doesn't have that kind of horse power. Your code is in fact questionable. If the property was never used by the client code then you'll create the WebClient object and immediately dispose it. Use the field instead, test for null and Dispose().
The problem with the second field is probably induced by the need for the tool to avoid unnecessary warnings. It will only complain if it can determine with absolute certainty that the field is ever initialized. Same kind of lack of smarts here, it can't tell that the factory always returns a non-null reference. Only when it sees the constructor being used in the class itself can it be sure that the field needs to be disposed.
It's a good tool, not perfect.

C# - Design-related dispose question (take two)

I asked a question earlier today, but I think I need to approach it in a different way (on top of that there was a "hang up" in regards to DataSet).
Here's a class that encapsulates the creation of a Font (in other words, it is reading data from an xml file and is creating a font, at runtime, based on what it reads from that file):
public class FontCreator
{
private Font m_TheFont = null;
public FontCreator( ... some parameters ... )
{
m_TheFont = GetTheFont();
}
public Font TheFont
{
return m_TheFont;
}
private Font GetTheFont()
{
// code, and more code, that eventually leads to:
Font f = new Font(fntFamily, fntSize, fntStyle);
return f;
}
}
The consumer of the FontCreator class looks something like:
public class TheConsumer()
{
private FontCreator m_FontCreator = null;
public TheConsumer()
{
m_FontCreator = new m_FontCreator( ... some parameters ... );
Initialize();
}
private void Initialize()
{
InitializeThis();
InitializeThat();
}
private void InitializeThis()
{
.... some code ...
SomeObject.ApplyFont(m_FontCreator.TheFont);
}
private void InitializeThat()
{
... some code ...
SomeObject.ApplyFont(m_FontCreator.TheFont);
}
}
What code do you add, and where, to ensure that "TheFont"'s Dispose method is explicitly called?

If you don't wish to maintain a reference to TheFont after it is initially used, then call it's Dispose method in your constructor, right after Initialize. If you wish to keep TheConsumer alive for a while and maintain a reference to TheFont, it gets more interesting. Two Options:
You can have TheFont's dispose method called from the Destructor of the TheConsumer object. This is not the common practice and has problems. Mainly, this is not called until garbage collection happens. Better is:
You can make the TheConsumer object itself implement IDisposable, and call TheFont.Dispose from TheConsumer.Dispose. Since TheConsumer implements IDisposable, the code that uses it should call its Dispose method.
Edit in response to harsh comment!
Yes, I should have made clear to only use 1 in addition to 2, if at all. I know all developers everywhere are supposed to notice when IDisposable is implemented, but they often don't. If the referenced managed resource might really remain around a long time and cause problems if not properly disposed, I sometimes have a safety Dispose() method call in the destructor of the object holding the reference. Is that so wrong? :)

public TheConsumer()
{
using (m_FontCreator = new m_FontCreator( ... some parameters ... ))
{
Initialize();
}
}

I am confused, if you want to quickly use the font creater object then implement IDisposable on the FontCreater and use
using(m_FontCreator = new FontCreater(....))
{
InitializeThis();
InitializeThat();
}
If you need to keep the instance of the FontCreater through the lifetime of TheConsumer, then implement IDisposable on both FontCreater and TheConsumer classes.
public class TheConsumer : IDisposable
{
void Dispose()
{
if(m_FontCreator != null)
m_FontCreator.Dispose();
}
}
then use TheConsumer class like so
using(TheConsumer consumer = new TheConsumer(....))
{
....
}

Answer 1: Avoid it. Don't keep objectsthat contain unmanaged resources around any longer than necessary.
Answer 2: If you do need the embedded fields as shown in your code, than both the FontCreator and the Consumer class need to implement IDisposable. But not a destructor (Finalizer).
The main argument for this is that FontCreator is the 'owner' of the Font and should therefore take responsibility. And the Consumer is responsible for the Creator in the same way.
As others have noted, it appears you can at least avoid the m_FontCreator field in the Consumer class. But it depends on the rest of the code, is m_FontCreator used elsewhere?