Garbage collection of static members

Members are not collected... Objects are.
So if you set the Ref. Type static member to null, any object it was previously pointing to would be collected. If not, it will hang around till the AppDomain goes down (Each AppDomain has its own set of static stuff)

Objects referenced by static variables will only be garbage collected when the relevant AppDomain is garbage collected. In client applications, there's often just a single AppDomain which lives for the duration of the process. (An exception is when the application uses a plug-in architecture - different plug-ins may be loaded in different AppDomains and the AppDomain may be unloaded later.)

In ASP.NET, "AppDomain recycling" happens periodically (for various reasons) - when this occurs, and the static variables within that AppDomain will no longer act as GC roots, and thus won't prevent objects being garbage collected.

If you were worried about an object being garbage collected while you still had a reference to it via a static variable, though, you can relax. While you can access the object, it won't be garbage collected.

The short answer... No; all current implementations of the .NET garbage collector will not collect objects strongly referenced by static class member fields, until the Application Domain those static class member field strong references are associated with, is torn down.

The longer answer... Potentially yes; the garbage collector bases its decision to collect an object on reachability of the object, not on references (strong or weak) to the object. In theory, if the garbage collector could determine that no code would ever require a certain object again from a certain point onwards (that is, the object is not reachable from any code path), the GC would be allowed to collect that object, even if it were still strongly referenced by static class member fields. This is perfectly allowable, since you'd never notice, since no code would ever try access the static class member field that holds the reference to the object. You might ask, so why do I care if I am never going to access the object again via any of the strong references I hold to it? The reason you'd care is side-effects. For instance, you might assume by assigning a static class member field a reference to a SafeHandle object, representing a unmanaged resource, that the SafeHandle object would never be closed and would thus keep the unmanaged "object" it represents alive. This is only true for the current implementations of the GC. A future implementation of the GC could collect objects strongly referenced by static class member fields if those objects were no longer reachable by any of the remaining program code.