Incremental rebuild was a feature of the C# compiler which was meant to increase the throughput after an initial build. It worked on the principle that changes in between builds are localized, and that the information gathered by the compiler from previous builds wouldn't be

entirely invalidated; specifically, some of the information and, indeed, the assembly itself could be updated in an incremental fashion resulting in faster builds.
Both the VS 2002 and VS 2003 compilers exposed this option through the /incr switch on the command line, and the ‘Incremental Rebuild’ option in the Advanced tab of Project Properties. In 2002 incremental rebuild was enabled by default for all project types.
After we shipped 2002 we noticed that we started to get a large number of bugs (internal compiler errors - ICEs – the worst kind) which were a direct result of the incremental rebuild feature.
These bugs derived from the complexities involved in correctly implementing incremental rebuild and the problems associated with testing it. Consequently, for 2003 we fixed all known issues with incremental rebuild but subsequently turned it off by default for all projects.
Incremental build initially seems like a no-brainer win, it can theoretically improve compilation times by significant amounts, in certain cases we saw single assembly build times improve by as much as 6x.
However, and this may seem counter-intuitive at first, incremental rebuild could also lead to longer build times. Why? The feature had several heuristics to determine whether it should do a full rebuild or not.
One of those heuristics was if > 50% of the files being tracked needed to be recompiled. However, in most cases the files that needed to be recompiled aren't simply the files that have changes, but rather the dependency graph between the changed public interface of the types
within the files and those other source files that depend on those types. So, the compiler would do a lot of work to figure out the dependency graph, and occasionally discover it should actually do a full build anyway.
Due to how incremental rebuild worked, it would then throw out all of the work it had done, and simply perform the normal build at that point, increasing the end-to-end time. Incremental rebuild also had a few other implications that were likely non-obvious to folks.
We wanted to update the existing assembly and PDB, but due to the way they are laid out, incrementally updating them meant they would contain the old data as well and we'd just update the pointers (e.g. in the metadata table) to point to the new locations in the file.
That meant the assembly generated from an incremental build was different than what you'd get from a non-incremental build, and both be larger and slower to load.
The slower to load aspect likely wasn't a big deal; however, the different output spoke to one of the major problems that users had with incremental build. In VS 2002 it was entirely possible to build, have the compiler choke and issue an error, and the simply build again
and have it work. This lowered confidence in the compiler (reasonably), and led to odd conclusions about why the compiler was exhibiting this behavior that were unrelated to the incremental flag, because many users didn't even know it was set.
For example, folks might tweak their code, do another build, and have it work - not because of the change they made, but because a non-incremental build happened. There were at least 13 cases that would cause the compiler to bail on doing an incremental rebuild and perform a
full build instead, including things like 'more than 30 successful incremental builds without a full build', which would prevent the PE from getting too bloated over time. So, whether or not the user actually saw the incremental behavior was difficult for them to predict.
All of this led to the decision to cut incremental build in VS 2005. I should mention that this is incremental compilation of the assembly, incremental rebuild of the solution was most decidedly not cut and was greatly improved in VS 2005 through MSBuild.
The funny thing about this one is that we had initially spent significant design, added complexity to the codebase, and effort in validation (every feature added to the language needed to be separately tested in incremental cases) and when we turned it off by default in VS 2003
essentially no one noticed. We had a few folks who mentioned it in VS 2005, but not because they saw the compiler builds get slower, but simply because they saw the option was removed.
TBH the regular feedback we had was that the compiler was blazingly fast - particularly from folks who had been using C++ for a long while. This is another feature that, looking back, we probably should never have done.
It caused customers tons of headaches for little ultimate benefit. That said, I feel good about our willingness and decision to remove it. Occasionally, at Microsoft we fall prey to the sunk cost fallacy, but it's gotten much better over the years as our telemetry has
dramatically improved and we have lots of additional insight about usage and benefit versus what we had in 2003 when we made this decision. So, if anyone used VS 2002 and wondered what happened to this option, now you know :-)

More from Tech

So we had to develop technologies like this to barely manage control over limited areas in Iraq's few urban centers. Only ~8 in 100 Iraqi adults owns a personal vehicle. That rate is > 1 car/adult in America yet I have never seen any doctrine paper or work of fiction address this


We've seen and struggled in civil conflicts with instant, local, universal, distributed communications (cell phone era, basically every conflict since 2000). We've seen and struggled in conflicts with instant, global, universal distributed communications (everything since 2011).

The world's most overfunded military and glow in the dark agencies struggle and largely fail to contain conflicts where fhe vast, vast majority of people are locked into a ~5mi radius of their home.

How can they possibly contain a conflict in a nation with universal car ownership and the most developed road network in the world? The average car can travel over 400 miles on one tank of gas, how can you contain the potential of that kind of mobility?

I think that's partially why the system was so freaked out by 1/6. Yes, most of it is histrionics but you don't decide to indefinitely turn your capital into the Baghdad Green Zone with fortifications and 25k troops over histrionics alone.
Ok, I’ve told this story a few times, but maybe never here. Here we go. 🧵👇


I was about 6. I was in the car with my mother. We were driving a few hours from home to go to Orlando. My parents were letting me audition for a tv show. It would end up being my first job. I was very excited. But, in the meantime we drove and listened to Rush’s show.

There was some sort of trivia question they posed to the audience. I don’t remember what the riddle was, but I remember I knew the answer right away. It was phrased in this way that was somehow just simpler to see from a kid’s perspective. The answer was CAROUSEL. I was elated.

My mother was THRILLED. She insisted that we call Into the show using her “for emergencies only” giant cell phone. It was this phone:


I called in. The phone rang for a while, but someone answered. It was an impatient-sounding dude. The screener. I said I had the trivia answer. He wasn’t charmed, I could hear him rolling his eyes. He asked me what it was. I told him. “Please hold.”

You May Also Like

दधीचि ऋषि को मनाही थी कि वह अश्विनी कुमारों को किसी भी अवस्था में ब्रह्मविद्या का उपदेश नहीं दें। ये आदेश देवराज इन्द्र का था।वह नहीं चाहते थे कि उनके सिंहासन को प्रत्यक्ष या परोक्ष रुप से कोई भी खतरा हो।मगर जब अश्विनी कुमारों ने सहृदय प्रार्थना की तो महर्षि सहर्ष मान गए।


और उन्होनें ब्रह्मविद्या का ज्ञान अश्विनि कुमारों को दे दिया। गुप्तचरों के माध्यम से जब खबर इन्द्रदेव तक पहुंची तो वे क्रोध में खड़ग ले कर गए और महर्षि दधीचि का सर धड़ से अलग कर दिया।मगर अश्विनी कुमार भी कहां चुप बैठने वाले थे।उन्होने तुरंत एक अश्व का सिर महर्षि के धड़ पे...


...प्रत्यारोपित कर उन्हें जीवित रख लिया।उस दिन के पश्चात महर्षि दधीचि अश्वशिरा भी कहलाए जाने लगे।अब आगे सुनिये की किस प्रकार महर्षि दधीचि का सर काटने वाले इन्द्र कैसे अपनी रक्षा हेतु उनके आगे गिड़गिड़ाए ।

एक बार देवराज इन्द्र अपनी सभा में बैठे थे, तो उन्हे खुद पर अभिमान हो आया।


वे सोचने लगे कि हम तीनों लोकों के स्वामी हैं। ब्राह्मण हमें यज्ञ में आहुति देते हैं और हमारी उपासना करते हैं। फिर हम सामान्य ब्राह्मण बृहस्पति से क्यों डरते हैं ?उनके आने पर क्यों खड़े हो जाते हैं?वे तो हमारी जीविका से पलते हैं। देवर्षि बृहस्पति देवताओं के गुरु थे।

अभिमान के कारण ऋषि बृहस्पति के पधारने पर न तो इन्द्र ही खड़े हुए और न ही अन्य देवों को खड़े होने दिया।देवगुरु बृहस्पति इन्द्र का ये कठोर दुर्व्यवहार देख कर चुप चाप वहां से लौट गए।कुछ देर पश्चात जब देवराज का मद उतरा तो उन्हे अपनी गलती का एहसास हुआ।