Visual Studio and .NET Framework Home
ProjectItem.Collection wrong for folders of SQL Server projects of VSTS for Database Professionals
Carlos J. Quintero
9/5/2007 5:05:00 AM
User(s) can reproduce this bug
I am sort of reopening the bug that I reported in http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=295434 because it was closed without acknowledging the bug and providing a f¡x. The problem has nothing to do with scenarios or what to accomplish with DTE. It is just that the current implementation of the automation model VS 2005 and VS 2008 Beta2 has a bug. I will try to explain it much better and even provide where the code of MS is wrong:
- An EnvDTE.ProjectItem of a project can be a folder or a file.
- A folder contains folders or files
- A file can contain dependant files (such as .designer.cs or .resx)
- For that purpose, the EnvDTE.ProjectItem class of the automation model provides two properties:
1) ProjectItem.ProjectItems: this collection returns the children of the ProjectItem (be a folder or a file). It is used to navigate the hierarchy from top to bottom.
2) ProjectItem.Collection: this collection returns the collection of items the ProjectItem (be a folder or a file) belongs to. In particular, the ProjectItem.Collection.Parent property returns the parent of the ProjectItem. It is used to navigate the hierarchy from bottom to top.
It should be clear at this point that both collections are different and can not be the same.
SQL Server Database projects implement the automation model in the Microsoft.VisualStudio.Package.Automation. namespace of the Microsoft.VisualStudio.TeamSystem.DataPackage.dll package. In this namespace, there are two classes of interest:
This class implements correctly the Collection property as follows:
public virtual ProjectItems get_Collection()
HierarchyNode parent = this.node.Parent;
if (parent is ProjectNode)
return ((OAProject) parent.GetAutomationObject()).ProjectItems;
if ((parent is FileNode) && (parent.FirstChild != null))
return ((OAProjectItem<FileNode>) parent.GetAutomationObject()).ProjectItems;
if (!(parent is FolderNode))
throw new NotImplementedException();
return ((OAProjectItem<FolderNode>) parent.GetAutomationObject()).ProjectItems;
Notice that it uses "parent" because the Collection property refers to the parent, not to the children.
2) OAFolderItem, which inherits from that class and overrides (incorrectly) the ProjectItems and Collection to return the same value!:
public override ProjectItems Collection
return new OAProjectItems(base.Project, base.Node);
public override ProjectItems ProjectItems
Notice that this implementation is absolutely wrong!
Visual Studio 2005 (All Products and Editions) Service Pack 1
Windows XP Professional
Operating System Language
Steps to Reproduce
- Create a new database project, which will have the folders "Data Generation Plans", "Schema Objects" and "Scripts"
- Run this macro:
Dim objProjectItemFolder As ProjectItem
Dim colParentCollection As ProjectItems
objProjectItemFolder = DTE.Solution.Projects.Item(1).ProjectItems.Item("Data Generation Plans")
colParentCollection = objProjectItemFolder.Collection
If colParentCollection.Count = 0 Then
MsgBox("We should be 3 folders, not 0!!!")
You get that the parent collection has 0 items, where it should be 3 folders. This happens because the Collection property is actually returning (incorrectly) the children of the "Data Generation Plans" folder, which are 0.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 9/5/2007 at 7:01 PM
Thanks for your feedback. We have routed this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
Visual Studio Product Team.
on 9/5/2007 at 5:19 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com).
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
© 2013 Microsoft