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
3/ enabling web apps (via ASP.NET, web forms/services, etc.). The client app framework manifested as Windows Forms and was the next iteration of a RAD app creation environment. The Windows Forms designer is extremely rich and intended to make developing UI-rich
4/ Windows apps faster and easier like the Ruby designer did in VB6. Unlike the VB6 designer, the Windows Forms designer needed to work across many languages, initially VB and C#, but ultimately including Delphi, Cobol, C++, F#, etc. This required the designer to read and
5/ generate source code in the language being developed. This was enabled through language-specific CodeDOM generators and parsers. Interestingly, the C# team did not own the CodeDOM implementation for C#. The framework team developed it. However, they only developed the CodeDOM
6/ generator (no parser). This was a priority as it was necessary for ASP.NET development (ASP.NET enabled code compilation on the server, and CodeDOM was the way that happened). That left the Windows Forms designer team in a bit of a lurch,
7/ because while we could use the CodeDOM to generate InitializeComponent code, there was nothing that enabled reading that code back and rendering the form. VB similarly had only a CodeDOM generator and had the same problem. There simply wasn’t time or resources to implement a
8/ full CodeDOM parser implementation, so instead, the C# and WinForms team developed a hack. The designer would query a *CodeModel* implementation for a specific private interface called IMethodXML. It would do this for the InitializeComponent method of any class that was
9/ ‘designable’. This interface would convert a very limited set of statements and expressions into XML that the designer would read and turn into its CodeDOM representation. As a simple example: 
10/ This was put together on a weekend and was both awesome and problematic. It was awesome because it unblocked the designer and ultimately everyone that developed Windows Forms applications in VS 2002 using C# & VB. It was problematic for a few reasons.
11/ First, most of the team didn’t know it existed, including the test team. Second, it wasn’t documented. Third, it wasn’t the way the designer worked for other languages. Finally, since the schema was so limited it meant that as soon as a user made changes to the
12/ InitializeComponent method by hand, they could easily cause this method to choke, which in VS 2002 often led to the deletion of the body of the IntializeComponent method. That is, all the control and form placement, sizing, event hookup, etc. This was infuriating for
13/ developers and mitigated only slightly with a region we wrapped the method in saying something akin to ‘Designer generated code, don’t edit by hand’. There were other issues as well in that it was verbose, synchronous, language-specific, etc. That there was a designer
14/ experience at all for C#/VB was heroic but looking back on this one still gives me heartburn when thinking about the folks that lost hours/days/weeks of time when the designer ate their code. This ultimately led to some innovation in the languages ala partial classes and was
15/ part of the impetus to have a much richer code model in future versions.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
