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>):
3/ public int CompareTo(Widget other)
{
throw new Exception("The method or operation is not implemented.");
}
The C# community was, not surprisingly, somewhat confused (and often livid) that the code generation didn't use NotImplementedException instead.
{
throw new Exception("The method or operation is not implemented.");
}
The C# community was, not surprisingly, somewhat confused (and often livid) that the code generation didn't use NotImplementedException instead.
4/ I received a good amount of angry mail explaining how dumb this was. It's hard to argue, and in fact, we had generated NotImplementedException for every Community Tech Preview (CTP) release of VS 2005. So what changed?
5/ In late 2004, the Visual Studio for Devices team was updating the VS support to build .NET apps for devices that ran on the compact framework. The first release of this tooling was in VS 2003; however, in VS 2005 we changed implement interface in significant ways that I'll
6/ talk about at some later point. For this discussion though, the notable change was that in VS 2003 we returned a 'default value' instead of throwing an exception. The new generation broke the code for Smartphones. Why? Well, because of the lag time of getting framework
7/ versions on hardware, Smartphones were running CF 1.0. CF 1.0 didn't have NotImplementedException.
We didn't have time to implement smarter code generation that would selectively generate different results when targeting CF versus the desktop framework at that point,
We didn't have time to implement smarter code generation that would selectively generate different results when targeting CF versus the desktop framework at that point,
8/ so we did the simplest thing possible. We rationalized this as follows: 1) the generated code was almost always going to be replaced anyway, so surely having it generate temporary code that wasn't ideal was okay, 2) even though there were fewer Smartphone than framework
9/ developers, we wanted to maintain that the code generation we did would work regardless of target, and 3) the code generation was based on a stub that could be changed by the user if they found it particularly offensive.
10/ It seemed relatively benign, but I got a surprising amount of hate mail about this one :-)
I'll talk about customizing this generated code some other time, but in case folks are interested, it's still possible in much the same way as it was then.
I'll talk about customizing this generated code some other time, but in case folks are interested, it's still possible in much the same way as it was then.
11/ The furor around this eventually calmed down as we were able to change the code generation in future releases as newer versions of CF were adopted.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
