SPWeb.Site, стоит ли на нем вызывать Dispose ()?

Ответ Кирка правильный. Перед созданием SPWeb у вас должен быть какой-то дескриптор SPSite, и это тот же самый экземпляр SPSite, который будет у вас при вызове SPWeb.Site.

Давайте подумаем о последствиях этого - если вы не контролируете создание SPSite, но один из его дочерних веб-сайтов передается вам из внешнего кода, и вы удаляете сайт, когда управление возвращается вызывающему коду, вы мы удалили Сайт, с которым они не могут справиться! Поставьте себя на место вызывающего кода: вы передаете SPWeb в метод, и когда этот метод будет выполнен, используемый вами SPSite будет закрыт. Ответственность за очистку ресурсов, которые они выделяют, всегда лежит на создателе экземпляра. В этом случае не утилизируйте SPSite.

Просто подумайте о том, что у меня в голове (иногда опасно) ...

Кажется, что у вас не может быть SPWeb без SPSite. Итак, если вы получили SPWeb, не пройдя через SPSite для его получения (либо создав новый SPSite, либо предоставленный вам), то вам, вероятно, не нужно беспокоиться об утилизации SPSite.

Однако это всего лишь предположение. Хороший вопрос!

Это не ясно. Есть блог Стефана, в котором говорится: «Убедитесь, что вы удаляете только те объекты SPSite и SPWeb, которые принадлежат вашему коду». Тогда есть этот поток от Майкла Уошама (Microsoft), который утверждает, что этот шаблон действительно просочился.

Если вы не можете найти другую ссылку или кто-то еще не знает, почему бы вам не протестировать ее на своем сервере разработки и не добавить свои результаты в качестве ответа на этот вопрос? Поместите его в цикл, который выполняется 100 раз, и используйте ключ реестра SPRequestStackTrace, описанный в Устранение неполадок с утечками SPSite / SPWeb в WSS v3 и MOSS 2007, чтобы убедиться, что ваш тестовый код является источником проблемы.

Reflector сообщает нам, что это код, который запускается внутри объекта SPWeb, когда вы вызываете свойство Site:

public SPSite Site
{
    get
    {
        return this.m_Site;
    }
}

Он не создает новый объект SPSite, а просто возвращает тот, который у него уже был, о чем при необходимости позаботится SPWeb.Dispose (). Таким образом, вы можете безопасно использовать его, и я бы не стал избавляться от него, чтобы зависимости SPWeb не испортились вам.

Вы пробовали проверить свою сборку с помощью SPDisposeCheck? Возможно, это подскажет, как решить вашу проблему.

Я часто использую этот шаблон в своем коде SharePoint в качестве практического правила, если вызов depose не приводит к сбою всего, что я его называю. Другое правило, которому я следую, - я стараюсь не создавать расширения, которые не вызывают чистого выигрыша в SPRequest объектах (объект SPRequest - это объект .net, который общается со всеми тяжелыми объектами com)

теперь разбиваю ваш пример

 for (int i = 0; i < 100; i++)
 {
     using (SPWeb web = SPContext.Current.Site.OpenWeb(""))
     {
            SPSite site = web.Site;
            Debug.WriteLine(site.Url);
     }
 }

Ключевым моментом здесь является SPContext.Current.Site. SPContext будет очищаться после того, как он сам правильно работает (один из немногих объектов, которые это делают), поскольку мы знаем, что сайт очищается правильно, я ожидаю, что сети были очищены до, однако это далеко от правильный ответ на ваш вопрос. (обратите внимание, что у вас должна быть утечка веб-сайтов, которые вы получили через OpenWeb)

public static void GetWebPartFromCatalog(this SPWeb web, string webPartName)

вам нужно заставить SPSite что-то делать с веб-частями.

1. свойство web.Site на самом деле очищается после того, как оно само, ЕСЛИ сеть удаляется.
2. Почему бы просто не передать объект SPSite и позволить пользователю функции беспокоиться об этом? В большинстве случаев я бы подумал, что они все равно будут звонить с использованием SPContext.Current.Site.
3. В большинстве случаев мне приходится беспокоиться о разрешениях, не все наши библиотеки DLL попадают в GAC, поэтому, когда я пишу новый метод расширения, мне приходится обертывать его SPSecurity.CodeToRunElevated

Имея это в виду, я бы написал это как. . . Теперь проверка Dispose в этом случае отключится, потому что SPSite передается в качестве аргумента, потому что он не может отследить, в какой области он расположен.

public static void GetWebPartFromCatalog(this SPSite site, string webPartName) {
     SPSecurity.CodeToRunElevated( () => {
         using(SPSite suSite = new SPSite(site.Id)){
             //do what you need to do
         }
     };
}

У Стефана Гобнера есть отличная статья по этому поводу: Устранение неполадок, связанных с утечками SPSite / SPWeb в WSS v3 и MOSS 2007

... И обязательно используйте инструмент проверки SPDispose в вашей кодовой базе.

Вам необходимо удалить экземпляр SPSite / SPWeb, если это новый объект

eg

using(SPSite site = new SPSite("url"))
{
    DoSomething;
}

здесь using позаботится об удалении объекта, однако, если вы получили ссылку на объект из SPContext.Current, вы не должны явно удалять объект, поскольку ссылка должна быть доступна из SPContext.Current.