In theory yes, in practice there are buggy .Net assemblies out there which hand out "property" objects to the caller without those objects referencing their owner in any proper way but still maintaining some pointers that are owned by the owner. Releasing the owner before the owned object could then mean that the the owned object tries to reference something in the owner which has already vanished from memory. So I make it a rule to always close ActiveX and .Net objects in the reverse order in which I obtained them.
Note that you will only get this really bad behavior if there is an actual unsafe pointer (not a normal CLR reference) involved or there is code written to deliberately deviate from the idea of GC (for example; deliberately passing by reference and then nulling references). Otherwise if an object has a root that is not eligible for collection then it too will be ineligible.
In fact the CLR GC is notoriously cautious about this - an example of this is event handlers; when a caller registers to an event the delegate also includes a pointer to the caller. If the caller goes out of scope then it is not eligible for GC as it is still referenced through the delegate to object with the list of event handlers; it will remain in memory and its event handlers will be called. This is a common memory leak (forgetting to remove event handlers for the shorter-lived items that register for them) eg. here
