This information is included in the product DeliverPoint 2007. For more
information, you can visit http://www.barracuda.net

Ok, I have made some progress on this. Here is the code snippet I have:

SPWebApplication webApp = SPContext.Current.Site.WebApplication;
foreach (SPSite site in webApp.Sites)
{
if
(site.RootWeb.DoesUserHavePermissions(SPBasePermissions.ViewListItems))
{
//writer.WriteLine(site.RootWeb.Url);
row = data.NewRow();
//row["Site Name"] = site.RootWeb.Name;
row["Site Name"] = site.RootWeb.Title;
row["URL"] = site.RootWeb.Url;
data.Rows.Add(row);
}
}
Above works fine in a webpart. However, the site collection
http://servername shows up twice. Any ideas why that is the case?

I could in the foreach loop to check for duplicates, but why do I need
to do that?

It is very import to dispose of SPSite and SPWeb objects.

It is very "important" to dispose of SPSite and SPWeb objects.

It is, but only if you've allocated them yourself, e.g. by calling a
constructor. Objects passed via a context object, directly or
indirectly, as in the sample code referenced should not be
disposed of:

If you create  your own SPWeb or SPSite object with a
constructor (see the next section), you can [should!]
use its Close or Dispose method to close the object.
However, if you have a reference to a shared resource,
such as when the objects are provided through members
of the SPContext class, do not use the Dispose or Close
method to close the object, but instead allow Windows
SharePoint Services or your portal application to
manage the object.

All very true. However, if you look at the code the sites  are being
instantiated as part of a Foreach loop walking a collection. In my
experience those need to be treated like objects you allocated yourself,
not objects provided by the SPContext class. The SPWebApplication
doesn't need to be disposed of, but the SPsite objects in the foreach
loop should be.

I missed the Context object. Good catch!

I added code inside the foreach to
dispose each spsite object.

Going back to my situation about site collection http://servername
showing up twice, on my qa env, it shows up only once. So there must
be something on dev env, not sure what yet.

In a normal Object oriented environment I agree with you 100%. And
there is a very good chance in SharePoint that you are still correct and
I am wrong. But here is my understanding/theory for why I dispose of
objects where a reference was retrieved from a parent container. I'm
not trying to argue, I really would like to explore this and get a
better idea of exactly what is happening behind the scenes.

In SharePoint these objects don't reside in memory, they are stored in
the SQL database. So when you retrieve a reference from a parent
container are you actually retrieving a reference to an instantiated
object or are you referencing an object serialized in the database that
must be instantiated from the database when you use it. When getting an
object directly from SPContext it is already instantiated for use in the
context. But when referencing an object as part of a collection you
are referencing an object that is still serialized in the database. If
you retrieve that reference as an object I think it ceases to be a
serialized object in the database and is then instantiated. If it is
instantiated as a result of your reference, separate from the context,
shouldn't you then dispose of it?

From the collection properties of their containers. And we dispose of
them as the last line of the foreach loop.

I based my comments on the MSDN Technical Article Best Practices: Using
Disposable Windows SharePoint Services Objects
<msdn2.microsoft.com/.../aa973248.aspx> . (Which, by
the way, recommends calling Dispose at the end of each loop when using
SPSite.AllWebs.)

So it does, thanks for the reference. I'd not realized SPSite and
SPWeb had unmanaged resources, which generally requires more care in
managing object references even in a GC'd environment. Ah well, life
is rarely as simple as we'd wish.

Judging by the behavior of the debugger when you are trying to view
properties of the children sharepoint objects, stored as serialized
in the database,(big delays) it looks like the referenced objects
really get deserialized when used first time. Also from my
experience "overdisposing" on them doesn't cause any problems.