Надстройка Visual Studio 2008 Проверьте, является ли элемент иерархии папкой решения - PullRequest
3 голосов
/ 03 апреля 2009

У меня есть надстройка для Visual Studio, написанная разработчиком, который больше не работает в компании и не знает, как его отладить. Но я хочу добавить функцию, чтобы она могла переходить в папки решений.

Звучит просто, но я не уверен, что API позволяет тестировать это? Ну, должен быть выход, потому что AnkhSVN и VisualSVN прекрасно работают с папками решений.

StackOverflow Я обращаюсь за помощью по этому вопросу.

Спасибо

Примечания

- Мы используем папки решений, чтобы скрыть «Проекты зависимостей», которые в основном представляют собой список ссылок на проекты, которые нам, вероятно, не нужны в конкретном решении и которые мы хотим скрыть по умолчанию.

public class Connect : IDTExtensibility2, IDTCommandTarget
{

public void GetProjectLocations(DTE2 dte)
{

UIHierarchy UIH = dte.ToolWindows.SolutionExplorer;

try
{
     UIHierarchyItem UIHItemd = UIH.UIHierarchyItems.Item(1);
}
catch (Exception E)
{
  Debug.Write(E);
}

UIHierarchyItem UIHItem = UIH.UIHierarchyItems.Item(1);//this looks suspect to me

// Iterate through first level nodes.
for (int i = 1; i <= UIHItem.UIHierarchyItems.Count; i++)
{
  Project TempGeneralProjObj = dte.Solution.Item(i);  

  if (TempGeneralProjObj.Kind == PrjKind.prjKindCSharpProject)
  {
  }

}

}

}

Ответы [ 2 ]

4 голосов
/ 13 августа 2009

Пока из моих тестов кажется, что папки решений будут удивительно приводить к типу Project, и как только это будет сделано, свойство Project.ProjectItems будет содержать список проектов, которые могут существовать в этой папке. Короче говоря, это один из способов, по крайней мере, получить информацию о том, как все устроено. Проблема, однако, заключается в том, что каждый ProjectItem, расположенный под папкой решения, кажется, приводит приведение к типу ProjectItem, но не может быть приведен к Project.

Вот как я в настоящее время обнаруживаю папку решения в цикле.

if(project.Kind == "{66A26720-8FB5-11D2-AA7E-00C04F688DDE}")
{
    // TODO: Do your thing
}

Это также разочаровало меня, и я также заметил ошибку в том, как ActiveReports обрабатывает папки решений , которая связана с этой же проблемой.

UPDATE!

Хорошо, так что я нашел решение, но я не могу претендовать на него на 100%, потому что я нашел большую его часть в Блог Macaw's .

Таким образом, похоже, что мои первоначальные выводы были правильными, чтобы получить фактический тип проекта для каждого ProjectItem в элементе решения, который вы должны искать в свойстве ProjectItem.SubProject .

Теперь Macaw использует рекурсивный подход к обходу структуры проекта, который, я думаю, я бы тоже обычно рекомендовал, однако в моем случае я хотел, чтобы реализация одного метода просто выходила из XML-представления проекта для простых исследовательских целей, поэтому я в итоге используя реализацию стека. Для справки вы можете найти мой код ниже, который успешно обрабатывает как минимум один уровень папок решений, полный только проектов, и никаких других специальных решений.

        XElement rootNode = new XElement("Solution");
        rootNode.Add(new XAttribute("Name", _applicationObject.Solution.FullName));

        Stack<Project> projectStack = 
            new Stack<Project>(_applicationObject.Solution.Projects.Cast<Project>());

        while(projectStack.Count > 0)
        {
            var project = (Project)projectStack.Pop();
            var solutionItemName = "Project";

            if(project.Kind == "{66A26720-8FB5-11D2-AA7E-00C04F688DDE}")
            {
                foreach(ProjectItem innerProject in project.ProjectItems)
                {
                    if(innerProject.SubProject != null)
                    {
                        projectStack.Push(innerProject.SubProject);
                    }
                }
                solutionItemName = "Folder";
            }

            var projectNode = new XElement(
                solutionItemName, 
                new XAttribute("Name", project.Name),
                new XAttribute("Kind", project.Kind)
                );
            rootNode.Add(projectNode);

            foreach(ProjectItem item in project.ProjectItems)
            {
                var itemNode = new XElement("Item", new XAttribute("Name", item.Name));
                projectNode.Add(itemNode);

                if(item.Properties == null)
                {
                    continue;
                }

                foreach(Property property in item.Properties)
                {
                    var propertyNode = new XElement(property.Name, property.Value);
                    itemNode.Add(propertyNode);
                }
            }
        }

Из этого поста и очевидных ошибок в других надстройках очевидно, что это не самый интуитивно понятный дизайн, но это то, с чем нам приходится жить.

1 голос
/ 03 апреля 2009

Чтобы отладить надстройку Visual Studio, загрузите исходный код в копию Visual Studio, на которой не запущена надстройка. Затем настройте проект для запуска второй копии Visual Studio при «запуске» проекта, после чего вторая копия будет работать с первой способной точкой останова и отладкой.

Убедитесь, что у вас есть пакетный файл (или его эквивалент) для очистки, чтобы вы всегда могли вернуться к работе VS без плагина.

Полезные ресурсы ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...