MZ-Tools Articles Series: HOWTO: Use the Browse for Folder dialog of Visual Studio from a package

Another question in the MSDN VSX Forum about the browser for folder dialog was intriguing enough for me to investigate. If you are using the .NET Framework since version 1.0 (like me), you may remember that that version didn’t provide a class, you had to use the native class of the Win32 API Shell, which was tricky. The FolderBrowserDialog was added in .NET Framework 1.1, and since then it has this appearance:

NetFolderBrowserDialog

Despite being in Spanish (the computer that I am using to write this post), you can guess that it provides a title, a description, a treeview and an optional button to allow the creation of a new folder without leaving the dialog.

However, Visual Studio uses this other dialog to select a folder in several places:

VisualStudioFolderBrowserDialog

Again, despite being in Spanish, you can guess that it provides a treeview to the left and a listview to the right, along with the button to create a new folder and, overall, somewhat better usability.

So, the question was how to leverage that Visual Studio dialog from a package. The answer lies in the IVsUIShell.GetDirectoryViaBrowseDlg method, and in this new article of mine you have a working example, because the API is awful, with arrays of structures, memory allocation, marshaling, etc:

HOWTO: Use the Browse for Folder dialog of Visual Studio from a package

MZ-Tools Articles Series: HOWTO Unload/Reload a project from a Visual Studio package

I have created two new articles/samples from a question that I addressed in the StackOverflow forum, about unloading / reloading a project programmatically. Using the automation model (EnvDTE) I knew the answers since many years ago:

DTE.ExecuteCommand(“Project.UnloadProject”)
DTE.ExecuteCommand(“Project.ReloadProject”)

However, that approach requires that the project is selected previously in the Solution Explorer. Furthermore, having migrated my MZ-Tools add-in to a Visual Studio package I am no longer happy when I have to use the old automation model and I am eager to investigate how to do things using native services. Alas, the investigation is never easy. In this case the IVsSolution interface provides the CloseSolutionElement method, which is not intuitive because it serves to unload many things, from the solution to a document, and certainly a project too. And it doesn’t seem to provide a method to reload a project. So, I opened the MSDN documentation for IVsSolution2, IVsSolution3, IVsSolution4, IVsSolution5 and IVsSolution6 interfaces and lo and behold, the IVsSolution4 interface has the answers in the UnloadProject / ReloadProject methods. If you remember, Visual Studio 2012 introduced asynchronous solution loading (something that seemed to start in Visual Studio 2010), so the new IVsSolution4 interface introduced quite a few methods that helps with that area. So, here are the samples:

HOWTO: Unload a project from a Visual Studio Package

HOWTO: Reload a project from a Visual Studio Package

Both methods require the project guid that identifies the project in the solution (not to confuse with the project type guid). You can get the project guid from a IVsHierarchy that represents a project calling the GetProperty method with the __VSHPROPID.VSHPROPID_ProjectIDGuid property. For VS 2010, alas, when the project is unloaded the “hierarchy stub” that represents the unloaded project in the solution doesn’t implement that property (it does in VS 2012 and higher). So, the second article applies to VS 2012 and higher (because it starts with an unloaded project as the initial condition), while the first could apply also to VS 2010.

Finally, for completeness sake, given a IVsHierarchy that represents an unloaded project you can get the unload reason calling the GetProperty method with the __VSHPROPID5.VSHPROPID_ProjectUnloadStatus property, which should return a value of the _VSProjectUnloadStatus enumeration.

Microsoft fixing all bugs of FileCodeModel in VS 2015. And fast.

In this post I blogged about nine bugs introduced in the FileCodeModel of Visual Studio 2015 by the new Roslyn-based implementation. Those bugs were “critical” (that is, no easy workaround) and were fixed in the next days.

Then I reported two additional bugs that were less critical for me since I could implement workarounds:

EnvDTE.CodeElement GetStartPoint(EnvDTE.vsCMPart.vsCMPartBody).Line returns wrong result if declaration uses more than one line

EnvDTE80.CodeProperty2.ReadWrite returns always read-write value for VB.NET body-less properties

Those were fixed too. And two days ago I reported a couple of new critical bugs (no workaround) that I discovered:

EnvDTE.CodeFunction.FunctionKind causes COMException for Sub New() in VB.NET instead of returning vsCMFunction.vsCMFunctionConstructor

EnvDTE.CodeFunction.StartPoint, EndPoint, GetStartPoint, etc. cause exception for VB.NET “Declare Sub”/”Declare Function” methods

And those two have been already fixed on GitHub and will be in the some of the next Visual Studio 2015 CTPs.

It is also very incredible the level of transparency that Microsoft has now using open source for Roslyn on GitHub, where you can see the new code that fixes the bugs, the added unit tests, which MS developer is actually working on the fixes, who is reviewing them, etc.

So, thanks Microsoft for all!

MZ-Tools Articles Series: HOWTO: Get Git Branches, Commits, Changes, Conflicts, etc. in the Team Explorer of Visual Studio

The next five articles / samples that I have created about Team Explorer extensibility are about getting the information contained in the Git-related pages of the Team Explorer of Visual Studio 2013.

The Branches page contains the current branch and the Published and Unpublished sections:

TeamExplorerGitBranches

To get that information from a package you need to use the Microsoft.TeamFoundation.Git.Controls.Extensibility.IBranchesExt interface. See the article:

HOWTO: Get the Git Branches in the Team Explorer of Visual Studio from a package

The Commits page contains the Incoming Commits and Outgoing Commits sections:

TeamExplorerGitCommits

To get that information from a package you need to use the Microsoft.TeamFoundation.Git.Controls.Extensibility.ICommitsExt interface. See the article:

HOWTO: Get the Git Commits in the Team Explorer of Visual Studio from a package

The Changes page contains the Included Changes, Excluded Changes and Untracked Files sections:

TeamExplorerGitChanges

To get that information from a package you need to use the Microsoft.TeamFoundation.Git.Controls.Extensibility.IChangesExt interface. See the article:

HOWTO: Get the Git Changes in the Team Explorer of Visual Studio from a package

The Resolve Conflicts page contains the Conflicts and Resolved Conflicts sections:

TeamExplorerGitConflicts

To get that information from a package you need to use the Microsoft.TeamFoundation.Git.Controls.Extensibility.IConflictsExt interface. See the article:

HOWTO: Get the Git Conflicts in the Team Explorer of Visual Studio from a package

The Commit Details page contains the commit properties and Changes section:

TeamExplorerGitCommitDetails

To get that information from a package you need to use the Microsoft.TeamFoundation.Git.Controls.Extensibility.ICommitDetailsExt interface. See the article:

HOWTO: Get the Git Commit Details in the Team Explorer of Visual Studio from a package

MZ-Tools Articles Series: HOWTO: Get the Builds / Pending Changes in the Team Explorer of Visual Studio from a package

The two first samples that I have created about Team Explorer extensibility are about getting the information contained in the Builds and Pending Changes pages.

The Builds page contains three sections: My Builds, Favorite Builds Definitions and All Build Definitions:

TeamExplorerBuilds

To get that information from a package you need to use the Microsoft.TeamFoundation.Build.Controls.Extensibility.IBuildsPageExt interface. See the following article:

HOWTO: Get the Builds in the Team Explorer of Visual Studio from a package

The Pending Changes page contains the Comment, Related Work Items, Included Changes and Excluded Changes sections:

TeamExplorerPendingChanges

To get that information from a package you need to use the Microsoft.TeamFoundation.VersionControl.Controls.Extensibility.IPendingChangesEx interface. See the following article:

HOWTO: Get the Pending Changes in the Team Explorer of Visual Studio from a package

New TFS Extensibility resources added to VSX site

A question in the MSDN VSX forum prompted me to investigate another area, Team Explorer extensibility, which I am not very familiar with yet. After solving the question, I wanted to learn more about Team Explorer / TFS Extensibility and I found quite a few resources that I didn’t have listed on this VSX site. Some resources that I have updated are:

  • In the Overview page, I have added an image from the MSDN documentation to illustrate the several client models, and clarified that you need the Team Explorer to get the client libraries even if you want a standalone application to connect to TFS.
  • In the Downloads page, I have added the links to download the Team Explorer packages for Visual Studio 2005-2013, which, by the previous paragraph, are required to get the client libraries for standalone applications that don’t extend the Team Explorer. The client model object assemblies and namespaces are quite confusing because some are Microsoft.TeamFoundation.* and some others are Microsoft.VisualStudio.TeamFoundation.*, and are located in at least three folders (ReferenceAssemblies\v2.0, ReferenceAssemblies\v4.5, and PrivateAssemblies of the root folder Program Files (x86)\Microsoft Visual Studio <version>\Common7\IDE). The MSDN documentation for Visual Studio 2012 has a nice mapping between assemblies and namespaces.
  • In the Articles section, I have added a couple of articles to extend the Team Explorer of Visual Studio 2012 / 2013, and an impressive collection of 56 articles about TFS API by MVP fellow Shai Raiten.

In the next posts, I will contribute myself explaining how to get information about the different pages / sections of the Team Explorer.