🧵Early in my career at Microsoft I was a PM on the C# compiler and language. Along with the QA and Dev lead we would regularly triage through bugs and decide when and whether they would be addressed. This was at a time when we'd spent the last 3 and 1/2 years working on VS 2002, .NET 1.0, C# 1.0, etc. We were approaching our release and so our triage bar for fixing issues was very high, particularly in the compiler, as we tend to stabilize platform components earlier than leaf components. Microsoft had a system for entering and tracking bugs,

1/ The second 'feature' that the compiler team invested in during the VS 2003 release was ECMA conformance. The VS 2002 compiler was close; however, there were some areas that weren't yet covered. These were almost universally small things, but one is interesting because a lot of 2/ folks are still unaware this feature exists. C# supports two forms of XML doc comments, the extremely common single-line-doc-comment, and the much less used delimited-doc-comment. The delimited-doc-comment wasn't in the specification that Microsoft proposed to ECMA and was

1/ At the time that we shipped VS 2002, it was common to release several 'service packs' over the course of months or years afterwards. These service packs contained a large number of bug fixes that addressed issues that were discovered after we released. In comparison to today, 2/ the pace of releasing was glacial. I am much happier with the velocity at which we can ship updates now (though admittedly, I know some folks wish we didn't ship quite so often). Regardless, the next release after VS 2002 was originally intended to be a service pack. However,

1/ If you have ever worked with Windows Forms, you may have noticed that the icon that appears in solution explorer changes when it contains a 'designable' type, and that when you double-click on any file with that icon, it opens the designer. 2/ If you play around with this a bit, you may also notice that if you change a class to descend from System.Windows.Forms.Form, it will become designable, and the designer lights up. I doubt many people have thought about how that works.

1/ In the late 90s we were busy on the ambitious project of Visual Studio .NET, introducing a new runtime, new languages, and a new shell. The last involved combining several existing shells, VJ/VI/MSE 6, VC6, and VB6. 2/ This led to many difficult discussions, incredibly complicated and confounding technical challenges, and the most difficult problem - what side of the environment should the Solution Explorer dock to by default?

1/ In the VS 2005 release there were many new features for the C# IDE experience, several of which would generate code. An example was implement interface, which was proffered as either a 'smart tag' or through the context menu. 2/ Another was generate method stub, where we would optionally create a method if you consumed it without having declared it first. When we released VS 2005, these features would generate stubs of the following form (this is the code gen for implementing IComparable<Widget>):

1/ @DesignPuddle asked why Solution Explorer search is so much slower than Goto All when searching for files. This is seemingly nonsensical because Goto All is presumably searching for everything while solution explorer search is searching less, right? Well… it is nonsensical, 2/ the search should be much faster, and the reason it’s slow has a lot to do with how it was initially designed versus what it’s now being used for. So, lets dig in a bit.

Both Goto All and Search in Solution Explorer are extensible via providers. However, the providers are

1/ It's been very busy at MS ever since the new year started, and you've probably seen a bit of what we're working on with Visual Studio 2022 (devblogs.microsoft.com/visualstudio/v…). 2/ I'm going to go further back in history though, and talk about a defining moment for Visual Studio .NET (2002) and really all of Microsoft. In early 2002, Bill Gates sent a memo to the entire company that kicked off the Trustworthy Computing initiative.

One of the stories that my first manager used to tell, that I always got a kick out of was the following. Context: Think Week was a week that Bill Gates used to take every year to learn about a huge variety of topics, and folks at MS would submit papers/bits. It was a big deal. "I joined Microsoft on 3/19/99 and found out I was working on a new language. The first week was a blur just getting up to speed and I don't think I even installed the complier (not that it did much then - I think you could define an interface but not use it yet).

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.

In 2001 I had only recently joined Microsoft full time, so I was really just getting my feet underneath me in the org. There were many internal teams using C#, so one of the things I owned was an internal DL called CSharp User Community which had thousands of folks on it. The point of the DL was for C# users to ask questions of each other to get help as they needed it, but I did participate a lot as often folks would ask for definitive answers. The downside to this is that I often received a large number of mails throughout the day directly.

I was trying to remember any interesting event associated with a new year and the best I could come up with this morning is many years after what I've been tweeting about, in 2010. In 2010 we were working on Dev11 (VS 2012) and iterating closely with Windows on Windows 8. I was leading a team to create a tooling experience for JavaScript Windows Store apps. Windows 8 was the introduction of the Windows Store and the new WinRT APIs, ABI format, etc. that allowed languages like JS, C#, VB .NET, C++, etc. to directly call the Windows API.

1/ In early 2004 we were heads down executing on Edit and Continue across a large contingent of teams. There had been several iterations of scoping, redesigns, and customer feedback. 2/ We had a weekly meeting every Thursday morning when representatives from each of the teams would get together and review progress. It was fairly heavy weight, but there were so many teams involved that it was necessary to have a regular sync.

1/ Edit and continue was a beloved feature of VB6 and was a priority for making migration onto .NET easy for RAD developers. EnC is magical when it works correctly. For web developers that are used to hot reloading, it enables that type of rapid development, but maintains state. 2/ Unfortunately, it is an extremely difficult feature to implement in a JIT'ed world as we discovered that with .NET 1.0. We actually had a version of EnC in the early releases of VS 2002.

1/ @werat asked about whether the debugger was using the C# compiler or language service in VS 2002. It was not. The debugger has a component called an ‘expression evaluator’ that is provided per language and is responsible for parsing and evaluating expressions when stopped at a 2/ breakpoint. For example, if you type into the immediate window, hover over a variable, type into the watch window, etc. the expression evaluator is involved. The debugger and the language service are actually deeply integrated in a number of scenarios in VS, which may

1/ I haven't mentioned much about C# integration into Visual Studio yet, but at the same time we were working on creating a new language, a new runtime, and a new framework we also decided to take disparate shells (MSDEV, devenv, VB6) and combine them. This was… a lot. 2/ As you might expect, taking on so much at the same time meant a very long development cycle. For those folks using VS6 it was a long wait for VS7 (‘98 to ’02). Regardless, we wanted to continue to provide a compelling LOB (line of business) client app framework while also

1/ An interesting bit of history for .NET and C# is that there used to be a public System.Variant type. It was actually a keyword in C# for a while, alongside of object. If you’re unfamiliar with variants, they are a tagged union type. 2/ This means that they can represent many different data types and contain a ‘tag’ (a small enumeration) that defines the type of data they hold. This evolved because COM uses variants heavily, as did VB6 (and many other languages).

1/ The C# development team, for V1, consisted of 5 individual engineers, a lead, and a couple of PMs. 4 of the engineers worked on implementing the compiler, and the last engineer worked on the Visual Studio integration (e.g., IntelliSense). 2/ The C# compiler was written entirely in C++ as was much of Visual Studio at the time. Everyone on the team wanted to implement the compiler in C#, but as I mentioned previously, expediency was key and when we started, we needed to bootstrap. That was done in C++, so it stuck.

1/ It's probably not the first thing you think of, but when we started .NET (COM+) in the late 90s, C# didn't exist yet. We were working on it at the same time as the CLR and the framework. So, you might wonder, what language was being used to generate IL and write the BCL? 2/ The answer is a language that we called SMC that Peter Kukol wrote the compiler for. Peter is a flat out amazing engineer and wrote the core parts of the compiler in just a few days. This unblocked the framework team, allowed vetting the runtime and interpreter, etc.