visual-studio - Visual Studio 2008 加载项检查层次结构项是否为解决方案文件夹

Question

我有一个开发人员编写的 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)
  {
  }

}

}

}

Answer 1

到目前为止，从我的测试来看，解决方案文件夹似乎会令人惊讶地转换为 Project 类型，一旦完成，Project.ProjectItems 属性将包含该文件夹下可能存在的项目列表。所以简而言之，这是至少获取有关事物结构信息的一种方法。然而，问题是位于解决方案文件夹下的每个 ProjectItem 似乎都将 find 转换为类型 ProjectItem，但似乎无法转换为项目。

这就是我目前在循环中检测解决方案文件夹的方式。

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

这也让我很沮丧，我还注意到一个 bug in how ActiveReports handles solution folders以及与同一问题相关的内容。

更新!

好的，所以我找到了解决方案，但我不能 100% 认领它，因为我在 Macaw's Blog 找到了大部分解决方案.

因此看来我最初的发现是正确的，但是为了获得解决方案项下每个 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);
                }
            }
        }

根据这篇文章的事实和其他插件中的明显错误，很明显这不是最直观的设计，但这是我们必须忍受的。