I recently wanted to look at the dependencies of a fairly large set of projects in a solution (not the one in the screenshot), and discovered that while there are apps/tools that do that, they are either Code Project articles for previous versions of Visual Studio or they create an unreadable smear of boxes and lines, because they were never designed to handle a solution with 50 or more projects. So, I decided to create a textual, treeview based browser of dependencies.
It's very simple, offering both a hierarchical view of project dependencies or a flattened list of dependencies, and also a tree-view showing projects that are dependencies of other projects (the right-hand side of the image above).
Note how the view is hierarchical, allowing you to drill into each project's dependencies.
In this view, the application drills into project dependencies for you and presents all unique dependencies in a flattened list:
You can also pick a project and find out what projects reference the selected project:
The code is really simple. Very little error checking and pretty much brute force implementation. The one annoying thing I discovered is that the solution file is not an XML document, whereas the project files (csproj) are. Makes one wonder.
Basically, this involves a lot of string checking and processing, in which a dictionary of project names and project paths is created.
public class Solution
{
protected Dictionary<string, string> projectPaths;
public Dictionary<string, string> ProjectPaths
{
get { return projectPaths; }
}
public Solution()
{
projectPaths = new Dictionary<string, string>();
}
// Example:
// Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "NumericKeypadComponent",
// "NumericKeypadComponent\NumericKeypadComponent.csproj",
// "{05D03020-4604-4CE9-8F99-E1D93ADEDF15}"
// EndProject
public void Read(string filename)
{
StreamReader sr = new StreamReader(filename);
string solPath = Path.GetDirectoryName(filename);
while (!sr.EndOfStream)
{
string line = sr.ReadLine();
if (!String.IsNullOrEmpty(line))
{
if (line.StartsWith("Project"))
{
string projName = StringHelpers.Between(line, '=', ',');
projName = projName.Replace('"', ' ').Trim();
string projPath = StringHelpers.RightOf(line, ',');
projPath = StringHelpers.Between(projPath, '"', '"');
projPath = projPath.Replace('"', ' ').Trim();
// virtual solution folders appear as projects but don't end with .csproj
// gawd, imagine what happens if someone creates a foo.csproj
// virt. solution folder!
if (projPath.EndsWith(".csproj"))
{
// assume relative paths. Probably not a good assumption
projPath = Path.Combine(solPath, projPath);
// we don't allow projects with the same name, even if different paths.
projectPaths.Add(projName, projPath);
}
}
}
}
sr.Close();
}
}
Ah, an XML file! Woohoo! It took a while for me to realize that I needed to specify the XML namespace along with the element name. As in, several hours of fussing, pulling hair out, and finally stumbling across some documentation in MSDN that gave an example of using Elements with a namespace. Sigh.
Similar to the Solution class, this class builds a dictionary of referenced projects, where the key is the referenced project name and the value is the referenced project path.
public class Project
{
protected Dictionary<string, string> referencedProjects;
protected List<Project> dependencies;
public string Name { get; set; }
public Dictionary<string, string> ReferencedProjects
{
get { return referencedProjects; }
}
public List<Project> Dependencies
{
get { return dependencies; }
}
public Project()
{
referencedProjects = new Dictionary<string, string>();
dependencies = new List<Project>();
}
// Example:
// <Project ToolsVersion="3.5" DefaultTargets="Build"
// xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
// <ItemGroup>
// <ProjectReference Include="..\Cx.Attributes\Cx.Attributes.csproj">
// <Project>{EFDBD81C-64BE-47F3-905E-7618B61BD224}</Project>
// <Name>Cx.Attributes</Name>
// </ProjectReference>
public void Read(string filename)
{
XDocument xdoc = XDocument.Load(filename);
XNamespace ns = "http://schemas.microsoft.com/developer/msbuild/2003";
foreach (var projRef in from el in
xdoc.Root.Elements(ns + "ItemGroup").Elements(ns + "ProjectReference")
select new
{
Path = el.Attribute("Include").Value,
Name = el.Element(ns + "Name").Value
})
{
string projPath = Path.GetDirectoryName(filename);
projPath = Path.Combine(projPath, projRef.Path);
referencedProjects.Add(projRef.Name, projPath);
}
}
}
A separate method is used to put the solution and projects together into yet another dictionary, this time the key being the project name and the value being a Project instance. This method also populates the Dependencies collection in the Project class (yeah, that's really bad practice, I know).
protected Dictionary<string, Project> projects;
protected void ParseSolution(string filename)
{
projects = new Dictionary<string, Project>();
Solution sol = new Solution();
sol.Read(filename);
foreach (KeyValuePair<string, string> kvp in sol.ProjectPaths)
{
Project proj = new Project();
proj.Name = kvp.Key;
proj.Read(kvp.Value);
projects.Add(proj.Name, proj);
}
foreach (KeyValuePair<string, Project> kvp in projects)
{
foreach (string refProjName in kvp.Value.ReferencedProjects.Keys)
{
Project refProject = projects[refProjName];
kvp.Value.Dependencies.Add(refProject);
}
}
}
There are two ways of populating the dependency graph: hierarchical or flat. The code for both is similar--the big difference is that child nodes aren't being created. And another ugly kludge in the flattened implementation is how I search for assemblies already in the node collection. Yuck!
/// <summary>
/// Sets up initial project name and first level of dependencies.
/// From there, child dependencies are either added hierarchically or flattened.
/// </summary>
protected void PopulateNewLevel(TreeNode node, ICollection<Project> projects)
{
List<string> nodeNames = new List<string>();
foreach (Project p in projects)
{
TreeNode tn = new TreeNode(p.Name);
node.Nodes.Add(tn);
if (asTree)
{
PopulateNewLevel(tn, p.Dependencies);
}
else
{
// flatten the dependency hierarchy, removing duplicates
PopulateSameLevel(tn, p.Dependencies);
}
}
}
protected void PopulateSameLevel(TreeNode node, ICollection<Project> projects)
{
foreach (Project p in projects)
{
bool found = false;
foreach (TreeNode child in node.Nodes)
{
if (child.Text == p.Name)
{
found = true;
break;
}
}
if (!found)
{
TreeNode tn = new TreeNode(p.Name);
node.Nodes.Add(tn);
}
PopulateSameLevel(node, p.Dependencies);
}
}
Also straightforward, also has a kludge to remove duplicate project names.
protected void PopulateDependencyOfProjects(TreeNode node, ICollection<Project> projects)
{
foreach (Project p in projects)
{
TreeNode tn = new TreeNode(p.Name);
node.Nodes.Add(tn);
foreach (Project pdep in projects)
{
foreach (Project dep in pdep.Dependencies)
{
if (p.Name == dep.Name)
{
bool found = false;
// the project pdep has a dependency on the project p.
// p is a dependency of pdep
foreach (TreeNode tnDep in tn.Nodes)
{
if (tnDep.Text == pdep.Name)
{
found = true;
break;
}
}
if (!found)
{
TreeNode tn2 = new TreeNode(pdep.Name);
tn.Nodes.Add(tn2);
}
}
}
}
}
}
Hopefully someone will find this useful and maybe even build upon it! It was a short and fun to write application. One thing I'd like to add is sorting the project names.
6/17/2009 - Initial Version
6/25/2009
7/5/2009 - Added rendering of graph using graphviz. Thanks to Dmitri Nesteruk for making the original changes to this application and for making his rendering code public.
| You must Sign In to use this message board. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
am i missing something here 
