MSBuild Team Blog : Tools

More tools...

msbuild — Mon, 03 Dec 2007 21:00:00 GMT

Two new MSBuild community tools to check out!

Eugene from Attrice has blogged about the Visualization support in the new edition of MSBuild SideKick. (There's also another pretty visualizer on CodePlex.)

Partho pointed me at a debugger he's created. It's on CodePlex too, which means you can help improve it. It runs as a logger, taking advantage of the rich event information that loggers receive, and the fact that loggers currently run synchronously with the build. (This will likely change in future versions of MSBuild.) Debuggers built on the logging infrastructure are about as good as you can get until we have debugger support built into MSBuild - but for many people that can be a lot better than no debugger.

Nice work.

Dan

What are Targets, Tasks, and Tools?

msbuild — Wed, 14 Nov 2007 23:35:00 GMT

I've heard these confused in the context of MSBuild, so let's talk a little about what they are:

* A TARGET is a grouping of tasks (often 1) designed to do a particular job. For example, a Link target would be designed to produce a final binary from object files. Targets can declare other targets that they depend on, and MSBuild will make sure those are run first. At present targets are the unit of incremental build: declaring Inputs and Outputs on a target will cause MSBuild to compare their timestamps and skip the target if the inputs are up to date. Because a target is the unit of build, it is the entity that other parts of the build depend on or invoke (via CallTarget or the MSBuild task from another project). The implementation of a target can be modified later, so long as it's "contract" ("consume X and Y properties and list of object files O to produce binary Z") is preserved. A future version will likely have an extensibility model for up-to-date checking, and that will likely plug in at the target level. Once a target has run once in the context of a project, global properties, toolsversion, and build, it will be immediately skipped next time it is invoked, without even checking timestamps. When you write a target, always check that it skips properly in the incremental build case. MSBuild logs information about targets during the build, and any extra logging you want has to happen from a task, especially the <Message>, <Warning>, and <Error> tasks. Targets can be batched, although this is rarely done.

A TASK is a reuseable implementation of some build action. In this case the only task in the Link target would likely be the task named Link. It is fed parameters, including the files to link, does the link, and the build proceeds. At present tasks must be .NET assemblies deriving from the interface Microsoft.Build.Framework.ITask. Tasks can consume and emit items and properties. By design, they have no other insight into the state of the build. They should not discover files on disk - this makes them opaque and less reuseable. PropertyGroup and ItemGroup inside targets can be thought of as tasks, but they have special syntax and powers. If your target is starting to get too "clever", write a task. We hear loud and clear that not everybody wants to write and compile code to create a task, and we'll address this future. Tasks can be batched, and this is commonly done either to force a task to run once for each source file (something like Sources="'%(Compile.Identity)'") or to filter out certain input files, by filtering in the condition on metadata on source items.

A TOOL is an implementation detail of some tasks. A Link task may happen to currently wrap a tool named link.exe and it may happen that the parameters on this Link task pretty much wrap 1:1 with the command line switches on this tool named link.exe. However those are implementation details. One day the link task could be modified to load a "link.dll". Or the owners of link.exe could flip the /clr switch in order to implement ITask themselves. Tasks that wrap tools will want to derive from the ready-made abstract class named Microsoft.Build.Utilities.ToolTask, which provides much of the functionality they will need. Many tasks do not wrap tools. [ Aside: For example, during development of MSBuild v1, we initially implemented resource generation by wrapping resgen.exe. However a key scenario was to build a typical VB or C# project without even having the .NET SDK installed, but resgen.exe did not ship in the .NET Framework and we couldn't persuade them to move it. So we wrote our own resource generation task in code, called GenerateResource. (Resgen.exe is just a thin wrapper over BCL APIs anyway.) A similar situation exists for al.exe, but we did not write a task to do that without the tool: al.exe is some pretty hairy code. This is why you need VS or the .NET SDK installed to build projects with satellite assemblies. But I digress.]

Unlike makefiles, the inputs and outputs on a Target are not necessarily what the “build action”, ie the task, operates on. The task operates only on the parameters it is given. Typically however the Inputs on the Target would be among the inputs passed to the task, but this is not necessarily true. For example the Link target’s Inputs might include $(MSBuildProjectFullPath), so that the target is forced to run if the project file itself has been edited - yet the Link task would not be passed the project file.

Dan

Beta 2 of the MSBuild Toolkit for .NET Framework v1.1 is Out!

msbuild — Sat, 25 Mar 2006 02:56:00 GMT

Craig just announced over on his blog that Beta 2 is available. New features in this release include:

Support for the ResolveComReference task!
Redirecting the LC task to target .NET 1.1
Defining a FX1_1 constant to let you exclude .NET 2.0 specific code
Providing a BaseFX1_1OutputPath property for replacing the default 'bin\FX1_1' base path.

Enjoy!

[ Author: Neil Enns ]

MSBuild Extras - Toolkit for .NET 1.1 (beta 1) is Out!

msbuild — Sat, 11 Feb 2006 00:06:00 GMT

The folks in our customer experience team have posted the first public beta of MSBuild Extras - Toolkit for .NET 1.1 (the project formerly known as "MSBee"). If you're interested in building .NET 1.1 applications using MSBuild this is the tool for you! Give it a spin and be sure to send them feedback.

[ Author: Neil Enns ]

AssemblyInfoTask Version 1.0.51130.0 is now available!

msbuild — Wed, 07 Dec 2005 22:41:00 GMT

I just posted an updated version of the AssemblyInfoTask and its source code to our GotDotNet user sample page. This new release fixes support for Visual J# projects, includes an updated installer that installs the task into the Global Assembly Cache, support for installing as a non-administrator, a few bug fixes to the help documentation, and full code-signing and strong name for the compiled assembly.

Enjoy!

[ Author: Neil Enns ]

How To: Update Assembly Version Numbers with MSBuild

msbuild — Sat, 12 Nov 2005 01:38:00 GMT

UPDATE: For information on the "Y7K" or "2007" issue, see our new blog entry.

One of our most frequently asked questions is: "How do update my assembly version numbers at build time?". Unfortunately our answer has been "you can't". Until today, that is.

I just posted a new task, AssemblyInfoTask, at GotDotNet. It provides complete support for a wide variety of version number styles, from a fixed number to numbers that change daily to numbers that increment on every build. It also supports setting other properties such as AssemblyTitle, AssemblyCopyright, etc.

Even better, we've posted the complete source code, unit tests (that run in Visual Studio Team System), and raw documentation for the task under the new Microsoft Community License. Try not to laugh too hard when you look at the code. Remember, I don't write code for a living, I'm one of those touchy-feely Program Manager people :)

If all you want to do is get Visual Studio-style build numbers, of the form 1.0.yyMMdd.revision (for example, 1.0.51111.02 for the third build today), then you simply add the following line to your project file after any existing <Imports>:

If anyone has trouble getting it to work, has comments, questions, or suggestions, please send 'em our way to msbuild@microsoft.com or post to our forum.Enjoy!

[ Author: Neil Enns ]

Automating the Creation of Custom Tasks with TaskGenerator

msbuild — Wed, 26 Oct 2005 01:30:00 GMT

It's pretty common to have a bunch of existing tools to include in a build process, and it can be rather a pain to hand-write classes to wrap each of them as proper MSBuild tasks. As we worked on converting the Visual Studio source code to build with MSBuild we realised it would be super helpful to have some sort of tool to assist in writing those wrapper tasks.

As good fortune would have it we had an awesome intern working in the MSBuild team last summer, and she wrote a nifty application to help with this process. The application is called TaskGenerator, and it lets you describe a command-line tool with XML, then it'll generate the appropriate MSBuild task source code that wraps the tool. Here's an example of what the XML for regsvr32.exe looks like:

When you run this through the tool you get a registerdll.cs file that implements a ToolTask, and can be compiled into a custom task.

We were hoping that this tool would be our first post to the new GotDotNet site, but they've had a few complications during their upgrade. Rather than wait, we're making it available now as a technology preview [download here]. We're using the new Microsoft Community License for the release, and while there's no source code for the tool at the moment we will change that sometime during November. This release was built against build 2.0.50727 of the .NET Framework, and will not work against earlier releases.

Note that this release is a technology preview. As with all MSBuild projects it was built using test-driven development and unit tests. However, it has not undergone a complete verification by our test team. To the best of our knowledge it is stable, but as you play with it you may find the occasional bug, area where the XML schema is limiting, or errors in the documentation. In addition, since it is a technology preview, there is no guarantee that future versions will honour XML used by this release of the tool. It is highly likely that we will modify the XML schema based on feedback from customers, and the next release of the tool will not include any code for backwards compatibility. Any XML files you create with this technology preview will only ever work with this release of the tool, build 1.0.0.0.

Enjoy, and as always send feedback to msbuild@microsoft.com!

[ Author: Neil Enns ]