.NET (General)

Sams Teach Yourself Visual C# 2010 in 24 Hours

Scott Dorman — Fri, 06 Nov 2009 04:01:43 GMT

I have previously mentioned that I’m working on the upcoming Sams Teach Yourself Visual C# 2010 in 24 Hours book.

Things are progressing nicely, if a bit slower than I’d prefer. I have the draft for the cover art, which looks really good.

I’m also very pleased to announce my technical editors – Claudio Lasaala and Eric Lippert.

Claudio is a Senior Developer at EPS Software Corp. He has presented several lectures at Microsoft events such as PDC and various other Microsoft seminars, as well as several conferences and user groups across North America and Brazil. He is a multiple winner of the Microsoft MVP Award and also holds the MCSD for .NET certification. He has articles published on several magazines, such as MSDN Brazil Magazine, CoDe Magazine, UTMag, Developers Magazine, and FoxPro Advisor.

Eric is a senior software design engineer at Microsoft has been working full time in the developer division since 1996, where he assisted with the design and implementation of VBScript, JScript, JScript.NET, Windows Script Host, Visual Studio Tools for Office and C#.

I am looking forward to working with both Claudio and Eric through the technical editing process and getting this book completed and available, which should happen sometime early in 2010.

Technorati Tags: Books,Sams Teach Yourself C# 2010

Visual Studio 2010 Beta 2

Scott Dorman — Mon, 19 Oct 2009 18:09:29 GMT

Visual Studio 2010 Beta 2 is now available for MSDN subscribers, and generally available on October 21. I haven’t had a chance yet to play around with it, but some of the CLR changes that are very exciting to hear about are:

The new String.IsNullOrWhiteSpace method indicates whether a string is null, empty, or consists only of white-space characters.
New overloads have been added to the String.Concat and String.Join methods that concatenate members of an IEnumerable<T> collections.
The String.Concat<T> method lets you concatenate each element in an enumerable collection without first converting the elements to strings.
The new Enum.HasFlag method determines whether one or more bit fields or flags are set in an enumeration value.
The Enum.TryParse<TEnum> method returns a Boolean value that indicates whether a string or integer value could be successfully parsed.
You can now easily copy one stream into another with the CopyTo method in classes that inherit from the System.IO.Stream class.
New Path.Combine method overloads enable you to combine file paths.
You can now parse System.Guid structures.
The new Microsoft.Win32.RegistryOptions enumeration lets you specify a volatile registry key that does not persist after the computer restarts.
Registry keys no longer are restricted to a maximum length of 255 characters.

I’m really looking forward to these improvements, particularly Enum.HasFlags, Enum.TryParse, String.IsNullOrWhiteSpace, Guid.TryParse, and Path.Combine(string[]). Of course, since some of these weren’t in Beta 1 (at least as far as I saw), it means revising some of the chapters for my book.

Technorati Tags: Visual Studio 2010,Beta 2,.NET 4.0

Interesting .NET Framework Statistics

Scott Dorman — Mon, 21 Sep 2009 01:15:01 GMT

I’ve been very “heads down” working on my upcoming book from Sams Publishing, Teach Yourself C# 2010 in 24 Hours, so I haven’t been blogging as much as I usually do. In doing some research for the book, I’ve been taking an in-depth look at the .NET Framework and thought I would share some interesting statistics.

There are 18,435 total types in the .NET Framework 3.5 SP1, with 13,995 classes, 1,216 interfaces, 2,100 enums, and 1,124 structs. The complete breakdown is shown below.

Of the 13,995 classes, 303 of them are exceptions. There are 227 public and 76 non-public exceptions. The complete breakdown is shown below.

Technorati Tags: .NET Framework

Premature optimization is the root of all evil

Scott Dorman — Sat, 29 Aug 2009 03:24:41 GMT

I’ve lost count how many times I’ve heard that quote. It’s a great quote said by one of the leading minds in computer programming and formal mathematics, Donald Knuth. The problem with this quote is that, like so many other things, people have only remembered (or only quote) a small portion of the entire thing.

To read the full quote, you need to look at a paper published in December 1974 titled Structured Programming with go to Statements in Computing Surveys.

The full quote is this (in reference to a loop optimization technique that provides a 12% performance improvement):

The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-
and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn't bother making such optimizations on a oneshot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code
has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been
that their intuitive guesses fail. (Computing Surveys, Vol. 6, No. 4, December 1974, p. 268 [p. 8 of the PDF])

While the overall sentiment could be summed up simply as “premature optimization is the root of all evil”, I think the point being made here is that well-known optimizations can and should be applied otherwise time spent on optimizing code should be focused on that small percent of critical code and should be performed with quantitative means.

What are well-known optimizations? That partly depends on your programming language and partly on your problem domain. Optimizations specific to a problem domain are very domain specific and not easily communicated outside of that domain. However, language specific well-known optimizations are a different story.

Take string concatenation inside a loop, particularly for languages like C# where strings are immutable objects. Why is that important? Since strings are immutable, they cannot be changed once created. When concatenating two strings you incur overhead from the creation of temporary strings. For example, consider the following code:

     string s = "this is " + "a test.";

While this is an arbitrary example, in order for this line to execute it would be necessary to create 3 strings. (Yes, I know the compiler (and if not the compiler, the JIT) would optimize this to remove the concatenation, but pretend for a moment that it didn’t.) Now, imagine this line running inside a loop 10 times. That loop has just created approximately 30 temporary string objects to perform that concatenation. In such a situation, it should be intuitive that the use of a StringBuilder to perform the string concatenation is preferable as you no longer have the intermediate string object creation and result in one allocation to create the StringBuilder and one allocation to convert the StringBuilder to an actual string object. There is always the possibility that while iterating through the loop the StringBuilder may need to perform a few additional buffer reallocations, but that still results in less overhead than creating immutable string objects.

The point here is that while it is true that premature optimization is the root of all evil, optimization should be a measured undertaking and well-known optimizations applied early are not premature.

Visual Studio 2010 Beta 1

Scott Dorman — Mon, 18 May 2009 14:55:10 GMT

I’m still waiting for an “official” announcement, but if you are an MSDN subscriber you will be able to download Visual Studio 2010 Beta 1 later today (May 18), probably around 12:00 PM (PST). If you aren’t an MSDN subscriber, you will be able to download Beta 1 on May 20 through Microsoft Downloads.

Technorati Tags: Visual Studio 2010

Code Contracts in .NET

Scott Dorman — Tue, 03 Mar 2009 00:44:15 GMT

I have previously talked about code contracts in .NET 4.0, and while .NET 4.0 isn’t out yet you can work with them now in Visual Studio 2008 through MSDN DevLabs.

In case you aren’t familiar with code contracts in .NET, this is a feature that was actually built by the .NET CLR team to provide a language-agnostic way to express code assumptions in the form of pre-conditions, post-conditions, and object invariants.

There are currently two tools provided:

Runtime Checking, which uses a binary rewriter to modify a program by injecting the contracts, which are checked as part of program execution.
Static Checking can decide if there are any contract violations without even running the program. It checks for implicit contracts, such as null dereferences and array bounds, as well as the explicit contracts.

This is definitely something to take a look at and start getting familiar with in order to simplify your code and testing.

Technorati Tags: Code Contracts,.NET

MVP Summit 2009 Twitters

Scott Dorman — Sun, 01 Mar 2009 23:45:00 GMT

If you’re at MVP Summit 2009 (or not at Summit) and trying to find people to follow I’ve started putting together a list of MVPs and Microsoft employees that I know who are here.

Everyone should be using the #mvp09 hashtag for their tweets, so you can follow the conversations using #hashtags, Twitter Search, Twopular, TweetScan, or any other twitter search sites.

If you want to be included in this list (or have updates to your information), leave a comment or message me on Twitter.

Microsoft MVPs

Name	Twitter	Blog	Location
Scott Dorman	http://twitter.com/sdorman	http://geekswithblogs.net/sdorman	Tampa, FL
Nikita Polyakov	http://twitter.com/NikitaP	http://geekswithblogs.net/campuskoder/Default.aspx	Tampa, FL
Bill Reiss	http://twitter.com/billreiss	http://www.bluerosegames.com/silverlightbrasstacks/	Tampa, FL
Rob Zelt	http://twitter.com/robzelt	http://www.robzelt.com/blog/	NC
Keith Elder	http://twitter.com/keithelder	http://keithelder.net/blog/	Hattiesburg, MS
Todd Miranda	http://twitter.com/tmiranda	http://www.xperimentality.com/	Alabama
Alan Stevens	http://twitter.com/alanstevens	http://netcave.org/	Knoxville, TN
Jeff Barnes	http://twitter.com/jeff_barnes	http://jeffbarnes.net/blog/	Birmingham, AL
Dennis Bottjer	http://twitter.com/dbottjer	http://drowningintechnicaldebt.com/blogs/dennisbottjer/default.aspx	Tulsa, OK
Shervin Shakibi	http://twitter.com/ShervSherv	http://www.geekswithblogs.com/shervin/Default.aspx	Boca Raton, FL
Simone Chiaretta	http://twitter.com/simonech	http://codeclimber.net.nz/	Milan, Italy
Stephen Foskett	http://twitter.com/sfoskett	http://blog.fosketts.net/	Wooster, OH
Dave Noderer	http://twitter.com/davenoderer	http://geekswithblogs.net/dnoderer/Default.aspx	Deerfield Beach, FL
David Silverlight	http://twitter.com/HeadGeek		Miami, FL
Bill Pytlovany	http://twitter.com/BillP	http://bitsfrombill.com/	Scotia, NY
Joseph Guadagno	http://twitter.com/jguadagno	http://www.josephguadagno.net/default.aspx?AspxAutoDetectCookieSupport=1	Chandler, AZ
Tony Ramos	http://twitter.com/tonyramos	http://tonyramos.com/	Cleveland, OH
Marques Lyons	http://www.twitter.com/tromboneforhire	http://www.insidethecircle.net/	Anaheim, CA

Microsoft Employees

Name	Twitter	Blog	Focus Area/Position
Kevin Pilch-Bisson	http://twitter.com/Pilchie	http://blogs.msdn.com/kevinpilchbisson	Dev Lead – C#
Jake Grey	http://twitter.com/jake_grey		MVP Lead - C# & Security, Community and Online Support
P.J. Forgione	http://twitter.com/pj_forgione		MVP Lead – Visual Basic
Joe Healy	http://twitter.com/devfish	http://devfish.net	Developer Evangelist – Florida
Scott Hanselman	http://twitter.com/shanselman/	http://www.hanselman.com/blog	Principal Program Manager
Luis Daniel	http://twitter.com/luisdans	http://blogs.msdn.com/luisdans/	Developer Platform Evangelism Area Lead – Latin America

Technorati Tags: MVP09,Twitter

Visual Studio 2008 Debugging – The Watch Window

Scott Dorman — Sun, 15 Feb 2009 02:23:48 GMT

The Watch window (actually there are four different Watch windows you can use) is easily the most powerful aspect of the Visual Studio debugger and the underlying technology it uses actually surfaces in several places:

Watch
Autos
Locals
Quick Watch
“Data Tips” (the debugging tool tips that appear when you hover over a code element)

The thing that most people might not realize is that you can actually call methods in the Watch window. This is useful because it allows you to see data structures that might not otherwise display well and you can also have completely dynamic assertions.

Calling a method in the Watch window is as simple as adding the parenthesis and any parameters needed.

There are a few considerations to be aware of when doing this, however. They are:

The function (property or method) executes in the context of the debuggee.
Don’t do anything more than reading memory.
The method must execute in less than 20 seconds.
Breakpoints are not hit when called from the Watch window.

Another very useful trick is that the Watch window supports drag and drop from the code editor. Simply select the expression in the code editor and drag it to the watch window.

Just like you can execute functions in the watch window, you can execute them in the Value column of the Watch window as well. This allows you to easily change the value of a watched expression to a completely new instance of an object. In the Value column, simply enter “new SomeClass()” to set the value to a new instance of the SomeClass object.

From the Immediate window you can type in an expression to allocate on object

        1: ? SomeClass x = new SomeClass()

and then in the Value column enter the variable prefixed with a “$” sign. (In this example, $x.)

Finally, let’s take a look at the Make Object ID capability of the debugger. This is available from the Locals and Autos windows through the context menu. Simply select the object you are interested in and right click, then choose the Make Object ID. This will create a numeric ID for that object, which will be displayed after the value.

What is actually happening here is that it tells the debugger to watch a particular object in memory no matter where it goes. This is useful because if the actual object goes out of scope you can still watch it by using the object ID. If the object ID says “Can’t evaluate” then it means the object has been garbage collected. Object IDs can also be used in conditional breakpoints and as parameters to function calls.

For instance, if you wanted to know what GC generation an object is in, you can do so using Object IDs.

Technorati Tags: Visual Studio, Advanced, Debugging

Visual Studio 2008 Debugging – Advanced Tricks

Scott Dorman — Sun, 15 Feb 2009 00:45:40 GMT

We previously talked about the Location, Condition, Hit Count, Filter, and When Hit modifiers for breakpoints. These are great advanced breakpoints that will really make your debug sessions much more useful, but there are also some other advances in Visual Studio that go beyond these breakpoint modifiers.

The first advance is the idea of advanced location breakpoints. How many times have you been debugging an issue and as you’re looking at the call stack you realize that you want to set a breakpoint somewhere higher up in the call stack? This is really useful when you want to let execution continue but want to stop part way through the return sequence from some lower-level function.

In order to accomplish this you would ordinarily have to find the source file in the solution explorer, then find the function you are interested in and set your breakpoint. Yes, you can simplify this by double-clicking the line in the call stack, which will take you to that line in the source code but then you loose the context of your current location.

Well, Visual Studio allows you to select the line in the call stack and press F9 (on the default keyboard, this is the keyboard shortcut to insert a breakpoint) and a breakpoint will be inserted at the appropriate location in code. You can also right click on the stack item and choose Run to Cursor.

This is great, but what about trying to set a breakpoint on a line that contains sub expressions, such as a foreach loop. A foreac loop is actually comprised of 3 sub expressions. If you click the gutter to set a breakpoint it sets it on the first sub expression on the line.

How do you set a breakpoint on another sub expression? For instance, if I wanted to set a breakpoint on the workerSettings.Tasks property in the foreach statement. By selecting the sub expression (or simply putting your cursor anywhere in that sub expression) and pressing F9 you will set a breakpoint only on that sub expression.

Let’s now look at a concept that can only be called dynamic assertions. Hopefully you are familiar with the Debug.Assert and Trace.Assert methods which allow you to halt program execution given a specific Boolean condition. While these are useful they aren’t very dynamic and can’t be very complex. But what happens if you want to hit a breakpoint when an error condition occurs in your application that needs to take in to account multiple factors?

If you remember from our discussion on the Condition modifier you can set the condition expression to any any valid Boolean expression. This means that you can also set the condition to be the result of a method call, as long as that method returns a Boolean value. In order to do this, you need to add a method that returns a Boolean. This method should return true if an error condition exists. (Basically, it should return true when you want the breakpoint to hit.)

        1: #if DEBUG

       2: public bool CheckName()

       3: {

       4:    if (this.name == null)

       5:    {

       6:       return true;

       7:    }

       8:  

       9:    return false;

      10: }

      11: #endif

Notice that I didn’t use the ConditionalAttribute(“DEBUG”) syntax here. The reason for this is that this attribute only works for void return types. Now that we have this method defined, you can use it as the condition expression

You also get some IntelliSense help showing that this is the correct method and you can verify that the condition is set correctly by looking at the Breakpoints window

Now, whenever the result of CheckName() is true, the breakpoint will be hit. This allows you to create some really complex and powerful debug conditions for your breakpoints.

Finally, we need to take a look at the New Breakpoint dialog. This is probably the most powerful and underutilized feature of the debugging system. Most of the developers that I know open files and scroll around until they find the line of code that should contain a breakpoint. In at least half of those times (if not more) they already know the function that should contain the breakpoint and generally want to set the breakpoint at the start of the function. This is where the New Breakpoint dialog can really help.

As you can see from the dialog, you can simply type the name of the function (this can be either a method or a property) which will contain your breakpoint. Unfortunately you don’t get any IntelliSense help while typing the function (like you do in the Breakpoint Condition dialog) but if you leave the “Use IntelliSense to verify the function name” checkbox checked it will display a warning message if you get the name wrong.

While this can save a lot of scrolling through files to find the right function, it does require you to know the fully qualified method name, which means you must know both the class and method name. What happens if you don’t know what class the method is in or you have multiple methods of the same name where you want to set breakpoints? As long as you have a project loaded, you can simply type the function name and a Choose Breakpoints dialog will display.

From this dialog, you can see all of the functions that match the name from all classes.

Technorati Tags: Visual Studio, Advanced, Debugging

Visual Studio 2008 Debugging Tricks – Tracepoints

Scott Dorman — Sat, 14 Feb 2009 22:17:12 GMT

We have talked about the Location, Condition, Hit Count, and Filter modifiers for breakpoints which only leaves the When Hit modifier. Using the When Hit modifier allows you to change your breakpoint to a tracepoint.

What is a tracepoint? Simply put, it is a breakpoint that continues execution. Why would this be interesting or even important? Tracepoints are great when you want to trace a particular path of execution, such as OnDeserialized events in your WCF DataContract classes. You are interested in watching the order your objects are deserialized to ensure that everything is happening when you expected it to occur.

In this scenario, you aren’t really interested in stopping the execution. Ordinarily you could achieve this by inserting Trace.WriteLine (or even Console.WriteLine or Debug.WriteLine) calls throughout your code. While this would work it means that you are adding lines of code just for debugging purposes (so hopefully they would only be needed temporarily) which means you need to remember to remove them when you are done debugging. Wouldn’t it be great if you could simply set a breakpoint to execute Console.WriteLine (or some equivalent) to display a message in our Output window?

That’s exactly what a tracepoint does, but it can do a lot more than just that.

The When Breakpoint Is Hit dialog allows you to simply print a message, but that message can contain special keywords and can also evaluate methods and properties of any object that is in scope when the tracepoint is hit. In addition to printing a message, you can also run a macro. By default a tracepoint is intended to continue execution, but you can change that as well which will effectively give you a breakpoint which will print a message and/or execute a macro before breaking.

Technorati Tags: Visual Studio, Advanced, Debugging