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,
3/ after some development, it became clear that the service pack was growing past simple bug fixes. Most notably, the release was set to align with the release of the .NET compact framework (anyone remember the codename for this? :-), and we wanted VS to have good support for
4/ smart devices. This led to the 'Everett' release being christened, which ultimately manifested publicly as VS 2003.
The C# compiler added very few features in VS 2003. Much effort was already happening in designing generics for VS 2005. However, that isn't to say there were
The C# compiler added very few features in VS 2003. Much effort was already happening in designing generics for VS 2005. However, that isn't to say there were
5/ no compiler features released in 2003. In this post, I'm going to talk about a very small feature that had an outsized experience on the debugging experience. That feature was a new pragma option, #line hidden. C# already supported a #line directive. It was heavily used for
6/ scenarios where C# was embedded into another language, like ASP. NET. #line allows specifying a mapping between the source file and another file for the purposes of both stepping and error reporting. Generally, ASP. NET would generate a #line back to the .aspx file at the
7/ proper line that contains the C# code so that if there was an error on that line the error was shown in the aspx instead of the generated source file. The problem in VS 2002 was that there was no way to prevent stepping to the generated code if you stepped over the last line
8/ of the script block. For example: 
9/ In this case, after the breakpoint is hit, if you were to step twice, you'd end up with:
10/ #line default told the compiler to stop mapping the error and stepping behavior to the other file. However, there was no way to say 'don't allow stepping through the rest of the code in this file'. That's where #line hidden came in.
11/ ASP. NET would start generating this code instead:
12/ The compiler would then generate a PDB with no additional mapping which, in this example, would mean that stepping past the end of the C# block would simply have the same impact as a 'continue'. The only real complexity here was explaining that #line hidden didn't impact
13/ error reporting, while #line <line number> <filename> did. I expect very few people explicitly noticed this change, but #line hidden has been used over and over again across many code generation scenarios for the past 18 years.
14/ There was an additional scenario that we considered at the same time that #line still doesn’t completely address - anyone know what it is?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
