AKipman's MSBuild blog

Currently there is a proposal on the table to move MSBuild out of the .NET redistributable and ship it instead as part of a lightweight developer tools redist (subset of the .NET SDK). This would mean that your dependency on MSBuild has the requirement of installing an additional redistributable before MSBuild can run.

Before we make any decisions of this magnitude, we need to better understand how this decision would impact you and your decision to adopt MSBuild. We would like to assess a few things:

• What key requirements would a tools redist have to meet in order to be viable for your needs, e.g. how small, distribution channels, available to repackage/refactor for your needs, etc.?
• Assuming a redist met the requirements, there would be an additional redist step in your distribution story. Does that threaten or completely break any of your key scenarios or value propositions? Which ones?
• What kinds of innovations do you expect in future versions of MSBuild? Are you willing to accept a dependency on a future refresh of the redist in order to utilize those innovations?

I would love to hear your feedback! If e-mail is not a convenient medium to give us that feedback, let me know and I'll gladly schedule a quick 1:1 phone meeting.

Thanks,
Alex Kipman (AKipman@microsoft.com)  

Yesterday Josh blogged about the MSBuild status which I posted earlier this week.  His blog entry generated an interesting conversation which I felt I should comment on (hence this blog entry).  The basic pushback was:

Status of internal projects may represent competitive information, may have legal consequences to contracts, expose security bugs before the fixes are deployed, and may represent excessive transparency. I work on something inside MSFT that would sink existing product lines. Should i post our build status information? <absolutely not>
Next they'll want us to start publishing checkin mail?

Interestingly enough I have heard this pushback three distinct times this week, and with exception of the above none were related to my little blog.  The first time was when I read next week's business week article titled “Blogging with the Boss’s Blessing” which dives straight into this issue.  I read the article because it features Sara Ford (who works a few doors down from me), and because we are all very proud of her :).   The second time was in an unrelated meeting I was having with Lutz, Rob and company.  There we were basically discussing how it only takes one irresponsible employee one blog entry to undo years of messaging and position from marketing.

All three conversations boil down to the same question:  “when is transparency detrimental to a company”!

In my utopical world, I think the answer is very simply *NEVER*; as long as people use their common sense.  People *should not* blog about things that they don't own.  For example, I shouldn't sit here blogging about the cool demo I got of XYZ yesterday, even though it was the coolest thing I've ever seen, since I don't know how much of XYZ is public yet, I mean I have an idea and I think it is public... but I just don't know for sure. People *should not* just copy and paste internal things into the blog.  For example, I shouldn't just copy and paste my status as is externally (and btw I haven't).  Ultimately as Scoble says:

Before posting an entry in his personal weblog, Robert Scoble always pauses and considers how he would justify its contents to three people: his boss, his wife and Steve Ballmer. 

Again just use common sense folks, and blogging is a win win win proposition.  I won't be blogging about the status of converting the Windows Kernel to an MSBuild task.  I won't be blogging about the status of adding the hyperspace feature to the MSBuild engine.  I won't be blogging about things that don't make sense to be blogged about. 

Lastly *I think we should be posting check-in mails* and I will be doing so in the future.  I already do so internally every time we post an LKG (last known good) to our internal partners, and I will be posting the same list externally when we ship the beta of Whidbey.  I think this is the single most valuable information a developer can have when he/she are trying to figure out what the delta is since the last technology preview, alpha etc.  What has changed?  What are the breaking changes?  What are the new features I should be pounding on?  I strongly recommend this to any feature team, as this is one piece of information our customers have to *discover* by trial and error, and this would give them a clear roadmap of a) what to look forward to, b) what to play with first and c) prepare them for what will break since the last time we did this. 

And now I'm late for going to work (Ori is going to kill me)... since I woke up to just read a bit and ended up blogging (damn this thing is addictive).  Cheers everyone... and happy blogging

I can't wait... are you packed yet?  For those that are going to be there, there will be cool MSBuild activities for you.  The roster includes two Hands on Labs and one breakout session.  They are:

DEV356 Visual Studio 2005 : Managing the Enterprise Build Process with MSBuild  
Thu, Jul 1 14:45 - 16:00 Room: TBD 
Alex Kipman 
Learn how the Visual Studio 2005 release of Visual Studio will radically improve the area of software development by introducing a new build engine called MSBuild. Key design goals for MSBuild include: delivering a file format that is well-documented and backed up by a published XML schema definition; making the MSBuild engine an integral part of the .NET Framework redistributable; allowing developers to customize, augment, or completely redefine the build process; and providing seamless integration with the Visual Studio 2005 IDE. 

DEVL56 MSBuild, The New Build System for Visual Studio 2005 and Longhorn  
Mon-Fri, Jul 1 08:30 - 19:30 Room: TBD   
Get an introduction to MSBuild, the new build system for Visual Studio 2005 and .NET development. MSBuild is a component included as part of the .NET Framework and has no dependencies on Visual Studio. See how it is fully functional on a machine that doesn't have Visual Studio installed. Learn how MSBuild's project file format is XML-based, and includes concepts like properties, items, targets, and tasks. Get details about the file format are included in the Appendix.  

DEVL21 Version Control and Team Development with Visual Studio .NET and Visual SourceSafe  
Mon-Fri, Jul 1 08:30 - 19:30 Room: TBD 
This lab focuses on Visual SourceSafe, Visual Studio .NET, and MSBuild -- the next generation build engine that delivers flexibility for the entire range of build scenarios, from single-user basics to complex build-lab scenarios. See how Visual SourceSafe 2005 and the new universal build engine, MSBuild, provide an unprecedented level of support for the build process and source control.  

I also get the chance to hook up with folks whom I've corresponded with in the past... I'm really exited about that!  I would also love to meet other people who are interested, curious or passionate about <InsertGooseBumps>*build*</InsertGooseBumps>.   If you are going to TechEd, want to talk build, don't be shy to send me e-mail and we'll set it up!

See you in Amsterdam!

Status... status and more status.  This is something new I'm trying, and I'd love to hear your feedback on the process.  As most people at Microsoft (heck probably anywhere), I have to send weekly status internally to my peers, the big cahunas and other interested parties.  My status covers MSBuild, and pretty much reports a pulse for the entire feature area.  What's Dev up to... what's QA up to... is the PM *still* slacking off (<-- don't answer that).   So if internal folks are generally interested in it... perhaps *you* are interested in it as well. 

So the question for you is:  Well are ya interested in it? 

I will attempt to post these on a regular basis, and through it, you can know what's up in MSBuild land.  Again we'll tweak the frequency and granularity of these as we go.  The more feedback you give... the better I'll be able to optimize this experience for you... Onto status then:

Performance

• MSBuild perf scenarios are ready to run as Pri1 performance tests in the pef lab.  Our current P1 scenarios consist of:
  • Small - Individual / Small feature team (eg MSBuild itself with ~10 leaf node projects)
  • Medium - Entire feature team (eg Visual Studio solution and project systems ~50 leaf node projects)
  • Large - Entire product unit (eg Visual Basic ~500 leaf nodes)
  • X-Large - Entire division at Microsoft (eg All of Visual Studio ~4500 leaf nodes)
• Work has started to integrate MSTV Server (~75 leaf projects) as one of our performance scenarios.  Based on this work we've been able to:
  • Isolate performance issues around our Resolve Assembly Reference (RAR) task. 
  • Improved overall load time by 10% (5 seconds).
• Recent perf numbers on MSBuild compared to Build.exe / nmake:
  • Build.exe / nmake⁵ building the MSBuild tree (1 CPU) - 55.25 seconds
  • MSBuild.exe building the MSBuild tree (1 CPU) - 36.60 seconds!!
• MSBuild peak size reduced from 55 megs to 15 megs.  Total allocations (ie GC pressure) went from 280 megs to 170 megs.  This ginormous improvement is mostly due to:
  • MSBuild now cache's imported project xml to prevent re-parsing
  • MSBuild now uses case insensitive hash keys to prevent storing upper case copy of all MSBuild property and item keys

So that concludes the status... you are now UP TO DATE <-- in msbuild speak that means you will be skipped next time we build you :) (ok dorky joke but I couldn't resist)

Useful?  More of it? Less of it?  Inquiring minds want to know :)

¹ Nightlies - we have ~2100 distinct automated tests for MSBuild.  Some more important than others.  Nightlies are some of the most fundamental tests we run.  As their name implies we run these on a daily (ahem nightly) basis and they are meant to test critical customer scenarios.  Breaking or regressing a nightly is really bad.  Nightlies are a great indicator of our overall product stability. 
² OGFs - Overall Good Feeling or Overall Goodness Factor (I can never remember).  A few times per milestone our awesome QA organization tests end-to-end scenarios (both manually as well as automated).  Based on the end-to-end experience they issue an OGF for the scenario.  The collection of these OGFs isused as an indicator of our overall product quality. Example of an OGF for MSBuild would be “Logger Initialization and Shutdown“
³ Handshakes - A collection of cohesive OGFs bubbles up into a Handshake.  If all OGFs within a handshake pass then a passing handshake is issued.  If at least one OGF does not meet expectations the entire Handshake fails.  An example of an MSBuild handshake would be “MSBuild Logging Handshake“ which would contain all MSBuild OGFs.
⁴ Flavored Project - these are project that build ontop of our core VB/C#/J# project systems and tend to optimize for a given technology.  Examples of these “flavored“ projects are the Smart Devices, VSTO or Yukon projects. 
⁵ Note - This is build.exe as we run it internally within our build labs.  Number may vary if you hand author your makefiles from scratch. 

_*_*_*_ Update: Swapped the 4th and 5th footnotes.  Thanks goes to David Cumps for pointing that out. _*_*_*_

Just kidding about the conquered part… but I figured this would get the blog read :-p.

Internally within Microsoft we usually send out these trip reports after we go to conferences (as I’m sure do most other corporations). Instead of writing the internal trip report and then eventually blogging about it (in a dehydrated form)… I decided to just blog about the trip and then point all the internal peeps to it. Basically my internal trip report mail will say: TechEd Trip report… read <insertBlogEntryLinkHere> for more details. So my apology if this is too lengthy for a blog post… I’m still adjusting. Any feedback is as always welcome…

Dan (DanMose@microsoft.com) and I went down to sunny San Diego on Sunday night. Unlike PDC 2003 the trip down to the conference was uneventful and aside from the fact that it wasn’t at all sunny (as a matter of fact even rainy Seattle was sunnier), the trip was fantastic. Our mission during the week was simple:

• Host an MSBuild Cabana session on Monday: DevC26
• Host an MSBuild Breakout session on Friday: Dev356
• Monitor the MSBuild HOL throughout the week: HolDev356
• Interact with as many customers / partners as we could during the rest of our time there
• And if time allowed… convince all attendees that the OS kernel should really be written as an MSBuild task :-p

Dan and I started by asking how many people had heard about, or used MSBuild in the past. Answer: 0 people

With that in mind we improv’ed MSBuild 101... what we are about, why we exist and why we think MSBuild will rock!! We advertised the Hands on Lab, our Friday breakout session and of course MSBuild@microsoft.com. There were about 40 people there, so this was interactive and we tried to field questions as we went. We went from there straight into ad hoc… question driven demo’s:

• We went through the process of creating a simple project file from scratch and explained the key concepts as he went through it.
• After that we took it from the other direction. What happens when you start from VS and want to extend it? We started from File-->new project… talked about our target files, wrote a simple task, registered it with MSBuild and *boom* you have fundamentally altered the Visual Studio build process
• A lot of Q&A later, even stepping into a logger to show how easy things are to debug the session was over. It was supposed to be a 1 hour cabana session and it turned out to be a 1:45 cabana session. We were the last ones of the day so people just hung around asking more questions. This was an absolute fantastic experience!

A few customer stories:

• A developer was sitting in the front seat and being very interactive. At the end they told us that they had written thousands of lines of code to do what we showed in just a few. I couldn't resist at this point and I said "well the theme of TechEd is *do more with less* muahahaha :)". Anyways they had some questions, which Dan and I answered. Why am I telling you this? Well they left still a bit incredulous, and went to try our Hands on labs. A few minutes later they come back and said "it works, it really really works" quickly followed by "Why haven't you shipped this two years ago, and does it support Visual Studio 2003" :-).
• "I went to the Cabana Session last night and it was fantastic. I am going to see if I can do that hands on lab soon."
• http://www.theserverside.net/news/thread.tss?thread_id=26153

JoeN talked about his breakout session here. I love that format and will be doing the same thing for the MSBuild breakout session. Stay tuned.

Without detailing the session itself post will contain all that, here is what *you* thought about it:

• Overall score: 7.46 / 9.00
• Evals submitted: 30
• Comments (in no particular order):
  • Technology overdrive - http://www.thespoke.net/MyBlog/Fai/MyBlog.aspx?entryid=21334
  • A little too much of a dog and pony show, I would have liked to learn more about the capabilities of MS build than doing several examples based on the same technology. The simple example would have been good enough, I felt you showed the smart phone for the sake of showing the smart phone..
  • After spending 35 minutes in this session I still don't have a clue on what this is all about. Instead of just hacking the configuration files of the MSBuild System, the key components of the system should be explaine
  • Did not care that you could type in the demo -- I think it was more important to show how easly and the very limited amount of code that was needed to do so
  • Don't worry about the missed demo. We (at least I) understand about how pre-beta code works
  • I liked your Win / ASP schema with pros and cons
  • It might pay to slow down a bit. Speed and broad coverage seemed less effective in this presentation
  • kudos on that build process went wrong but it sends out a SMS. cool
  • More about MSBuild in future conferences please
  • no one wants to watch people type xml.
  • You guys rocked! Very informative. I wish you were earlier in the week

There is clearly a ton of room for improvement, and based on this feedback some pretty major changes will happen before TechEd Europe. For those of you that filled surveys and left us your comments… THANK YOU. We appreciate the feedback and will do what we can to improve the MSBuild breakout session from it. Current set of changes we have in mind:

• Bring back architecture slide(s) that position MSBuild within the FX stack and Visual Studio
• Kill the demo1: file format in depth
• Rework demo’s 2 and 3 into cohesive story with a beginning, middle and end, rather than completely decoupled demo’s
• Talk about demo’s 2 and 3 in more detail now that demo 1 has been cut
• Do a better job at showing how this affects *my* team -  show integration with the Visual Studio Team System: a rolling build server interfacing with Team System source control, work item tracking, unit testing, and so on.
• S L O W D O W N

If you were there and have additional feedback… well you should have filled out an eval :-) j/k. Please send any additional feedback to: MSBuild@microsoft.com

We did not have a chance to monitor this as much as we would have liked. From the information we were able to get this was a pretty good lab. Overall we scored high, comments were positive and people seemed happy with it. From my perspective we hit a home run with the HOL, and I certainly plan on re-using it pretty much as is in future conferences. If you have any feedback on our HOL… send feedback to: MSBuild@microsoft.com. We will work to incorporate that feedback by a conference near you.

• Mangia, mangia with customers (Monday) – Dan sat with several customers from an ISV, some developers, and one IT person responsible for the build process and configuration management (names removed to protect the innocent :-)). Conversation centered on how painful it was to a) integrate build with source control, b) diagnose builds, and most of all to c) replicate a build when (not if) it needed to be reproduced later. Right now those customers mostly use batch files and ad-hoc scripts. Dan described how MSBuild could help them: a) download community-developed tasks to integrate with SourceSafe, b) use loggers to audit the build process, and c) use the Team System "big build in a box" to help reproduce builds. The customers were very excited and demonstrated interest to play with MSBuild. Lunch was left with MSBuild@microsoft.com as *the* email to be used if any of them wanted to share feedback (good, bad or indifferent)!
• Dinner with the To’s (Monday) – What a delightful part of my TechEd experience. Chris To was my intern last summer, and during that tour of duty he worked/owned many cool features of Whidbey including MSBuild VS Integration, Class View, Caller Callee and the Code Definition Window. He happens to be from near San Diego, so I had the pleasure to meet the parents :-). We had a lot to celebrate and catch up on!! After having been a really cool, top notch intern, Chris went back to school and on the side just that morning won 1^st place in the imagine cup tournament. Now he gets to go to Brazil to represent the North America and I’m sure win the world-wide competition there (official press release can be found here). Dinner was a blast, and getting a chance to share that evening with Chris and his parents was both an honor and delight. Couldn’t be more proud of you Chris… and I’m sure you and your team will do wonders in Brazil later this month!
• Meeting with Karin Becker (Tuesday) – This was our first experience with the "Rio" system. Karin works with Visual Studio Magazine and wanted to talk to us about upcoming publications of VS Magazine and how MSBuild could play a role in it. This meeting was definitely informative, and both Dan and I learnt a thing or two about how Articles are published etc.
• Dinner with John Lam (Tuesday) – Again a very delightful dinner. I had interacted with John at length before TechEd. John published our first external white paper on MSBuild and has generally been a great supporter / enthusiast. With this said, I had never met John face to face. We aimed to rectify that at TechEd… and the mission methinks was very much accomplished (you can read John’s perspective of dinner here). Dinner consisted of chatting about an assorted selection of technologies, and overall we just had a wonderful time. I must say it is sooo much better to meet friends face to face.
• Mangia, mangia with customers (Wednesday) – Dan sat with several customers and chatted about the Team System announcement. He answered loads of questions and talked about the fact that many of the tools were widely used internally, thus providing good scalable, proven and stable bits to start with. He said and I quote "I’m not just promoting it; I use many of these tools myself (really!)". The customers left energized and were now looking forward to going into Rick LaPlante’s session later that afternoon to find out more details.
• Meeting with Stephen Slocum (Thursday) – This was our second experience with the "Rio" system. Doug Neumann, friend from Team System, hooked us up. Stephen had come to our Cabana session and we had a fantastic conversation. We talked about targeting VS 2003 with MSBuild, more details about our C++ support, as well as generally picking his brain about his current build process etc. Learnt how he uses BuildIt.Net, we talked about his pains there and migration path to MSBuild. That conversation alone and the lessons learned are enough for me to generate many blog entries (which overtime I will :-)). *Stephen* if you are reading this… let us (MSBuild@microsoft.com) know how your research with MSBuild is going. We’d love to hear more and interact with you and your team as you go through that process.

• Rio – Dan and I thought this was a great idea, but overall not well implemented. We would have loved nothing more than back to back Rio meetings for the entire event. Unfortunately if you walked by the Rio room it was mostly empty. We don’t know what went wrong, but either customers didn’t know about Rio, or it wasn’t approachable to them. Personally we think that it was a combination of both. I’m a customer from organization X and I want to speak with build experts. I don’t know who they are, I don’t know the trendy name for their technology, I just know that they must be around somewhere. I should be able to just place a request to speak about Build… and Commnet should do the rest. TechEd’s implementation had an attendee requesting a meeting with person X from Microsoft. Now let’s face it… how many attendees knew that a) Dan and I know anything about build, b) that MSBuild is anywhere related to what they are looking for and c) that we actually shower regularly and indeed would *love* nothing more than talk to customers at TechEd? I’d wager 2 people knew that… and one of them works with us at Microsoft :-). What’s your feedback on it? Not that we have any control over it but we would certainly forward the feedback if you have any :-)! We would have loved to have had a chance to hear 1:1 from more people solving build problems in the real world, as it was our schedule wasn’t as full as it could have been.
• Cabana Sessions – Dan and I loved the Cabana session. It was great to interact with customers and do more of a Q&A session and some live demo’s to spice things up. I think the attendees also enjoyed this. The general constructive feedback from everyone (and we +2 that feedback) was: 1) it was really hard to hear since there was a ton of ambient noise and 2) it was really hard to see the plasma TVs due to lighting situation of that large room (too bright). I won’t rehash that feedback here, but we will say +2 to that. Great idea… lets just improve sound and video and this has the potential to be just great!

Wow, a bit larger than I had originally intended.  If you got this far... many thanks for putting up with me.  If you didn't... sorry about the long post. 

I want to take a bit of time up front to set expectations of what I plan on posting in the future.  I wanted to give a short explanation about the different categories I created.

Ultimately this blog is for *you*.  In that spirit I would love to hear back from *you* about the things I plan to blog about.  Do you find these categories interesting, useful?  Am I missing specific categories you’d like to see me blog about? 

Categories I plan to blog about: 

• Conferences – MSBuild goes to a lot of conferences.  We spend a lot of time preparing for it, we have a ball while at the conference, and we have post mortems after the conferences.  This category is aimed at sharing all of the above with *you*. 
• Fluff – This blog is about Whidbey and MSBuild.  Anything that doesn’t fit either of those categories goes into fluff.  My goal is to keep this category down to very few posts (even though it is 100% of the posts for now :() 
• MSBuild Automated – Over time I plan on having some statistical posts being made automatically on a given frequency.  Examples of posts in this category would be things like “how many projects within Microsoft build with MSBuild”.  Basically I would create a logger that at the end of build posts build statistics to a database.  I would then create a little daemon that on a given interval (say weekly) would poll the database and auto-post a blog entry with that information about projects within Microsoft that build with MSBuild.  Such posts will go under this category, so that you can easily filter them out if they are non-interesting to you.
• MSBuild Engine – Any post that talks about the semantic model of MSBuild will go under this category.  MSBuild object model issues and hosting of the MSBuild Engine will also go under this category
• MSBuild FAQ – There are certain questions I get asked over and over again.  So much so that I have pretty canned answers for them already.  I plan on posting such questions *and* answers under this category
• MSBuild File Format – Any posts that talk about the authoring of an MSBuild project will go under this category. 
• MSBuild Loggers – Any posts that talk about the authoring of an MSBuild logger, or anything that has to do with Events being passed through MSBuild will go under this category.
• MSBuild Status – Internally I send weekly status of MSBuild to the powers that be.  That status discusses things such as “what is the MSBuild team working on at the moment” and “what is the MSBuild team planning on working in the near future” etc.  I figure if this information is useful internally within Microsoft, it would also be useful externally to anyone interested in reading them.  I plan on posting said statuses to this blog category.
• MSBuild Tasks – Any posts that talk about the authoring of an MSBuild task, or anything that has to do with tasks, tasks registration, tasks consumption, tasks sharing etc will go under this category.
• MSBuild Visual Studio Integration – Any posts that talk about Visual Studio and how it integrates with MSBuild will go under this category
• Whidbey General – Any posts that are not MSBuild related, but that are talking about some cool technology in the Whidbey stack will go under this category. 

Welcome everyone!  Thank you so very much for taking time out of your busy schedules and gracing me with your presence!  I’m honored, I truly am.  I’m having flash backs to my senior year in high school when I walked into a new school, in a new country, barely speaking the native language.  So many people around who are just soooooo much cooler than me.  Will I fit in?  Will people want to read my blog?  Will they just write me off as another weirdo?  Will the cutie in my first period English class want to marry me

Anyways… I hope the contents of this blog are semi-useful and that every now and then I can provide you with some new learning experiences.  If I’m real lucky I’ll provoke some thought and stir some controversy on rare occasions.  If nothing else I can promise you some Kipmanisms¹ which I am told are extremely funny. 

I am genuinely thrilled, psyched and out of my shell proud about Whidbey, our new technology stack and of course I am beyond proud and excited about MSBuild.  I think Whidbey will be a fantastic release and if you haven’t played with it yet… well what are you waiting for!?

I must tell you, the first post of a blog is very hard.  I’ve been stewing over this blog post since last Thursday when John, Stefan and Chad started peer pressuring me to blog :).  Well gents, it worked, and here I am blogging for the first time.  John has been very supportive and kind through this, and I must thank him BIG time for helping me work up the courage to start this blog.  John as I’ve told you in person:  YOU ROCK!

What to say, how to best introduce myself to the world at large?  Who am I and where do I fit in the world of Microsoft?  Well my name is Alex Kipman and I was born in Brazil circa a quarter of a century ago.  I’m unabashedly proud of having the opportunity to work at Microsoft and have been doing this for almost three years now (my anniversary is coming up soon).  And yes if you must know Bill Gates *is* my hero!  

I have been fascinated by computer since my early years when I first fell in love with an Atari 2600 (note: my current mistress is an Xbox… and my live alias is ZEUS!).  I’m a strong believer in multiplier effects and have always preferred to affect the few that will in turn affect the masses.  For this reason it’s no wonder I gravitated to the developer division at Microsoft.  Here I can fulfill my dreams and work on my dream job, where day to day I help the smartest people on the planet enable developers worldwide to reach their full potential.  My thinking is simple; if we enable developers to imagine, and aid them in the creation of fantastic new computer experiences, I get a multiplier effect where I’ve helped the few affect the masses. 

I’ve spent my entire life at Microsoft as a Program Manager in the Visual Studio Core Team.  I’ve been working on MSBuild for the past 2 years.  Before Microsoft I worked as a consultant for a French based consulting firm and attended Rochester Institute of Technology (RIT) where I received a degree in software engineering. 

So that’s a little bit about me, where I fit in the world and what I’m passionate about.  Hopefully I haven’t bored you yet, and stay tuned as the next few post I intend to make technical as opposed to fluff :-)

Thanks,

Alex Kipman (AKipman@microsoft.com)

Program Manager

MSBuild Team

¹ – Kipmanisms – Word created by Sumedh Kanetkar (SumedhK@microsoft.com), one of our super star MSBuild devs.  It basically denotes weird sentences or words that I say and write.  I usually don’t notice I’ve done it until the entire room starts laughing.  Examples of Kipmanisms range from “Death by a thousand paper clips” to “How about those damn apples”