How would you spend $100 on MSBuild?
We're currently planning for our next version (aka, "Dev10" - no code name this time) and subsequent releases. In that spirit, I'd like to do a quick poll of MSBuild aficionados to help us keep our "vision" for MSBuild aligned with yours, our customers.
First, a caveat - while ideally I would like to rank the results and work down the list, the reality is that we have other constraints: although we are a separate build platform, our biggest customer by far is Visual Studio and its customers. There's a lot more Visual Studio users than direct MSBuild users, so when Visual Studio needs to add a feature that requires work on MSBuild, we have to help. Then there's other constraints, like team resources. There's no guarantee which of these will appear in what version, and some of them may not be worth any investment. Some of them I just made up.
OK. Here’s some brainstormed features. Some of them are properly Visual Studio features, but they overlap closely with build:
1) Higher performance multiprocessor support. For example, we suspect there is plenty of room to improve the scheduling we do, and find speedups elsewhere in the code. As more and more of us have multicore machines, this might be a good place to invest.
2) VC support. This means converting VC projects (.vcproj) to MSBuild format, a customizable and extensible build process entirely defined by MSBuild .targets files rather than in makefiles or built into the VC project system, reuseable tasks for native code tools just like we have today for managed code, changing the VS project system for VC projects to sit on top of MSBuild format projects and build process, and replacing use of vcbuild.exe with msbuild.exe.
3) Support for other Microsoft project types that aren't yet in MSBuild format: Deployment/MSI (.vdproj), SQL Reporting (.rptproj), Biztalk (.btproj), Speech server (.prproj) etc -- whether currently supported by a VS project system or not. This is essentially a process of internal evangelization and encouragement for us.
4) Conversion of Visual Studio solution files (.sln files) and their (rudimentary) build process to MSBuild format and the VS support for reading and writing these, opening the way to create a targets file useful for traversing a tree of projects, and to let VS cleanly support n-level project hierarchies.
5) Extensible up-to-date checking: a way to plug in up-to-date checker extensions that you could use on selected Targets as an alternative to the simple timestamp checking you are currently restricted to. Perhaps including a ready-made extension that would by some means automatically support transitive dependencies - header files are an example of these; or to compare public interfaces for significant changes.
6) Distributed Build. (Like multiprocessor build we are now shipping, but building spread over a set of machines that you have pre-provisioned; possibly opening the way for future Team Build support for it too.)
7) Extensible reuseable inline tasks. This means the ability to create extensions that consume the language or description format of your choice and to create a task that you could use without explicit compilation or deployment. For example, a Powershell extension that you could use to create tasks implemented in Powershell. Think of putting script underneath a <UsingTask> element. These inline tasks would be easy to create and share online. Might include ready-made extensions for Powershell, and/or a data-description format for tool switches, so you could quickly create a task wrapping a command line tool without any compilation.
8) Typing and scoping for items and properties. For example, declaring an item to contain a path; letting a property fall out of scope at the end of a target.
9) Extensible functions. Today we have only 'exists(..)' and it's stepchild 'hastrailingslash(...)'. This would be an extension allowing new functions to be created for use in conditional expressions, and possibly elsewhere, and some functions like perhaps combinepath($(root),$(file)). Perhaps more built-in metadata to go along with %(Filename) and such.
11) An MSBuild debugger with full Visual Studio support for stepping, inspecting locals, and breakpoints. Today you have to use <Message> tasks and gaze at diagnostic logging output.
12) Visualization for project and target dependencies, mining of what files are consumed by what projects, impact analysis for changes to particular files, possibly leading to support for build refactoring at the project/tree level. This is essentially richer logging and datamining and a high level on a huge source tree.
So now here's the poll. If you had only $100 to spend, how would you distribute it amongst them?
Dan
(Edit: gave Distributed build a unique number :-) )
