0

Can MSBuild capture a list of the projects it has built "so far" during a build?

I would love a hypothetical @(ProjectsBuilt) item list I could access, which names the csproj files that have finished being been built.

You might ask "Why this feature?" In the abstract, it pertains to updating or exporting dependencies - particularly in an incremental build setting. I'll give two examples:

  • A Visual Studio solution contains a number of "plugin" projects. When some of the plugins have been updated, and built, a general-purpose script "captures" which projects were built, and immediately kicks-off nuget packaging and repository uploads.
  • A Visual Studio solution contains "implementation" projects and "interface" projects. In other words, some of the resulting assemblies are meant to be exported for use in other solutions. After some code changes have been made, the "interface" assemblies resulting from building any and all projects are then exported to a special "common" folder to be consumed by other applications.

Certainly the problems described above could be solved by having each "exported" or "plugin" project contain a post-build script to apply the appropriate dependency-exportation step. But it is anti-DRY to require a post-build step be added into every participating VS project.

If MS build would simply keep a running-tally of what projects have been built "so far," then at an appropriate build-step all the necessary "dependency exportations" could be done in one swoop, and from a centralized msbuild location. The projects targeted by this capability would not require any per-project build-steps at all. Nice!

Brent Arias
  • 29,277
  • 40
  • 133
  • 234
  • When would you want this list? During the build? What would you do with it? I'm not sure there's a concept of "project finished building" in MSBUILD, other than "when the MSBUILD command is finished, then all projects are as finished as they're going to be" – John Saunders Dec 28 '12 at 01:34
  • I updated the question with use-cases reflecting why this feature would be useful. – Brent Arias Dec 28 '12 at 04:08
  • I think you need to learn MSBUILD. It is not necessary to keep track of projects "built" in order to accomplish what you're looking for. Among other problems with your approach is that there's no good definition of "built". Which targets must have been executed for which projects, and with which outcome? What about the case of certain targets executing multiple times for the same project? – John Saunders Dec 28 '12 at 05:27
  • For your "exports", simply add a target that copies the files, using batching. The batches will only contain those files which are not up to date with respect to the destination. – John Saunders Dec 28 '12 at 05:28
  • Your "batching" comment has led to the following new question: http://stackoverflow.com/questions/14130628/incremental-build-of-nuget-packages – Brent Arias Jan 03 '13 at 05:20
  • Having done further research, I can now safely conclude that "keeping track of projects 'built'" is a VERY good idea for two reasons. First, MSBuild batching and incremental build capabilities are overly primitive. For example, a `.csproj` file knows all its transitive dependencies, whereas the `Inputs` attribute for my incremental build target does not. Second, MSBuild not only knows how to generate the list of projects "built so far," it actually DOES do so when building a Visual Studio solution file that has `Project Dependencies` defined! Now I just need to access that information! – Brent Arias Jan 10 '13 at 05:32
  • Where do you think it builds a list of projects built so far? And with what definition of "built"? Have you learned MSBUILD yet? I strongly recommend "[Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build](http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/)" – John Saunders Jan 10 '13 at 05:48

0 Answers0