jeffcal's blogland : MSBuild

building everett apps with msbuild

jeffcal — Thu, 16 Dec 2004 19:54:00 GMT

check out this post from mark michaelis, where he describes the work he did to build everett apps with msbuild.

many customers are tackling this problem and it's encouraging to see them meet it with success.

jeff.

early msbuild documentation

jeffcal — Mon, 06 Dec 2004 22:21:00 GMT

there's an msbuild wiki over at channel 9, and there's a good preview of the msbuild documentation over at msdn:

http://msdn2.microsoft.com/library/0k6kkbsd.aspx

as always, feedback is welcome (and encouraged).

jeff.

important: we need your feedback

jeffcal — Wed, 06 Oct 2004 17:35:00 GMT

lately it seems like i've been pointing a lot at other content rather than providing too much of my own; i'll continue that trend today with the promise to change it tomorrow.

but this one's particularly important: alex kipman, the msbuild program manager, has posted an important call for input from the community regarding how msbuild ships. please go share your opinion with him, we want to hear from each of you.

jeff.

everyone wants it...

jeffcal — Sun, 03 Oct 2004 21:43:00 GMT

easily one of the top requests we get from customers is support for targeting msbuild to the everett (1.1) framework. well jomo's recently posted an instructional explanation of how one might approach this problem. and now robert mclaws has taken that and run with it to try to make it more versatile... frankly, i'm excited to see customers already using our product to accomplish their work even when we can't explicitly support it. i think that speaks volumes about both the ingenuity of our customers and the versatility of our product.

jeff.

new msbuild wiki

jeffcal — Wed, 29 Sep 2004 21:25:00 GMT

over at the nunitaddin blog, there's a post announcing a new msbuild wiki maintained by external customers and developers. i'm sure you'll find a few of the msbuild team members contributing there too. please share any interesting resources/tips with others!

keep your eyes open for the official msbuild site/wiki coming soon.

jeff.

the sequel

jeffcal — Fri, 17 Sep 2004 18:19:00 GMT

once again, the msbuild team will be packing our bags and heading to a secret location to fix as many bugs as possible. hopefully it will be as successful as last time. unfortunately, we'll be missing some of the helping hands we had last time, but maybe we can pick up a free agent or two. either way, i'll keep you posted.

jeff.

debugging a build process - what works for you?

jeffcal — Fri, 03 Sep 2004 01:33:00 GMT

building a large piece of software can take a very long time. combine the times to compile and link with syncing sources, running test suites and unit tests, mailing a build report, copying the bins over the network, etc. and you have a process that can easily take hours. what happens when some step in this process fails?

i'm curious what those of you out there do.

how do you track the problem down? how do you correct it? how do you carry on with the build? do you rely solely on the build's logs? do they normally contain the information you're interested in? what information are you interested in? do you try to repro the problem? does dependency analysis save you the trouble of again running those parts of the build which were successful?

let me know :)

jeff.

reducing our bug backlog, or why "The MSBuild team rocks!!!"

jeffcal — Tue, 03 Aug 2004 00:29:00 GMT

it's been nearly eight weeks since my last post, but i promise i've been doing something for you! and i can easily account for one of the eight with an explanation of what my whole team did just last week.

recently a couple teammates were trying to think about what issues they were concerned about resolving before we could ship a great first version of MSBuild. they weren't talking about specific bugs or work items, but more generally about the mileage between that day and the day we ship, and how we can make sure we cover that distance. reducing our bug count came up for several reasons:

1. lately the count has been pretty flat. in other words, the number of bugs we resolve (fixed, doesn't repro, by design, ...) has been roughly the same as the number of bugs people are opening.

2. devs have lots of other work to do aside from fixing bugs.

3. some important but lower priority bugs were starting to look ripe for kicking down to version 2 (which makes no one happy).

4. fixing bugs seemed like something program managers and testers could help the developers with. and if we (the testers) were fixing bugs, presumably we wouldn't be finding them....more on that later.

a plan was set: for one week, the MSBuild team - developers, program managers, and testers - would all sit in the same conference room in an unusual building (read: far away from the people most likely to distract us) while fixing MSBuild bugs on our laptops. we wouldn't answer mail, wouldn't have phones, wouldn't go to meetings, and wouldn't work on anything other than fixing bugs. period. there were obviously some initial concerns about this: who would take care of our dogfooders? which bugs would we fix? could testers and program managers even fix bugs? what would make this a success? we came up with the answers we could but otherwise dove straight in hoping we'd accomplish something. at the very least, this experiment would be a week of doing something different and exciting, and there was potential for significant results.

let's start with what we were facing: at 12:01 AM on monday the 26th, there were 437 bugs without an available fix open against MSBuild. to put this number in perspective a bit: the bug count sat just above 300 from early february to late april, before steadily rising to just under 450 from late april to mid june. for the next six weeks, we hovered there at about the same spot. over the past six months, our bug count had increased by about 50%.

so there was a lot of work to do. the first obstacle: the conference room we'd reserved as our temporary home wasn't on any building maps and the receptionist had no idea where it was. we feared the mysterious room was a black hole, but a recent admission by steven hawking allayed those fears. once we'd all discovered the room, we fixed bugs. and read bugs we thought maybe we could fix. and fixed bugs. and read the same bugs we thought we could fix before but still didn't know how to fix. and fixed bugs. and talked about fixing bugs. and fixed bugs. we also ate a few dozen krispy kreme donuts, a lot of bagels and cream cheese, sumedh's banana, and even some pizza with indian food on top of it.

by the end of the week, we'd all learned a lot and several of us had new nicknames (not all of which were desirable). the developers were especially patient while helping the others out with everything from process details to code reviews to discussions of potential fixes. the testers actually did open nine new bugs during the week. eight of those were opened by our resident star tester dan, who finds bugs while putting his shoes on. i personally learned a ton about our codebase and debugged more managed->unmanaged transitions than the mariners after piniella's been tossed.

here's the details though:

Monday 12:01 AM: 437 unfixed bugs
Friday 11:59 AM: 264 unfixed bugs

frankly, we'd hoped to reduce the count by about 100 for the week, or about 2/person/day. in fact, we were able to reduce the count by about 3.5/person/day, even including the 16 new bugs opened over the week. these numbers deserve a few qualifications: our goal was simply to reduce the bug count by as much as possible, so many of us chose the easiest bugs to fix rather than the most important bugs; we don't yet know how many new bugs we introduced, or how the regression rate compares to the usual scenario when only developers are working on the codebase; some of us actually did read our mail during the week (and deserve slaps on the wrists!). but no matter the qualifications, it was a great success and discussions are already underway about when we should do it again. it'd be nice if our work will encourage other teams to try similar experiments.

hopefully MSBuild will be a better product when we ship it because of this experiment; i personally think it will.

jeff.

ps - i'll write sooner next time!

[Edit: removed link]

dependency analysis in msbuild

jeffcal — Sat, 29 May 2004 04:58:00 GMT

when people first get their hands on msbuild, especially those familiar with other build systems, one of the first things they notice is msbuild's dependency analysis mechanism. the msbuild engine offers basic dependency checking based on explicitly declared target inputs and outputs. currently, the analysis is pretty simple, although helpful in many cases: msbuild checks output timestamps and input timestamps and if some of the outputs are older than some of the inputs (i'm glossing over details here), the engine will execute the target.

users of other build systems have pointed out a fairly obvious limitation of this mechanism: dependency analysis often must be more complex than timestamp checking. i couldn't agree more.

however, this limitation of msbuild's dependency checking mechanism should not be mistaken for a limitation of msbuild itself. reason: the author of a project file is not strictly limited to using the msbuild engine for her dependency checking, nor is she required to allow the engine to perform any dependency analysis at all! furthermore, and most importantly, this mechanism (whether opting in or out) in no way precludes tasks from performing their own dependency analysis at any level of precision they'd like, exactly as many (N)Ant tasks do today. the resgen task our team has developed does just this. we found in some cases simple filestamp checking would lead to skipped calls to resgen when they were actually required, so we simply moved the dependency analysis from the target level to the task level and voila! problem solved.

all this still leaves room for the engine to do more complex analysis while still exposing more control over it to the user, and we're thinking hard about how to make that happen.

jeff.

coming soon: wix tasks for msbuild

jeffcal — Fri, 28 May 2004 21:44:00 GMT

hey y'all, and sorry i haven't written in a couple of weeks. we're working hard to ship our first beta of msbuild right now so my blog unfortunately sat down with a hefty piece of neglect pie. but i'm back now (to the three of you who actually read this; well, two of you if i can't count my mother).

as many of you know by now, microsoft has dipped its toes into the open source waters by opening up the wix project to the community. a wise dev on my team pointed out that the wix open source announcement was followed almost immediately by a few requests for msbuild tasks which wrapped the core wix tools. so on my backburner for the past month has been figuring out how to make sure this happens. i started by reading a little more about wix and thinking about how it should fit into the build process, and finally before typing any code decided to ask if anyone else at microsoft had endeavored to create such tasks. i was silly to ask “if” rather than “who” because within about twenty minutes i'd learned that one of our top dogfooders (in another state no less) had already authored working versions of the tasks! so we're going to work with the wix guys to make sure these useful tasks see the light of day outside microsoft too...

in other task development news, i recently stumbled across some frustrating fusion loading issues, presented to me in the concise, if not elegant, form of HRESULT 0x80131040. i haven't quite tracked down exactly what the problem is but i'm certainly having fun trying.

have a good memorial day weekend. i'll be watching “fishing with john“ and a couple of sergio leone/clint eastwood westerns...

jeff.

today on dr. phil: resolving conflict among dependencies

jeffcal — Tue, 11 May 2004 21:18:00 GMT

Since joining the MSBuild team, I've learned more than I ever thought imaginable about .NET references and dependencies, largely because I'm responsible for testing the ResolveAssemblyReference task we'll be shipping as part of our task library. Between my testing of that task and the patient guidance of one of our developers, I've learned about many of the intricate details of reference resolution. It's amazing to me how much this thing can do, and how many scenarios rely on this little (ok, well, not so little) task in one way or another.

One cool new feature in Whidbey is at build time the ResolveAssemblyReference task can automatically choose the latest versions of your references and dependencies. So if I have some cool MusicWidget in my app which depends on Version 1.0 of WidgetBackend.dll but my MovieWidget depends on Version 2.0 of WidgetBackend.dll, the ResolveAssemblyReference task can ensure my app is compiled with Version 2.0. In most cases, when the owners of WidgetBackend.dll are playing nicely and maintaining backwards compatibility, this is exactly what I'd want, but I'd rather not have to worry about the details of which versions of support files my widgets are using. I just want to use my widgets! Of course, there will still be cases when for one reason or another I'm not prepared to migrate to Version 2.0, and I'll be able to direct the ResolveAssemblyReference task to still use the old version if so.

Similarly, 99.99% of apps written against version 1.1 of the .NET Framework will depend on some Framework assembly such as System.dll or System.Data.dll. When you install the Whidbey .NET Framework and rebuild your apps, the ResolveAssemblyReference task will see your Whidbey .NET Framework and pick those versions of System.dll and System.Data.dll for the compiler to use. And you won't even have to so much as browse to a file on disk. Of course the same provision applies here for those who aren't ready to move all of their dependencies to Whidbey: you can just tell MSBuild to use the specific version you've been using all along.

Hopefully the work we're doing in this area will give developers confidence in choosing the right solutions for their problems rather than worrying about what new problems may be introduced by their solutions...

jeff.

tasks in msbuild and nant

jeffcal — Tue, 04 May 2004 18:34:00 GMT

this weekend, ted neward wrote some dispirited comments about microsoft's decision to release msbuild in light of nant's community acceptance. now his point is larger than just the decision to release msbuild, and dare has commented on the larger issue here. but the quandary he describes is sure to be a common one faced by many nant users. specifically, he writes:

So if I need a custom build task to do ASP.NET deployment, do I build a NAnt task knowing its lifetime is probably scoped to this Whidbey beta cycle? Or do I build a MSBuild task knowing that it'll probably be two years before it's really useful, and that it's entirely likely that I'll have to rewrite it at least once or twice in the meantime?

i expect task authors to ask exactly these questions and frankly i think it's in the interest of both nant and msbuild to make sure we're providing solid answers. but i thought to myself: “there's a way to resolve this easily: write a task that works in nant and msbuild.” the idea isn't far fetched, as the interfaces are quite similar. to my surprise, i found john lam already did this for an ftp task and noted the following:

[N]Ant tasks can easily port to MSBuild and vice-versa. Today I just built an FTP task that works in both MSBuild and NAnt.

to be sure, there is a bit of maintenance involved in supporting both the nant and msbuild interfaces, but in general this should work without too much effort. have any others out there tried this? are you interested in seeing me write a task that works in both nant and msbuild?

jeff.

writing a build logger: all the news fit to print

jeffcal — Tue, 27 Apr 2004 21:34:00 GMT

We have an internal discussion list for users of MSBuild to share their thoughts and experiences with each other and bring questions they have about MSBuild. Last week, one of our internal users wrote the list to talk about some performance issues he was noticing as his build projects grew larger and larger, but he needed to extract timing info for the build in order to drill down on the problem. MSBuild won't give you this for free, but it offers an even better solution: loggers. By writing a custom logger, which is really just a .NET class implementing a public MSBuild interface, users can receive the events they're interested in receiving and record them in the ways they're interested in viewing them.

So I set out to write a logger which computes and records timing info for each segment of the build. I pasted the outcome of this effort below. Essentially I started off maintaining an open xml document and writing the data to the file as it became available (i.e., when the MSBuild engine fired a StatusEvent). This was quite efficient but the logs were just flat out ugly because every single “build“ element had to have a child “time“ element. So at the expense of my RAM, I cached all of the events for the entire build and processed the data once the build was complete. Here's what I came up with:

using System; using System.Xml; using System.Collections; using Microsoft.Build.Framework; namespace BuildTimer { /// <summary> /// This logger computes and records the timing info for each interesting segment /// of the build, i.e., the time spent in each task, target, and project along /// with the total time for the entire build. /// </summary> public class BuildTimer : ILogger { private Queue events; //where we cache all of the events private string parameters; //storage for Parameters property private LoggerVerbosity verbosity; //storage for Verbosity property /// <summary> /// From ILogger. This value is specified on the command line along with the logger spec. /// Should be a valid path to a writable location or the logger will throw during Shutdown() /// when it tries to write the XML log. /// </summary> /// <value>The value the engine provided from the logger's command line spec.</value> public string Parameters { set { parameters = value; } get { return parameters; } } /// <summary> /// From ILogger. This value is either specified on the command line, or the engine will /// set it to the default value LoggerVerbosity.Normal. All loggers receive the same value /// for a particular build and it is their choice/responsibility to use Verbosity as they /// see fit. In particular, the set of events a logger receives from the engine is the /// same no matter what Verbosity is specified. /// </summary> /// <value>The value specified on the command line, or the default if none was specified.</value> public LoggerVerbosity Verbosity { set { verbosity = value; } get { return verbosity; } } /// <summary> /// From ILogger. This method is called by the engine before any events are fired /// so the logger can register for events it's interested in. In our case, we're /// only interested in StatusEvents. /// </summary> /// <param name="eventSource">IEventSource provided by the engine for event registration.</param> public void Initialize(IEventSource eventSource) { events = new Queue(); eventSource.StatusEvent += new BuildEventHandler(StatusHandler); //register for StatusEvents } /// <summary> /// From ILogger. This method is called by the engine once all events have been fired. /// The logger should perform any final work here. We create an Xml file and log all /// event info including times to the file. /// </summary> public void Shutdown() { XmlTextWriter log = new XmlTextWriter(Parameters, System.Text.Encoding.Unicode); log.Formatting = Formatting.Indented; log.IndentChar = '\t'; Stack timingInfo = ComputeTimingInfo(); //contains one BuildInterval per Started/Finished pair while (events.Count > 0) { BuildStatusEventArgs statusEvent = (BuildStatusEventArgs)events.Dequeue(); if (!IsStartedStage(statusEvent.Stage)) //finish event - close the element and carry on { log.WriteEndElement(); continue; } log.WriteStartElement(GetStageElementName(statusEvent.Stage)); if (statusEvent.Stage != BuildStage.BuildStarted) //StageName is blank for BuildStarted { log.WriteAttributeString("Name", statusEvent.StageName); } BuildInterval interval = (BuildInterval) timingInfo.Pop(); log.WriteAttributeString("Time", (interval.Finish - interval.Start).ToString()); if (Verbosity == LoggerVerbosity.Detailed || Verbosity == LoggerVerbosity.Diagnostic) { log.WriteAttributeString("Message", statusEvent.Message); log.WriteAttributeString("Start", interval.Start.ToString()); log.WriteAttributeString("Finish", interval.Finish.ToString()); } } log.Close(); } /// <summary> /// The registered BuildEventHandler which will receive all StatusEvents /// from the engine. We simply cache the event and save the work for /// Shutdown() when we know we've received all events. /// </summary> /// <param name="sender">Ignored.</param> /// <param name="args">BuildStatusEventArgs object we cache for later use.</param> public void StatusHandler(object sender, BuildEventArgs args) { events.Enqueue(args); } /// <summary> /// Walks the event cache and populates a stack with BuildIntervals for each /// Started/Finished pair of StatusEvents. /// </summary> private Stack ComputeTimingInfo() { Stack remaining = new Stack(events); //the constructor effectively reverses the order we'll see events Stack finishedEvents = new Stack(); Stack timingInfo = new Stack(); while (remaining.Count > 0) { BuildStatusEventArgs currentEvent = (BuildStatusEventArgs) remaining.Pop(); if (IsStartedStage(currentEvent.Stage)) { BuildInterval interval = new BuildInterval(); interval.Start = currentEvent.TimeStamp; interval.Finish = ((BuildStatusEventArgs)finishedEvents.Pop()).TimeStamp; timingInfo.Push(interval); } else { finishedEvents.Push(currentEvent); } } return timingInfo; } /// <summary> /// Simple test to see if a particular BuildStage was one of the "Started" stages. /// </summary> /// <param name="stage">The stage to be checked.</param> private bool IsStartedStage(BuildStage stage) { return ((stage == BuildStage.TaskStarted) || (stage == BuildStage.TargetStarted) || (stage == BuildStage.ProjectStarted) || (stage == BuildStage.BuildStarted)); } /// <summary> /// This exists purely for performance, to avoid repeated calls of the form /// /// stage.ToString().Replace("Started", "") /// </summary> /// <param name="stage">The stage we're getting the element name for.</param> private string GetStageElementName(BuildStage stage) { string name = String.Empty; switch (stage) { case BuildStage.TaskStarted: name = "Task"; break; case BuildStage.TargetStarted: name = "Target"; break; case BuildStage.ProjectStarted: name = "Project"; break; case BuildStage.BuildStarted: name = "Build"; break; } return name; } } /// <summary> /// Use this to conveniently pair the timing info for a Started/Finished event pair /// so we can later output it to the log. /// </summary> internal struct BuildInterval { public DateTime Start; public DateTime Finish; } }

I like the output of this logger much better now even if it chews up memory on order of the number of status events (I've always been a sucker for form over function). With a sufficiently large project, it'd probably be necessary to go back to the uglier logs or risk the logger becoming its own bottleneck in the build's perf. Finally, here's an example of the logger's output when logging a build of itself with default verbosity:

With a command line switch, I can increase the verbosity to include the Message, Start time, and Finish time for each build segment.

jeff.

the meanderings of an msbuild tester

jeffcal — Thu, 22 Apr 2004 18:14:00 GMT

hola. and welcome to my flashy new blog. my name's jeff callahan and i test microsoft's new build system, msbuild. i've been a full time tester for msbuild almost a year now, but during various breaks from college i also worked as an intern or contractor on projects under visual basic, exchange server, and visual c++. but none of those experiences were nearly as cool as my stint on msbuild has been thus far.

why is that? we're working on an exciting project that i think customers are really going to like. i'm helping ship the first version of a product and i get to see the important decisions we must make to get it right and out the door. but most importantly i work with a group of really smart folks who teach me things every day.

so hopefully i can give a bit of insight into how this project msbuild works, what sort of hard decisions we're making to get it shipped, and what cool things i'm learning from the people i work with.

make yourself at home, and don't hesitate to speak up.

jeffcal.