For the purpose of testing our C/C++ analyzer PVS-Studio, we often check various open-source projects and publish reports about bugs we have found. It is obvious that we seek projects of large sizes (hundreds of thousands of code lines), as there is little to be tested and caught in just a few dozens of files. We already had opportunities to test large collections consisting of hundreds of small open-source projects, for example sets of test samples for various SDKs and Frameworks. We are especially interested in checking such collections to see how the analyzer supports various specific code constructs, Visual C++ project subtypes, and so on.
But projects of this kind have one disadvantage which is not obvious at first sight: they lack a general project solution file. Each project in these sets is usually independent and has its own solution. Checking 4 or 5 hundred sln files is certainly not a fascinating employment, considering that handling hundreds of reports thus obtained will be pretty hard too.
Logic tells us that we could create one independent sln file (One Solution to Rule Them All) for all the project files to unite all the projects we need. But this simple task appears to be not as trivial in case of Visual Studio because the Add Project dialog allows you to choose only one project at a time! So even if you are lucky enough to have all the projects lying in one directory, the process of adding them will be painful all the same.
A quick search revealed at once that we were not alone who had faced this problem. But what do people usually suggest in this case? Well, they suggest "manually" generating a new solution, open it as a text file, and add the necessary code lines for each project. What is tricky about this method? You see, besides having to search through each project to find out its identifiers and configurations, you risk getting a conflict of dependencies or those very GUIDs of projects (even if only 2 of them). In that case you would have to manually investigate the whole solution to locate the problem! And writing a program that would take this all into account yet would be needed just a couple of times, is very burdensome.
After all, all this functionality can be found in Visual Studio itself - it is that very Add Existing Project that provides it. If only we could automate the process of calling this command and receiving the list of files... Well, we can do that. What's more, we can do it by adding just 4 code lines:
EnvDTE.DTE dte = Package.GetService(typeof(EnvDTE._DTE))
as EnvDTE.DTE;
m_dte = (EnvDTE80.DTE2)dte;
foreach (string file in Directory.GetFiles(ProjectRoot, "*.vcxproj",
SearchOption.AllDirectories))
m_dte.Solution.AddFromFile(file, false);As you can see, the object of the EnvDTE80.DTE2 type allows the program to add a project into the current solution by the file name. And it is quite what we need! Besides, the AddFromFile method also allows you to manage projects being added by returning references to each of them. Wrapping this code into a try...catch block will allow you to eliminate all the possible conflicts between separate projects.
What is after all EnvDTE80.DTE2 and how to get it? The DTE (development environment) object is the top-level object of the Visual Studio Extensibility API which allows you to automate the process of working in IDE and even extend its capabilities. There are several different ways to get access to DTE, both from an external process and by creating an extension package or a plugin for the Visual Studio environment. We have a series of articles on our website on the basics of development of such plugins, where you can find simple instructions on how to create such a plugin right now!