Don Kiely's Technical Blatherings

All Things Technical in .NET, SQL Server, and Security

<August 2008>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456


Navigation

Personal

Subscriptions

News

Post Categories



Friday, November 16, 2007 - Posts

DebuggerTypeProxy Proxy Class is Compiled into Release Build

I recently did a session about debugging ASP.NET applications at the Victoria .NET Developers Association in Victorial, B.C. It was a fun meeting, and as an Alaskan from Fairbanks I always feel a special bond with my Canadian peers down south!

I also had the opportunity to meet Ken Cox, who I’ve long known through Visual Studio Magazine but had never met. He and I have written the majority of the First Looks reviews in the magazine for years. I’ve always thought that he got the coolest products to review, and now I know that he has thought the same thing about me!

Ken asked an interesting question during the session, one that I had never explored. I was showing the DebuggerTypeProxyAttribute attribute, which lets you substitute an entirely different class for display in Visual Studio 2005’s Locals window (as well as other debugging windows where object variables are displayed). It’s a cool way to simplify the display of complex objects for debugging, although it can easily be abused to make debugging harder.

He asked whether the proxy class—used as the substitute display object—is compiled into the release build of the assembly. I didn’t know, but promised to find out.

Turns out that the proxy class is indeed included in the release build. Which, now that I know the answer, makes sense. There really isn’t anything special about the proxy class, and it is conceivable that it could be used for other purposes in the application. In the example I showed, the proxy class was internal to the class it was substituting for in the debug windows, but that isn’t a requirement; it is usually more convenient though.

For the compiler to exclude the class from the assembly, it would have to look at the DebuggerTypeProxy attribute and remove the code before compiling. But that raises all sorts of dependency issues that I’d rather not rely on the compiler to handle. Instead, a developer could use conditional compilation directives to remove the code, if it wasn’t needed in the release build.

A tip of the anorak to Ken for a great question!

posted Friday, November 16, 2007 4:50 PM by donkiely with 1 Comments




Powered by Dot Net Junkies, by Telligent Systems