Agile Development & "When will it be done?"

I've been doing XP/Agile development & management for 5 years now, and I've come to the conclusion that as soon as you have to answer "when will it be done?" you are back on the path to Waterfall.

What is the meaning of GC.KeepAlive()?

What is the purpose of GC.KeepAlive(object obj)? From the method name, it sounds like it will keep obj from being garbage collected after the call. In fact, the opposite is true, it will keep obj from being garbage collected before the call. On the face, that sounds like a pretty absurd method, doesn't it.

The problem is that the method is named incorrectly. Better, but more verbose, names would be GC.MakeExplicitlyElligibleForGarbageCollection() or GC.DontCollectObjectBeforeNow().

So, what's really going on here? As you are presumably well aware, memory is reclaimed in the .NET framework through garbage collection, which can happen at any time, for any object that has no outstanding references (but don't confuse with reference counting). For example:

public void SomeMethod()
{
 SomeClass o = new SomeClass();
 GC.Collect(); // no references to 0, it may be collected
 return;
}

Not very exciting, and makes sense, right? o isn't being used after the point of instantiation, so the collector is free to clean it up and reclaim the memory*.

But suppose that for some reason or another you need o to remain 'alive' until after SomeMethod() exits. In order to guarantee that, you would need to add some reference to 0 at the end of the method so that it can't be collected. That is the purpose of GC.KeepAlive().

So, all that GC.KeepAlive() does is create an artificial reference to 0 so that it can't be collected prior to the GC.KeepAlive() call:

public void SomeMethod_V2()
{
 SomeClass o = new SomeClass();
 GC.Collect(); // reference to 0 below, it will NOT be collected
 GC.KeepAlive(o);
 GC.Collect(); // no more references to 0, it may now be collected
 return;
}

So, hopefully the above makes it clearer what GC.KeepAlive() does, although we do need to figure out a better name...

*Note: In order to facilitate debuggers, when an application is compiled in Debug mode, the JIT will NOT collect locally-allocated instances until after the method exits. So, in this example, if compiled under Debug, o will never be collected until after SomeMethod() returns. In Release mode, locally-allocated instances can be collected after the point of last reference, even before the method has returned.

Resolving Error LNK2001: unresolved external symbol __imp__time

I don't know if this is a generic situation or not, but it has been frustrating to resolve. The scenario is that I'm building some C/C++ FLEXnet components and was having no fun on getting the Release build to compile and link. After much fiddling, I was able to resolve everything down to one link error:

Error LNK2001: unresolved external symbol __imp__time

After comparing the differences between Debug and Release settings, I ended up stumbling upon the "Whole Program Optimization" setting (Project, Properties, Configuration Properties, General).

In my case, the default for the Release build was set to: Use Link Time Code Generation -- seems reasonable. What isn't reasonable is how it leads to the above linker error. I still have no idea why it causes it, but changing it to No Whole Program Optimization solved the issue.

Note: using Visual Studio 2008, SP1

Get Method or Property Name as String in .Net

There are a few occasions where it is helpful to have the string name of the executing method or property.

The cleanest way that I've been able to devise is to use the query the current stack frame using System.Diagnostics.StackFrame.

string methodName = new StackFrame().GetMethod().Name;

When called from within a property, the name includes the getter/setter prefix: get_ or set_. Therefore, if you want the actual property name, use the following:

string propertyName = new StackFrame().GetMethod().Name.Split('_')[1];

Directory.Delete and Read-only Files

The System.IO.Directory.Delete() method will fail (exception) when it encounters a read-only file, regardless of the recursive flag. Unfortunately, the designers of this method did not have the foresight to provide a means around this limitation.

First off, the exception (UnauthorizedAccessException) only contains the file name; no path information is given. So, if you are in the middle of a recursive delete, the file name is largely irrelevant and there isn't much (programatically) that can be done to manage the situation. The appropriate implementation would have been to include the full path & file name information in the exception, and let the implementor decide on how to represent the file to the UI, as needed.

Second, there is no provision to handle read-only or similar situations w/ the method. At a minimum, there should be the capability to specify whether or not a read-only file should be deleted or not.

Because of this, the recursive implementation of Directory.Delete() is largely useless as it doesn't do what it has been designed to do: delete a directory (and containing files). The consequence of this is that we must write our own method to perform what is actually wanted -- hardly efficient. Anyway, to that end, here is a small function that implements more complete and usable delete functionality:

  public void DirectoryDelete(string path, bool recursive)
  {
    if (recursive)
      foreach (string directory in Directory.GetDirectories(path))
        DirectoryDelete(directory, true);
    foreach (string file in Directory.GetFiles(path))
      File.SetAttributes(file, FileAttributes.Normal);
    Directory.Delete(path, true);
  }