Styjun

Certainly MS provides the api to do this without parsing the xml yourself. Look up microsoft.build.buildengine

Adapted from some C# code found on msdn ... it's usually worth exploring. Need to reference the microsoft.build.engine dll for this to compile. Replace framework version and path below with your values. This worked on a sample project file, although the list may be longer than you expect.

using System;
using Microsoft.Build.BuildEngine;
class MyTargets
 
 static void Main(string[] args)
 
 Engine.GlobalEngine.BinPath = @"C:WindowsMicrosoft.NETFrameworkv2.0.NNNNN";
 Project project = new Project();
 project.Load(@"c:pathtomyproject.proj");
 foreach (Target target in project.Targets)
 
 Console.WriteLine("0", target.Name);
 
 

I loved the idea of using PowerShell, but the pure XML solution doesn't work because it only outputs targets defined in that project file, and not imports. Of course, the C# code everyone keeps referring to is dead simple, and with .Net 4.5 it's two lines (the first of which you should consider just adding to your profile):

Add-Type -As Microsoft.Build
New-Object Microsoft.Build.Evaluation.Project $Project | Select -Expand Targets 

Yeah. Really. That's the whole thing.

Since the output is very verbose, you might want to restrict what you're looking at:

New-Object Microsoft.Build.Evaluation.Project $Project | 
 Select -Expand Targets |
 Format-Table Name, DependsOnTargets -Wrap

There is a catch, however.

When you load builds like that, they stick in the GlobalProjectCollection as long as you leave that PowerShell window open and you can't re-open them until you unload them. To unload them:

[Microsoft.Build.Evaluation.ProjectCollection]::GlobalProjectCollection.UnloadAllProjects()

Considering that, it might be worth wrapping that in a function that can accept partial and relative paths or even piped project files as input:

Add-Type -As Microsoft.Build
Update-TypeData -DefaultDisplayPropertySet Name, DependsOnTargets -TypeName Microsoft.Build.Execution.ProjectTargetInstance

function Get-Target 
 param(
 # Path to project file (supports pipeline input and wildcards)
 [Parameter(ValueFromPipelineByPropertyName=$true, ValueFromPipeline=$true, Position=1)]
 [Alias("PSPath")]
 [String]$Project,

 # Filter targets by name. Supports wildcards
 [Parameter(Position=2)]
 [String]$Name = "*"

 )
 begin 
 # People do funny things with parameters
 # Lets make sure they didn't pass a Project file as the name ;)
 if(-not $Project -and $Name -ne "*") 
 $Project = Resolve-Path $Name
 if($Project) $Name = "*" 
 
 if(-not $Project) 
 $Project = Get-Item *.*proj
 
 
 process 
 Write-Host "Project: $_ Target: $Name"
 Resolve-Path $Project 
 end 
 [microsoft.build.evaluation.projectcollection]::globalprojectcollection.UnloadAllProjects()
 

And now you don't even need to manually Format-Table...

Addendum:

Obviously you can add anything you want to the output with that Update-TypeData, for instance, if you wanted to see Conditions, or maybe BeforeTargets or AfterTargets...

You could even pull nested information. For instance, you could replace the Update-TypeData call above with these two:

Update-TypeData -MemberName CallTargets -MemberType ScriptProperty -Value % $_.Parameters["Targets"] 
 -TypeName Microsoft.Build.Execution.ProjectTargetInstance

Update-TypeData -DefaultDisplayPropertySet Name, DependsOnTargets, CallTargets -TypeName Microsoft.Build.Execution.ProjectTargetInstance

You see the first one adds a calculated CallTargets property that enumerates the direct children and looks for CallTarget tasks to print their Targets, and then we just include that ind the DefaultDisplayPropertySet.

NOTE: It would take a lot of logic on top of this to see every target that's going to be executed when you build any particular target (for that, we'd have to recursively process the DependsOnTargets and we'd also need to look for any targets that have this target in their BeforeTargets or AfterTargets (also recursively), and that's before we get to tasks that can actually just call targets, like CallTargets and MSBuild ... and all of these things can depend on conditions so complex that it's impossible to tell what's going to happen without actually executing it ;)

I suggest you use PowerShell:

Select-Xml `
 -XPath //b:Target `
 -Path path-to-build-file `
 -Namespace @ b = 'http://schemas.microsoft.com/developer/msbuild/2003' |
 Select-Object -ExpandProperty Node |
 Format-Table -Property Name, DependsOnTargets -AutoSize

The XPath query will find all Target elements and display the target name and dependencies in table format. Here is a sample that selects the 10 first targets from Microsoft.Web.Publishing.targets:

PS C:Program Files (x86)MSBuildMicrosoftVisualStudiov11.0Web> Select-Xml `
 -XPath //b:Target `
 -Path Microsoft.Web.Publishing.targets `
 -Namespace @ b = 'http://schemas.microsoft.com/developer/msbuild/2003' |
 Select-Object -ExpandProperty Node |
 Sort-Object -Property Name |
 Select-Object -First 10 |
 Format-Table -Property Name, DependsOnTargets -AutoSize

Name DependsOnTargets 
---- ---------------- 
_CheckPublishToolsUpToDate 
_CheckRemoteFx45 
_CleanWPPIfNeedTo 
_DetectDbDacFxProvider 
_WPPCopyWebApplication $(_WPPCopyWebApplicationDependsOn) 
AddContentPathToSourceManifest $(AddContentPathToSourceManifestDepe...
AddDeclareParametersItems $(AddDeclareParametersItemsDependsOn) 
AddDeclareParametersItemsForContentPath $(AddDeclareParametersItemsForConten...
AddDeclareParametersItemsForIis6 $(AddDeclareParametersItemsForIis6De...
AddDeclareParametersItemsForIis7 $(AddDeclareParametersItemsForIis7De...

Here is the code snippet to get all targets in the order their execution.

 static void Main(string[] args)
 
 Project project = new Project(@"build.core.xml");
 var orderedTargets = GetAllTargetsInOrderOfExecution(project.Targets, project.Targets["FinalTargetInTheDependencyChain"]).ToList();
 File.WriteAllText(@"orderedTargets.txt", orderedTargets.Select(x => x.Name).Aggregate((a, b) => a + "rn" + b));
 

 /// <summary>
 /// Gets all targets in the order of their execution by traversing through the dependent targets recursively
 /// </summary>
 /// <param name="allTargetsInfo"></param>
 /// <param name="target"></param>
 /// <returns></returns>
 public static List<ProjectTargetInstance> GetAllTargetsInOrderOfExecution(IDictionary<string, ProjectTargetInstance> allTargetsInfo, ProjectTargetInstance target)
 
 var orderedTargets = new List<ProjectTargetInstance>();

 var dependentTargets =
 target
 .DependsOnTargets
 .Split(';')
 .Where(allTargetsInfo.ContainsKey)
 .Select(x => allTargetsInfo[x])
 .ToList();

 foreach (var dependentTarget in dependentTargets)
 
 orderedTargets = orderedTargets.Union(GetAllTargetsInOrderOfExecution(allTargetsInfo, dependentTarget)).ToList();
 

 orderedTargets.Add(target);

 return orderedTargets;
 

If you build from command-line you can generate a metaproject file by setting an environment variable before building. This file will detail everything that a solution-file will target as well as outlining their target order.

It's not really a read-friendly diagnostic file but does have all the information you likely need in XML format.

E.g. from CMD and a typical VS2017 installation; replace line 1 with whatever build-tool-loader you use

call "%ProgramFiles(x86)%Microsoft Visual Studio2017EnterpriseCommon7ToolsVsDevCmd.bat"
set MSBuildEmitSolution=1
call MSBuild SolutionFile.sln /t:rebuild 

For a real example, I've made an SLN file starting with a C# project called mixed_proj, so I've got mixed_proj.sln, mixed_proj.csproj, then the two C++ projects I added, ConsoleApplication1 and DLL1.

I've set the build dependency order to where ConsoleApplication1 only builds after DLL1

Here is the command-line for building it:

call "%ProgramFiles(x86)%Microsoft Visual Studio2017EnterpriseCommon7ToolsVsDevCmd.bat"
set MSBuildEmitSolution=1
call MSBuild miced_proj.sln /t:rebuild 

Here is the generated metaproject file content (too big to paste here)