Charlie Calvert's Community Blog : LINQ

Tech Republic Posts a Review of Essential LINQ

Charlie Calvert — Fri, 28 Aug 2009 23:46:52 GMT

On the Tech Republic web site Justin James has written a review of Essential LINQ, the book Dinesh Kulkarni and I wrote about the key features of LINQ such as

LINQ to Objects
LINQ to SQL
LINQ to XML

We also touch on important subjects such as the Entity Framework, best practices, and LINQ extensions.

This isn’t the place to rehash the review, but I’ll admit that I found reason to enjoy it. For instance, Justin says: “Overall, I was absolutely delighted with the extraordinarily well written Essential LINQ. It’s one of the few technical books I’ve read that didn’t feel like a chore to read.”

The key links:

Read the Review
Tech Republic also provides a link to a sample chapter from the book.

Community Convergence XLVIII

Charlie Calvert — Wed, 14 Jan 2009 08:03:16 GMT

Welcome to the 48th Community Convergence. The C# team continues to work hard to get out the next version of C#, and to add improvements to the Visual Studio 2010 IDE. Working long, fruitful hours on these rainy Washington State January days and nights, the engineers on our team are doing a great job putting together a set of features that will improve both C#, and the experience C# developers have in the Visual Studio IDE. They are also working to lay the foundation for some big improvements which you will see only after the next version of C# ships.

To keep up with the team's plans, you should:

Continue to follow LINQ
Learn about the Dynamic Features planned for Visual Studio 2010
Learn about the Code Focused IDE features planned for Visual Studio 2010

Here are a few listings that will help you gain deeper insight into all of these important technology:

Videos

Sam Ng

Luca Bolognese

Expression Tree Serialization and LINQ

Eric Lippert

Eric has put together a short, but helpful description of how his fellow team members wrote about the C# Spec in the new book, The C# Programming Language Language, Third Edition. The authors are Anders Hejlsberg, Scott Wiltamuth, Peter Golde, and Mads Torgersen. Other notable luminaries contributed annotations to the printed version of this text. All the authors are very talented and work hard, but In my opinion, Mads deserves a special note of thanks for the great work he did to help pull this edition of the book together.

Kirill Osenkov

Soma

New Features in Visual Studio 2010

Matt Warren

LINQ IQ Toolkit on Codeplex

LINQ Reference Documentation

Charlie Calvert — Mon, 24 Nov 2008 09:33:06 GMT

The LINQ documentation created by Microsoft is available both inside Visual Studio, and for free via the MSDN library found on the WEB. Here are some important pages from that documentation that can help you navigate through the online reference material that Microsoft has prepared for LINQ developers:

· The Root MSDN Library Page: http://msdn.microsoft.com/en-us/library/default.aspx

· .NET Development: http://msdn.microsoft.com/en-us/library/aa139615.aspx

· .NET Framework 3.5: http://msdn.microsoft.com/en-us/library/w0x726c2.aspx

· System.Linq: http://msdn.microsoft.com/en-us/library/system.linq.aspx

· System.Data.Linq: http://msdn.microsoft.com/en-us/library/system.data.linq.aspx

· System.Xml.Linq: http://msdn.microsoft.com/en-us/library/system.xml.linq.aspx

· Code Generation: http://msdn.microsoft.com/en-us/library/bb399400.aspx

· More on Joins: http://msdn.microsoft.com/en-us/library/bb311040.aspx

· For more information on the operators, see the section of the online help called “The .NET Standard Query Operators.” It is written by Anders Hejlsberg and Mads Torgersen. The URL is http://msdn.microsoft.com/en-us/library/bb394939.aspx

I would not suggest using these references materials as a primary means of learning LINQ. However, if you have a book or other guide to LINQ development, then this reference material can be a useful addendum to that text. If you understand in a general way how LINQ works, but need answers to detailed questions, the links provided here may sometimes help you find answers.

LINQ Farm: Covariance and Contravariance in C# 4.0

Charlie Calvert — Tue, 28 Oct 2008 21:04:00 GMT

This post covers the upcoming C# 4.0 support for covariance and contravariance when working with delegates and interfaces. Eric Lippert’s series of posts on this subject are definitely the definitive reference at this time. I’m writing this overview of the subject simply as an appendix to his explanation, and as quick reference for folks who want to get up to speed on this technology. Please remember that this post covers pre-beta technology as defined in the October 2008 CTP of Visual Studio 2010.

The support for covariance and contravariance in the next version of the C# language will ensure that delegates and interfaces will behave as expected when you are working with generic types. In Visual Studio 2008, there are rare occasions when developers might expect a delegate or interface to behave one way, only to find that it does not conform to their expectations. In Visual Studio 2010 delegates will behave as expected. Other C# types support have always automatically supported covariance and contravariance. C# 4.0 will simply ensure that generic delegates and interfaces follow suit.

Consider this simple class hierarchy:

class Animal{ }
class Cat: Animal{ }

Here we have a class called Animal, and a simple descendant of it called Cat. Suppose you declare a delegate declaration that defines a method that returns an arbitrary type:

delegate T Func1<T>();

An instance of this delegate could be defined to return a Cat:

Func1<Cat> cat = () => new Cat();

The delegate declaration shown here defines a delegate that returns a type T. The second line of code initializes T to be of type Cat and assigns this delegate to a simple lambda that creates an instance of a cat and returns it. For those of you not yet comfortable with lambda syntax, I’ll add that the lambda shown here is simply a shorthand way of writing a method that looks like this:

public Cat MyFunc()
{
    return new Cat();
}

So one could also have written the cat delegate like this:

Func1<Cat> cat = MyFunc;

Given either of these declarations, our intuition tells us that we could assign a cat to a delegate that returns an Animal:

Func1<Animal> animal = cat;

This code looks like it should succeed because a Cat is type of Animal, and one should always be able to assign a smaller type of object, such as a Cat, to a larger type of object, such as a Animal. We think of the type Animal as being large, since a creature such as a Cat, Dog, Whale or Bird would be a type of Animal, and hence compatible with it. In other words, a big type like an Animal is assignment compatible with lots of smaller types, such as a Cat, Dog or Whale. We think of the type Cat as being smaller than an Animal, since only other cats can be assigned to it. It is not assignment compatible with as wide a range of types as an Animal, and hence we think of it as being smaller.

In fact, the assignment shown above does not work in Visual Studio 2008. The new feature being added in Visual Studio 2010 ensures that this assignment will work if you make one minor change to the declaration for your delegate. In particular, you need to use the keyword out in your type parameter:

delegate T Func1<out T>();

Now the assignment will succeed, and the code will run as expected, as shown in Listing 1. This type of assignment is called covariance.

Listing 1: Examples of covariance and contravariance.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SimpleVariance
{
    class Animal { }
    class Cat: Animal { }

    class Program
    {
        // To understand what the new CoVariance and ContraVariance code does for you
        // Try deleting or adding the words out and in from the following 2 lines of code:
        delegate T Func1<out T>();
        delegate void Action1<in T>(T a);

        static void Main(string[] args)
        {
           // Covariance
            Func1<Cat> cat = () => new Cat();
            Func1<Animal> animal = cat;

            // Contravariance
            Action1<Animal> act1 = (ani) => { Console.WriteLine(ani); };
            Action1<Cat> cat1 = act1;
        }        
    }
}

Looking at Listing 1, you will notices that there is a second example included in it. This second example illustrates contravariance. Most developers, including myself, find contravariance more difficult to understand than covariance. It is, however, a similar concept.

The second example starts out by including a delegate declaration. This time the declaration defines a method that takes a parameter, rather than returning a value:

delegate void Action1<in T>(T a);

Notice also that we use the keyword in, rather than the keyword out. That is because we are passing a parameter in, rather than returning a result “back out” of a function.

Next we define a delegate that takes an animal as a parameter:

Action1<Animal> act1 = (ani) => { Console.WriteLine(ani); };

In the contravariant example shown in Listing 1, the assignment of act1 to the delegate cat1 would fail if we did not include the keyword in when declaring the Action1 delegate type. Here is the assignment:

Action1<Cat> cat1 = act1;

This would fail in C# 3.0 no matter what you did. It will work in C# 4.0 so long as you use the keyword in when declaring the delegate type Action1. If you omitted the keyword, then it would fail. For instance, the following declaration of Action1 would cause the assigned to fail because the keyword in is omitted:

delegate void Action1<T>(T a);

Contrast this declaration with the one in Listing 1.

In the contravariant example we use a lambda to define a method that is equivalent to a standard method that looks like this:

public static void Contra(Animal ani)
{
Console.WriteLine(ani);
}

I’m using lambdas in Listing 1 simply to keep the code short, not because lambdas are connected to covariance and contravariance. This code would still illustrate covariance and contravariance whether or not I used lambdas. What is important here is not the presence of lambdas, but the presence of a generic delegate.

Finally, lets take one moment to make sure you understand why the assignment of act1 to cat1 works. The peculiar thing about contravariance is that it appears that we are assigning a larger type to a smaller type. In other words, it appears that we are trying to fit a big thing like an Animal, into a small type like a Cat. This is not what we are doing. The point here is that act1 will work with any animal, and a Cat is animal, therefore you can safely make the assignment. In other words, cat1 can only be passed Cats, and all cats are animals, therefore anything you can assign to cat1 could also be safely passed to act1. This is why the assignment should work, and does in fact work if you use the keyword in.

As I say, contravariance is a bit confusing. If you find the subject a bit much, then you are joining a happy throng of other developers who struggle with the subject. My suggestion is just to relax, think about the example I’ve shown here for a bit, and you will probably have an “ah-ha” moment either in the next few moments, or sometime in the hopefully very lengthy remainder of your life.

Almost everyone who has written or talked about this subject, from Eric Lippert to Anders himself, points out that this technology is not so much an innovation as a means of bringing C# in line with developers expectations. Adding support for covariance and contravariance to generic interfaces and delegates simply ensures that the language behaves as many would intuitively expect it to behave. All you have to do is remember to add the the keywords in or out when you are making an assignment that involves delegates or interfaces, and the language isn’t behaving as you would expect it to behave.

I apologize for focusing only on delegates in this post. Hopefully I’ll find the time to come back and illustrate the same subject using interfaces. I should add that all the code shown here is written against a very shaky pre-beta version of the C# 4.0, and it is always possible, though that not necessarily likely, that this technology will change before it ships.

Community Convergence XLVI

Charlie Calvert — Sun, 26 Oct 2008 09:40:48 GMT

Welcome to the forty-sixth Community Convergence. There are three upcoming events for members of the C# team. The most important, PDC, will be held in Los Angeles over the week of October 26. The weekend before the conference, there will be a Code Camp in Los Angeles. One week after the PDC, there will be a Tech Ed in Spain.

Code Camp in Los Angeles

Members of the team will be at the Code Camp in Los Angeles

Talk: Essence of LINQ
- Speaker: Charlie Calvert
- Room: GFS 116
- Time 9 AM
Talk: C# 3.0 features and how to (ab)use them
- Speaker: Sam Ng
- GFS 116
- Time: 10:15 AM
How LINQ Words
- Speaker: Alex Tuner
- Room: SLH 102
- Time: 12:30 PM

PDC

The following list includes talks by members of the C#, VB, F#, IronPython and IronRuby teams that will be given at PDC.

TL16: The Future of C#
- Anders Hejlsberg
- Mon 10/27 | 1:45 PM-3:00 PM | Petree Hall CD
- Repeated: Wed 10/29 | 3:00 PM-4:15 PM | 502A
TL10: Deep Dive: Dynamic Languages in .NET
- Speaker: Jim Hugunin
- Mon 10/27 | 3:30PM | 502A
TL11: An Introduction to Microsoft F#
- Speaker: Luca Bolognese
- Thu 10/30 | 1:45 PM-3:00 PM | 502A
TL12: Future Directions for Microsoft Visual Basic
- Speaker: Paul Vick
- Tue 10/28 | 5:15 PM-6:30 PM | 406A
TL46: Microsoft Visual C# IDE: Tips and Tricks
- Dustin Campbell
- Mon 10/27 | 12:45-13:30 | 403AB
TL54: Natural Interop with Silverlight, Office and Python
- Alex Turner
- Tue 10/28 | 12:45 PM-1:30 PM | 404A
TL57: A Panel on the Future of Programming Languages
- G. Bracha, D.Crockford, A. Hejlsberg, E. Meijer, W.Schulte, J. Siek
- Wed 10/29 | 10:30 AM-11:45 AM | 403AB
TL44 IronRuby: The Right Language for the Right Job
- Speaker: John Lam
- Mon 10/27, 5:15PM, 515B

Tech Ed Europe (EMEA)

Here are some talks by the C# and VB teams that will be given at Tech Ed EMEA.

How LINQ Works in C#
- Speaker: Alex Turner
New Features in C# 3.0
- Speaker: Mads Torgersen
Visual C# IDE Tips and Tricks
- Speaker: Karen Liu
The Future of C#
- Speaker: Mads Torgersen
The Joy of Writing Code in Visual Studio 2010
- Speaker: Karen Liu
Talk: Future Directions for Visual Basic
- Speaker: Jonathan Aneja
Talk: Strategies for Upgrading Visual Basic 6.0 to .NET
- Speaker: Paul Yuknewicz, Jonathan Aneja
Microsoft Visual Basic 2008 Tips and Tricks
- Speaker: Lisa Feigenbaum
How LINQ Works in VB
- Speaker: Jonathan Aneja
Conquering XML with Visual Basic 9.0
- Speaker: Lisa Feigenbaum

LINQ Farm: Preserving Formatting with LINQ to XML

Charlie Calvert — Tue, 30 Sep 2008 09:02:10 GMT

In a previous post, you saw how to work with line numbers when using LINQ to XML to read a file. This post continues in the same vein, but this time the focus is on how to:

Read in an XML file with an arbitrary format, and then write it back out to disk in exactly the same format.
Read in an XML file with an arbitrary format, and write it back out with standard formatting

Some scenarios where you might need this functionality include reading a document from one location and writing it to another location, or reading in a document, editing it, and writing it back out with new data, but the same format.

You can download the source for the code shown in this post.

How to Preserve Formatting

Consider the following block of XML:

<?xml version="1.0" encoding="utf-8" ?>
<alpha><beta> 
 sam 
</beta></alpha>

This document has an extremely idiosyncratic layout. Tags are nested on the same line and a text field stands on its own surrounded by linefeeds. If you wish to read in and write this document back out with the formatting preserved, here is how to proceed:

XDocument x = XDocument.Load(readFileName, LoadOptions.PreserveWhitespace);
x.Save(writeFileName, SaveOptions.DisableFormatting);

When calling XDocument.Load, pass in the LoadOptions.PreserveWhitespace flag from the following enumeration:

public enum LoadOptions
{
  None = 0,
  PreserveWhitespace = 1,
  SetBaseUri = 2,
  SetLineInfo = 4
}

When writing the document back out to disk, use SaveOptions.DisableFormatting, from the following enumeration:

public enum SaveOptions
{
  None = 0,
  DisableFormatting = 1
}

If you take these two steps, then the XML you write to disk will have the same formatting as the document you read in.

Modifying Oddly Formatted XML

If you read in XML that has an odd format, it is likely that linefeeds play a role in that formatting. Suppose we want to modify the XML document shown previously so that it looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<alpha><beta>
  Sue  
</beta></alpha>

The value sam from the original document has been replaced with the word Sue. To make this substitution properly, you need to take care to preserve the linefeeds in the original document. In this example I show a relatively mindless way to preserve linefeeds. For good measure, I also add in code for working with line numbers.

XDocument x2 = XDocument.Load(readFileName,
    LoadOptions.PreserveWhitespace | LoadOptions.SetLineInfo);

XText value = (from c in x2.Elements().DescendantNodes().OfType<XText>()
               where c.Value.Trim().Length > 0
               select c).Single();

IXmlLineInfo x = (IXmlLineInfo)value;
Console.WriteLine("Line Number: {0}", x.LineNumber);
value.Value = Environment.NewLine + "  Sue  " + Environment.NewLine;

x2.Save(createFileName, SaveOptions.DisableFormatting);

This code reads in the original XML file with the PreserverWhitespace flag. I've also OR'd in the LoadOptions.SetLineInfo flag. I do this not because I have any real need to do so, but simply so you can see how to pass in two flags to the Load method.

The next block of code queries the document for all the text nodes that consist of something more than pure white space. I then output the line number of the node that was found. Finally, I modify the node, replacing the original text with the word Sue:

value.Value = Environment.NewLine + " Sue " + Environment.NewLine;

To modify the node, I simply replace the Value property with new text. Note that the code explicitly adds in a pair of linefeeds to preserves the original, idiosyncratic formatting. If you are confused about what is happening here, look up again at the original document. It begins with two tags:

<alpha><beta>

Then there is a linefeed, the word sam, and another linefeed and finally the closing tags:

</beta></alpha>

The code I've written simply preserves those linefeeds. I'm doing this not because I think it is a good idea to include white space like this in a document, but simply to show you that it is possible to preserve it if you have a need or desire to do so.

After modifying the document, the XML is written back to disk using the same technique explained in the previous section.

Cleaning Up XML

If you discover an XML file that has idiosyncratic formatting that you want to remove, LINQ to XML makes it fairly easy to clean up such a document. By default, LINQ to XML will write out a document with proper formatting. All you have to do is use the Load and Save methods without any of the LoadOptions or SaveOption flags shown in the previous two sections:

XDocument x2 = XDocument.Load(readFileName);
x2.Save(createFileName);

This code will not, however, remove arbitrary white space from a text node. For instance, the text node described above that begins and ends with a linefeed will still have linefeeds when you write the document back out. This may be exactly what you want. On the other hand, you may feel it leaves your document in a pretty ugly state. Here is how to clean up the problem

XDocument x2 = XDocument.Load(readFileName);

var query = from c in x2.Elements().DescendantNodes().OfType<XText>()
            select c;

foreach (var item in query)
{
    item.Value = item.Value.Trim();
}

x2.Save(createFileName);

This code finds all the text nodes in the document and strips away their white space with standard string Trim method. When you are done, you can write the document back out to disk. It will now have the clean formatting you expect:

<?xml version="1.0" encoding="utf-8"?>
<alpha>
  <beta>sam</beta>
</alpha>

Finally, if you want to strip away all white space, and end up with a document that sits on a single line, you can write code that looks just like the listing shown earlier in this section, except that the the call to Save the document should look like this:

x2.Save(createFileName, SaveOptions.DisableFormatting);

The output you create will appear all on one line, like this:

<?xml version="1.0" encoding="utf-8"?><alpha><beta>sam</beta></alpha>

If you did not clean up the text nodes as shown above, then your code would end up with linefeeds in it from the text nodes. The result, in our case, would look like this:

<?xml version="1.0" encoding="utf-8"?><alpha><beta>
  sam  
</beta></alpha>

The point here is that DisableFormatting turns off LINQ to XML’s attempts to format your code properly. If you read in strangely formatted code, then using this flag will preserve that idiosyncratic formatting. If you read in code with no attempt to preserve the original formatting, as we do in this section, then writing to disk with this option will end up stripping away all formatting, and leaving you with code all on one line except for white space in a text node.

Working with Text Files

In this post I've focused on reading in and writing XML files using the LINQ to XML API. It's perhaps useful to recall that you can also use standard .NET IO in order to perform similar tasks. This can be particularly helpful when you are testing your code, and want to be sure that your LINQ to XML routines are behaving as expected.

Here is a simple routine for reading in a XML file, or any other text file:

private static void ReadAsText(string fileName)
{
    string s = File.ReadAllText(fileName);
    Console.WriteLine(s);
}

And here is the C# call for writing a file to disk:

File.WriteAllText

If you download the sample code associated with this post, you will see that I use these routines to confirm that my code is working correctly.

Summary

In this post you've seen how to preserve white space in an XML document, and how to strip it out and return to standard formatting. You also had a chance to learn how to edit an idiosyncratically structured XML document without changing its format.

Download the source.

LINQ Farm: LINQ to XML and Line Numbers

Charlie Calvert — Fri, 26 Sep 2008 23:13:01 GMT

There are times when it is useful to know the line number of a node in an XML file. This information can be a helpful to users, particularly if you want to report an error. It can also be convenient to search for a node by line number, but that can, of course, be a very risky endeavor, as documents can be modified accidentally, and their line numbers changed without notice.

This post shows a few fundamentals about working with line numbers in a LINQ to XML program. The code shown in this post is taken from a project called XmlLineNumber. You can download this program from the LINQ Farm on Code Gallery.

Reporting a Line Number

Let’s begin our exploration by detailing a technique for reporting the number of a node that you have found in an XML file. To get started we need to use code from a class called XObject. As shown in Figure 1, XObject sits at the top of the LINQ to XML class hierarchy.

Figure 1: The core objects in the LINQ to XML class hierarchy

XObject implements an interface called IXmlLineInfo:

public interfaceIXmlLineInfo
{
    int LineNumber { get; }
    int LinePosition { get; }
    bool HasLineInfo();
}

The eponymous LineNumber property of this interface is able to store the information we want. To enlist it in our service we need only call XDocument.Load with LoadOptions.SetLineInfo:

XDocument xml = XDocument.Load(fileName, LoadOptions.SetLineInfo);

If you load this XML file into memory using SetLineInfo from the LoadOptions enumeration, then line numbers will be associated with the nodes in your document. The file we are loading is called FirstFourPlanets.xml. It’s a sweet little file that looks like this:

<?xmlversion="1.0" encoding="utf-8"?>
<Planets>
<Planet>
    <Name>Mercury</Name>
    <Moons/>
</Planet>
<Planet>
    <Name>Venus</Name>
    <Moons/>
</Planet>
<Planet>
    <Name>Earth</Name>
    <Moons> <Moon>
        <Name>Moon</Name>
        <OrbitalPeriod UnitsOfMeasure="days">27.321582</OrbitalPeriod>
      </Moon>
    </Moons>
</Planet>
<Planet>
    <Name>Mars</Name>
    <Moons>
      <Moon>
        <Name>Phobos</Name>
        <OrbitalPeriod UnitsOfMeasure="days">0.318</OrbitalPeriod>
      </Moon>
      <Moon>
        <Name>Deimos</Name>
        <OrbitalPeriod UnitsOfMeasure="days">1.26244</OrbitalPeriod>
      </Moon>
    </Moons>
</Planet>
</Planets>

Here is code that uses the IXmlLineInfo interface to report the line number of a node discovered through a standard LINQ to XML search:

XText phobos = (from x in xml.DescendantNodes().OfType<XText>()
                where x.Value == "Phobos"
                select x).Single();

var lineInfo = (IXmlLineInfo)phobos;
Console.WriteLine("{0} appears on line {1}", phobos, lineInfo.LineNumber);

This code looks through all the descendants of the root node for nodes of type XText which are equal to the word Phobos. It uses the LINQ query operator Single to ensure that the query returns only a single node. If the query returned more than one result, the call to Single would raise an exception, which in this case is the behavior we want. The program then casts the result as an instance of IXmlLineInfo, and reports the line number to the user:

Phobos appears on line 24

Searching by Line Number

Let's now turn things around and show how to search through an XML file and look for a node by line number. If you glance at the FirstFourPlanets.xml file, you will see that line 21 looks like this:

<Name>Mars</Name>

Here is code from the XmlLineNumbers sample showing how to search for that node by line number:

XDocument xml = XDocument.Load(fileName, LoadOptions.SetLineInfo);

var line = from x in xml.Descendants()
           let lineInfo = (IXmlLineInfo)x
           where lineInfo.LineNumber == 21
           select x;

foreach (var item in line)
{
    Console.WriteLine(item);
}

Note that the first line uses LoadOptions.SetLineInfo to ensures that line information is recorded when the document is loaded into memory.

The LINQ query shown here uses Descendants to iterate over the elements in the FirstFourPlanets.xml file. The where filter in the query checks to see if any of those elements has its line number set to 21. It happens that the 15^th element returned by the call to Descendants fits that search criteria, and so that node, and that node alone, is found when we foreach over the results.

Notice the cast to convert the XElement nodes returned by the call to Descendants:

let lineInfo = (IXmlLineInfo)x

This cast is necessary, since the actual fields of the IXmlLineInfo interface are not exposed by XElement.

Once again, I want to stress that reporting the line number of a node seems like a reasonable thing to do, but searching for an element by line number is usually not a good idea in production code. For unexplained reasons, code that was on line 532 has a way of migrating to line 533 when you least expect it. In any case, you now know enough to begin working with line numbers in a LINQ to XML program.

Download the source.

Charlie to Speak on LINQ at DevLink

Charlie Calvert — Tue, 19 Aug 2008 08:12:50 GMT

I will be speaking this Friday and Saturday, August 22nd and 23rd, at devLink near Nashville, TN. I will give two talks, both on LINQ, both for intermediate and advanced developers. The first covers querying in LINQ, and the second talk explains the features of C# 3.0 that make LINQ possible.

Essence of LINQ Part I

Query expressions are the primary tool for writing LINQ queries. This talk will explore the syntax for writing query expressions. It will also explore a number of the most important LINQ operators. The 7 different types of LINQ clauses will be covered, as well as the 4 different ways to introduce range variables, the different means of creating a LINQ join, and the role of composition in LINQ. Some of the operators that will get special attention include Join, SelectMany, GroupBy, OrderBy and the Aggregate and Set operators. This talk digs into some intermediate and advanced issues, and I assume that most attendees know at least a little about LINQ.

Essence of LINQ Part II

To enable LINQ, C# 3.0 introduces a number of new language features such as query expressions, lambda expressions, extension methods, automatically implemented properties, local type inference, expression trees and more. These are all features that can improve the quality of your code. They also provide new opportunities for making mistakes This talk will explore these features and outline best practices for using them.. Each feature will be introduced with an example illustrating how it contributes to the overall LINQ architecture.

The materials for my talk are on the LINQ Farm on Code Gallery. To download them directly, click here.

Released: Visual Studio Service Pack 1; .NET 3.5 Service Pack 1

Charlie Calvert — Mon, 11 Aug 2008 21:03:25 GMT

Visual Studio Service Pack 1 and .NET 3.5 Service Pack 1 are now available for download. A new feature for C# developers called squiggles provides better error messages while you are typing your code. There are several important LINQ performance enhancements, including one that could yield a 30% speed increase in some common scenarios. There are also thousands of other bug fixes.

A general description of these releases is available here. It describes Visual Studio and .NET 3.5 changes such as:

Improvements to the WPF designers, and core WPF performance.
SQL 2008 support
Entity Framework support.

Download

A download page is available here, or you can just follow these links:

VS 2008 Service Pack 1:

Executable: http://go.microsoft.com/fwlink/?LinkId=122094 (Direct Link)
Iso: http://go.microsoft.com/fwlink/?LinkId=122095 (Direct Link)

VS 2008 Express Editions with Service Pack 1:

Executable: http://go.microsoft.com/fwlink/?LinkId=123679
ISO: http://go.microsoft.com/fwlink/?LinkId=123680

VS Team System 2008 Team Foundation SP 1:

http://go.microsoft.com/fwlink/?LinkId=124829

.NET Framework 3.5 Service Pack 1:

http://go.microsoft.com/fwlink/?LinkId=124150

LINQ Farm: More on the LINQ Aggregate Operators

Charlie Calvert — Fri, 25 Jul 2008 04:00:17 GMT

The LINQ aggregate operators allow you to perform simple math operations over the elements in a sequence. This post is designed to walk you through those operators, and give you an overview of how to use them. Table 1 shows a list of the 7 aggregate operators.

Note: All the samples shown in this post are found in the AggregateOperators program found on Code Gallery LINQ Farm.

Table 1: LINQ includes 7 aggregate operators designed to help you perform simple math operations. The definitions shown in this table are over-simplifications that give you a general sense of what you can do with a particular operator.

Count	Count the elements in a sequence.
LongCount	Count the elements in a very, very long sequence.
Sum	Add the elements in a sequence
Min	Find the smallest element in a sequence
Max	Find the largest element in a sequence
Average	Find the average value in a sequence
Aggregate	Perform various binary operations on the elements in a sequence.

Except for the Aggregate operator itself, all of these operators have a simple, obvious default use. Several of these operators, do, however, have overloads that need a few sentences of explanation. I will show you one simple example of using the default behavior for the operators, and then dive a bit deeper with a second example that shows how to use at least one of the overloads.

The Count and LongCount Operators

The Count and LongCount operators return the number of elements in a sequence. The Count operator can find this number quickly by simply asking objects such as List<T> that support the ICollection<T> interface for the count. If that service is not available, then LINQ iterates over the items in a list to get the count. The LongCount operator provides the same basic functionality, but allows you to work with an Int64. A simple example of using the Count operator is shown in Listing 1.

Listing 1: A simple example of using the Count and LongCount operators.

public void ShowCount()
{
    var list = Enumerable.Range(5, 12);
    Console.WriteLine(list.Count());
}

The overloads for Count and LongCount allow you to pass in a lambda expression that performs custom calculations from which LINQ can derive the count for a sequence. For instance, you can write code that returns the number of even numbers in a collection:

var list = Enumerable.Range(1, 25);

Console.WriteLine("Total Count: {0}, Count the even numbers: {1}",
    list.Count(), list.Count(n => n % 2 == 0));

Our list consists of the numbers between 1 and 25. We call count once with the first version of the Count operator and get back the number 25.

The second overload of the Count operator takes a simple predicate. The declaration looks like this:

public static int Count<TSource>(this IEnumerable<TSource> source,
   Func<TSource, bool> predicate);

The predicate takes an integer and returns a bool specifying whether or not a particular value from the list passes a test. In our case, we simple ask whether or not the number is even. This computation will return the values 2, 4, 6 and so on up to 24, for a total of 12 elements.

The Min and Max Operators

The Min and Max operators are equally simple. Listings 2 and 3 show how it works. The first shows the behavior of the first overload of Min and Max, the second shows how to one of the other overloads to pose slightly more complex questions.

Listing 2: A simple example of using the Min and Max operators to determine and highest and lowest values in a sequence.

public void ShowMinMax()
{
    var list = Enumerable.Range(6, 10);
      Console.WriteLine("Min: {0}, Max: {1}", list.Min(), list.Max());
}

Our list consists of the number 6 through 15, so the code writes out the values 6 and 15 to the console.The C# source that implements Min and Max use the IComparable<T> or IComparable interfaces to perform the calculations. If you pass in a null argument you will get an ArgumentNullException.

For the more complex examples, I'm going to need a few rows of simple data, which I provide in Listing 3.

Listing 3: The following Item class and the GetItems method are used by most of the examples in this section of the text.

class Item
{
    public int Width { get; set; }
    public int Length { get; set; }

    public override string ToString()
    {
        return string.Format("Width: {0}, Length: {1}", Width, Length);
    }
}

private List<Item> GetItems()
{
    return new List<Item> 
    { 
       new Item { Length = 0, Width = 5 },
       new Item { Length = 1, Width = 6 },
       new Item { Length = 2, Width = 7 },
       new Item { Length = 3, Width = 8 },
       new Item { Length = 4, Width = 9 }
    };
}

There is no simple way to know maximum or minimum values from a list of Items. To find the largest Item do you choose the element with the greatest Length, the greatest Width, or some other value? To solve this problem the C# teams provided us with an overload of the Min and Max operators that take a delegate that we can use to select the proper value for the comparison:

public static int Max<TSource>(this IEnumerable<TSource> source, Func<TSource, int> selector);

Like nearly all the LINQ to Objects operators, Max is implemented as an extension method for the class IEnumerable<T>. It takes an extremely simple lambda that is passed an element from the enumeration and returns an integer. To see how this works, take a look at Listing 4.

Listing 4: A somewhat more complex use of Min and Max, demonstrating how to get minimum and maximum values for complex types with multiple fields.

List<Item> items = GetItems();
ShowList(items);
Console.WriteLine("MinLength: {0}, MaxLength: {1}", 
   items.Min(l => l.Length ), items.Max(l => l.Length));

As you can see, Min and Max both take a very simple delegate, which is implemented here as a lambda.

The lambda that is passed to Min looks like this: l => l.Length. This is lambda is so simple that it can be a bit confusing to people who are new to LINQ. Let's take one moment to be sure we understand what is happening.

We know that this LINQ operator must iterate over the sequence passed in to it, and we can assume that it passes each item it finds to the selector delegate. It then tests the result returned from selector, to see if it is the largest value returned. Without peeking at the real source code, it seems that Max might do something like the code in listing 5.

Listing 5: This method, which I created, mimics what occurs in the real Max method that ships with the C# 3.0 release.

public static class MyExtensions
{
    public static int Max<TSource>(this IEnumerable<TSource> source
      Func<TSource, int> selector)
    {
        int largest = int.MinValue;
        foreach (var item in source)
        {
            int nextItem = selector(item);
            if (nextItem > largest)
            {
                largest = nextItem;
            }
        }
        return largest;
    }

Assuming that we are working with a collection of Items, then selector, were it implemented as a standard method, would have to look something like this:

public int selector(Item item)
{
    return item.Length;
}

This method is semantically identical to the delegate we used in listing x: l => l.Length. It is very simple code that tells us which part of the Item class we are going to use to determine our max value.

It's all so simple that one feels a little like a character in Edgar Allan Poe's "The Purloined Letter:" the answer was hidden in plain sight. Once again we see that the biggest impediment to learning LINQ is the fear that it might be complicated. In practice, it is almost startlingly simple.

The Average Operator

Once one understands the pattern shown in our examination of the Min and Max operators, we find that it can be easily applied to most of the other Aggregate operators. Let’s look at the Average operator, which returns the average value from an enumeration.

For instance, one can find the average for a range of numbers like this:

var list = Enumerable.Range(0, 5);
  Console.WriteLine("Average: {0}", list.Average());

When run, this code tells us that the average of the numbers 0, 1, 2, 3, 4 is the value 2.

When working with a collection of Items, we face the same problem we had with Min and Max: How does one discover the average value for list of Items that define two properties called Length and Width? The answer, of course, is that proceed just as we did with Min and Max operators:

List<Item> items = GetItems();

double averageLength = items.Average(l => l.Length);
double averageWidth = items.Average(w => w.Width);
double averageValue = items.Average(v => v.Length + v.Width);
Console.WriteLine("AverageLength: {0}, AverageWidth: {1} AverageValue: {2}", averageLength, averageWidth, averageValue);

Again, we pass in very simple lambdas such as l => l.Length + l.Width or w => w.Width. Somewhere in the background code similar to what you see in the custom implementation for the Max operator found in listing 5.X. The code must iterate over the list, passing in each item to our lambda, which defines the value we want the Average operator to use in its calculations:

AverageLength: 2, AverageWidth: 7 AverageValue: 9

The Sum Operator

The Sum operator tallies the values in an enumeration. Consider the following simple example:

var list = Enumerable.Range(5, 3);
Console.WriteLine("List sum = {0}", list.Sum());

Our list consists of the numbers 5, 6 and 7. The Sum operator adds them together, producing the value 18.

working with a list of Items, the Sum operator faces the same problem we saw with the Min, Max and Average operators. It should come as no surprise that the solution is nearly identical:

var items = GetItems(); 
Console.WriteLine("Sum the lengths of the items: {0}", items.Sum(l => l.Length));

Here is the same pattern you saw with the Average, Min and Max operators: we pass in a simple lambda to help the Sum method know which part of an Item it should use as the operand when performing its simple addition. The result printed to the console is the value 10. If only the rest of our lives were quite this simple!

The Aggregate Operator

The Aggregate operator follows in the footsteps of the Sum operator, but it provides us with a few more options. Rather than taking a simple delegate like the other operators in this series, it asks for one similar to the lambda we worked with in a previous post:

public static T Aggregate<T>(this IEnumerable<T> source, Func<T, T, T> func);

We know what do to with delegates that looks like this. We could, for instance, create one that adds up a range of numbers:

var list = Enumerable.Range(5, 3);
Console.WriteLine("Aggregation: {0}", list.Aggregate((a, b) => (a + b)));

The aggregate operator gets passed the numbers 5, 6 and 7. The first time the lambda is called it gets passed 5 and 6, and adds them together to produce 11. The next time it is called it is passed the accumulated result of the previous calculation plus the next number in the series: (11 + 7) which yields 18. This is the same result we saw for the Sum operator in the previous section. This overload of the Aggregate operator is indeed very similar to the Sum operator, though it is more flexible, in that you can easily perform multiplication, division, subtraction and other operations instead of simple addition. For instance, this code performs multiplication, yielding the value 210:

list.Aggregate((a, b) => (a * b))

Before pushing on, I should backtrack a little and discuss two simple points that are often brought up when people talk about this first version of the Aggregate operator. If it is passed a list with one item, it returns that item. If it is passed a list with 0 items, it throws an InvalidOperationException.

A second overload of the Aggregate operator allows you to seed the process with an accumulator:

public static TAccumulate Aggregate<TSource, TAccumulate>(
    this IEnumerable<TSource> source, TAccumulate seed, 
    Func<TAccumulate, TSource, TAccumulate> func);

This is essentially the same operator as shown in the previous example, but now you can decide the starting point for the value that will be accumulated:

Console.WriteLine("Aggregation: {0}", list.Aggregate(0, (a, b) => (a + b)));

If we pass in a list with one item in it, say the number five, then the first time the lambda is called it would be passed the seed plus the sole item in the list:

(0 + 5)

The result, of course, is the number 5.

Suppose we pass in an accumulator of 0 plus the numbers 5, 6, 7.

var list = Enumerable.Range(5, 3);
Console.WriteLine("Aggregation: {0}", list.Aggregate(0, (a, b) => (a + b)));

In this case we would step through the following sequence:

0 + 5 = 5
5 + 6 = 11
11 + 7 = 18.

Again, we are doing essentially what we did with the Sum operator.

If you pass in a different seed, then you get a different result:

Console.WriteLine("Aggregation: {0}", list.Aggregate(3, (a, b) => (a + b)));

With a seed of 3, we get:

3 + 5 = 8
8 + 6 = 14
14 + 7 = 21

As mentioned earlier, the Aggregate operator allows us to perform not just addition, but multiplication, division or various other binary mathematical operations:

Console.WriteLine("Aggregation: {0}", list.Aggregate(1, (a, b) => (a * b)));

In this case the series looks like this:

1 * 5 = 5
5 * 6 = 30
30 * 7 = 210

Note that I passed in an accumulator equal to 1, so that we did not end up with the following series of operations:

0 * 5 = 0
0 * 6 = 0
0 * 7 = 0

In what I sometimes suspect might have been an excess of good spirits, the team added one final overload to the Aggregate operator:

public static TResult Aggregate<TSource, TAccumulate, TResult>(
                this IEnumerable<TSource> source, TAccumulate seed,
                Func<TAccumulate, TSource, TAccumulate> func,
                Func<TAccumulate, TResult> resultSelector);

This overload is nearly identical to the previous overload, but you are given one more, very simple, delegate that you can use to transform the result of your aggregation. For instance, consider this use of the Aggregate operator:

Console.WriteLine("Aggregation: {0}", list.Aggregate(0, (a, b) => (a + b),
    (a) => (string.Format("{0:C}", a))));

Please notice that the first two-thirds of this call mirror what we did earlier, and only the third parameter is new.

Suppose we pass in a sequence with the values 5, 6 and 7. As we've already seen, the process will begin by performing the following series of operations:

0 + 5 = 5
5 + 6 = 11
11 + 7 = 18

Once we have our result of 18, this number is passed to the last lambda in our call. It uses the string's Format method to transform it into a string in currency format:

$18.00

Like nearly everything in LINQ, this seems terribly complicated at first only to end up being reasonably simple. It is these kinds of simple operations, however, which provide us with the building blocks out of which we can safely create complex programs. This is what we mean when we apply the word elegant to a technology.

Note: All the samples shown in this post are found in the AggregateOperators program found on Code Gallery LINQ Farm.

LINQ Farm: More on Set Operators

Charlie Calvert — Sat, 12 Jul 2008 10:47:45 GMT

This is a second post on the LINQ Set operators, the first being published while LINQ was still in beta. As mentioned in the previous post, there are four LINQ set operators: Union, Intersect, Distinct and Except. Like the other 49 LINQ operators, these methods are designed to allow you to query data which supports the IEnumerable<T> interface. Since all LINQ query expressions, and most LINQ queries, return IEnumerable<T>, these operators are designed to allow you to perform set operations on the results of a LINQ query.

In this post I give four highly simplified examples of how to use each of the operators, and then end with a more complex example that shows how the operators might be used in a real world setting.

Download the source code.

Union

The Union operator shows the unique items from two lists, as shown in listing 1.

Listing 1: The Show Union method displays the number 1, 2, 3, 4, 5 and 6.

public void ShowUnion()
{
    var listA = Enumerable.Range(1, 3);
    var listB = new List<int> { 3, 4, 5, 6 };

    var listC = listA.Union(listB);

    foreach (var item in listC)
    {
        Console.WriteLine(item);
    }
}

Here two collections are joined together, but only the unique members of each list are retained.

Intersect

The Intersect operator shows the items that two lists have in common.

Listing 2: The ShowIntersect method displays the numbers 3 and 4

public void ShowIntersect()
{
    var listA = Enumerable.Range(1, 4);
    var listB = new List<int> { 3, 4, 5, 6 };

    var listC = listA.Intersect(listB);

    foreach (var item in listC)
    {
        Console.WriteLine(item);
    }
}

Here to collections are joined together, and only the unique, shared members of each list are retained.

Distinct

The Distinct operator finds all the unique items in a list.

Listing 3: The ShowDistinct method displays the number 1, 2 and 3.

public void ShowDistinct() 
{
    var listA = new List<int> { 1, 2, 3, 3, 2, 1 };
    var listB = listA.Distinct();

    foreach (var item in listB)
    {
        Console.WriteLine(item);
    }
}

Except

The Except operator shows all the items in one list minus the items in a second list.

Listing 4: The ShowExcept method prints out the numbers 1, 2, 5, and 6

public void ShowExcept() 
{
    var listA = Enumerable.Range(1, 6);
    var listB = new List<int> { 3, 4 };

    var listC = listA.Except(listB);

    foreach (var item in listC)
    {
        Console.WriteLine(item);
    }
}

In the Context of LINQ

The type of code listed above is useful, but it might be helpful to see these same operators used in the context of a LINQ query expression. You can then see how they can be used to analyze the results of queries to better understand the data that is returned.

You probably know that there are two similar collections used to create lists. One is the generic List<T> collection and the other is the old-style collection called ArrayList. We can use set operators to help us better understand the difference between these two classes.

Here are two queries retrieving the methods from the List<int> class and the ArrayList class:

var queryList = from m in typeof(List<int>).GetMethods()
                where m.DeclaringType == typeof(List<int>)
                group m by m.Name into g
                select g.Key;

var queryArray = from m in typeof(ArrayList).GetMethods()
                 where m.DeclaringType == typeof(ArrayList)
                 group m by m.Name into g
                 select g.Key;

Here is code to retrieve the interesection of these two lists:

var listIntersect = queryList.Intersect(queryArray);

And here is code that displays the resulting sequence:

Console.WriteLine("Count: {0}", listIntersect.Count());

foreach (var item in listIntersect)
{
    Console.WriteLine(item);
}

Alternatively, you could write the query like this:

var queryList = (from m in typeof(List<int>).GetMethods()
                 where m.DeclaringType == typeof(List<int>)
                 group m by m.Name into g
                 select g.Key).Intersect(from m in typeof(ArrayList).GetMethods()
                                         where m.DeclaringType == typeof(ArrayList)
                                         group m by m.Name into g
                                         select g.Key);

In either case, the following list would be displayed:

get_Capacity
set_Capacity
get_Count
get_Item
set_Item
Add
AddRange
BinarySearch
Clear
Contains
CopyTo
GetEnumerator
GetRange
IndexOf
Insert
InsertRange
LastIndexOf
Remove
RemoveAt
RemoveRange
Reverse
Sort
ToArray

And here is how to see the items that the generic lists supports that are not part of the old style collection:

var listDifference = queryList.Except(listIntersect);

And here is the result of this query:

ConvertAll
AsReadOnly
Exists
Find
FindAll
FindIndex
FindLast
FindLastIndex
ForEach
RemoveAll
TrimExcess
TrueForAll

Now you have a list of the methods the two classes share in common, and a list showing what the new generic class has that is not part of the older collection. The LINQ set operators made it easy for you to discover this information.

Download the source code.

LINQ Farm: Lambdas

Charlie Calvert — Sat, 28 Jun 2008 11:35:55 GMT

Lambdas are a simple technology with an intimidating name. They sound like they are going to be difficult to understand, but in practice prove to be relatively trivial.

LINQ has an almost inordinate need for its users to declare a large number of small, simple delegates. The architects of C# decided that forcing the users of LINQ to declare delegates using standard C# 2.0 delegate syntax was an overly verbose option. They wanted to find a shorter, more concise way to accomplish the same task.

The syntax they settled on looks like this:

Func<int, int, int> myLambda = (a, b) => (a + b);

This is a shorthand way of writing code which is semantically equivalent to the following:

public static int Add(int a, int b)
{
    return a + b;
}

Func<int, int, int> myDelegate = Add;

In the next few paragraphs I will compare these two ways of creating a delegate instance, and explain how they map back and forth.

It is obvious that the left hand side of the following two code fragments have the same meaning:

Func<int, int, int> myLambda = (a, b) => (a + b);
Func<int, int, int> myDelegate = Add;

But how can the right hand side be the same?

It turns out that that the expression on the right hand side of the first statement is a shorthand way of writing a method semantically equivalent to the Add method. Just to be clear, a lambda is not a reference to the Add method, it is second method that does the same thing as the Add method.

Here is the lambda:

(a, b) => (a + b);

And here is the Add method:

public static int Add(int a, int b)
{
    return a + b;
}

Here is the place in the Add method where we define the parameters it will take:

(int a, int b)

Here is the place in the lambda where we define the parameters that it will take:

(a, b)

Here is the place in the Add method where we define what it will return:

return a + b;

Here is the place in the lambda where we define what it will return:

(a + b)

As you can see, a lambda and a method do the same thing: they define a set of parameters and an executable body of code.

The type declarations for a lambda are resolved using a technique very similar to the one we employ for generic methods and generic delegates. To see how this works, look again at the full declaration for the lambda:

Func<int, int, int> myLambda = (a, b) => (a + b);

The generic delegate Func says that the method being implemented takes two integers as parameters, and returns an integer. The compiler takes this information and applies it to the lambda. Behind the scenes it resolves (a, b) to (int a, int b) and defines the function such that the body of the lambda (a + b) returns an integer. Thus we give the compiler enough information to convert our lambda into a method that performs the same action as the Add method.

The => symbol is called a lambda operator and is usually pronounced “goes to.” Thus the lambda above can be read as “a comma b goes to a plus b,” or “a and b goes to a plus b.”

Though you will rarely need to do so, you can explicitly declare the type of parameters to a lambda expression:

Func<int, int, int> f = (int a, int b) => (a + b);

For void functions that do not return a value, just use an empty set of parenthesis:

() => Console.WriteLine();

Lambdas have access to local variables:

public static void UseLocal()
{
    int n;
    Func<int> func = () => { n = 6; return n; };
    n = func();
    Console.WriteLine(n); // Outputs the number 6
}

You might be familiar with anonymous methods from C# 2.0. Semantically, anonymous methods and lambdas are identical, but the lambda syntax is easier to use. As a result, there is probably no reason for you to use anonymous methods in the future. Below is a lambda and anonymous method side by side:

Func<int, int, int> myLambda = (a, b) => (a + b);
Func<int, int, int> myAnonMethod = delegate(int a, int b)
{
    return a + b;
};

Both methods take two integers, add them together, and return the result. Commenting further on anonymous methods at this point would serve no purpose, since lambdas create the same result with less work.

In this post you have had a chance to look at lambdas. Their name is intimidating, and their syntax can be a bit confusing at first. Once you see beneath the facade however, this technology turns out to be relatively easy to master.

LINQ Farm: Extension Methods and Scoping

Charlie Calvert — Sat, 28 Jun 2008 11:17:15 GMT

There are a few scoping rules that you must keep in mind when using extensions methods. Problems with scoping and extensions methods are rare, but when you encounter them they are quite vexing.

An instance method will always be called before an extension method. The runtime looks first for an instance method, if it finds an instance method with the right name and signature, it executes it and never looks for your extension method. The following code illustrates this problem:

using System;

namespace ConsoleApplication1
{
    public class MyClass
    {
        public void DoThis()
        {
            Console.WriteLine("MyClass.DoThis");
        }
    }


    public static class MyExtensions01
    {
        // Can never be called as if it were an instance method of MyClass.
        public static void DoThis(this MyClass myClass)
        {
            Console.WriteLine("MyExtensions01.DoThis");
        }
    }


    class Program
    {
        static void Main(string[] args)
        {
            MyClass myClass = new MyClass();
            myClass.DoThis();                // Calls MyClass.DoThis
            MyExtensions01.DoThis(myClass);  // Calls MyExtensions01.DoThis
        }
    }
}

MyExtensions01.DoThis is a valid extension method for MyClass. However, it will never be called because MyClass.DoThis always takes precedence over it unless you explicitely call it as a static method of MyExtensions01.

In cases where you have two extension methods with the same name, an extension method in the current namespace will win out over one in another namespace. Ambiguity will become an issue, however, when you try to call two extension methods with the same name and signature in the same namespace, or in two different namespaces both used by the current namespace. See Listing 5 for an example of this problem.

The following code will not compile because the compiler finds the call to DoThat ambiguous:

using System;
using System.Collections.Generic;
using System.Linq;

namespace ExtensionScope
{
    public class MyClass
    {
        public void DoThis()
        {
            Console.WriteLine("Do this");
        }
    }
}

namespace Extensions01
{
    using ExtensionScope;

    public static class MyExtensions01
    {
        // Can never be called
        public static void DoThis(this MyClass myClass)
        {
            Console.WriteLine("Do this");
        }

        public static void DoThat(this MyClass myClass)
        {
            Console.WriteLine("Do bop");
        }
    }
}

namespace Extensions02
{
    using ExtensionScope;

    public static class MyExtensions02
    {
        // Can never be called
        public static void DoThis(this MyClass myClass)
        {
            Console.WriteLine("Do this");
        }

        public static void DoThat(this MyClass myClass)
        {
            Console.WriteLine("Do bang");
        }
    }
}

namespace ExtensionScope
{
    using Extensions01;
    using Extensions02;

    class Program
    {
        static void Main(string[] args)
        {
            MyClass m = new MyClass();
            m.DoThat();
        }
    }
}

This program throws a compile time error because the compiler does not know if you want to MyExtionsions01.DoThat() or MyExtension02.DoThat(). There are two ways to resolve this error:

You could remove the using directive for either Extensions01 or Extensions02. In this case, that would be a fine resolution, but if there were other methods or classes in both Extensions01 and Extensions02 that you wanted to use, then this could become a painful, or even unacceptable, choice.
You could explicitly state which method you want to call using standard static syntax: MyExtensions01.DoThat(m).
You could move either MyExtensions02 or MyExtensions01 into the ExtensionScope namespace:

namespace ExtensionScope
{
    public static class MyExtensions02
    {
        public static void DoThat(this MyClass myClass)
        {
            Console.WriteLine("MyExtensions02.DoThat");
        }
    }
}

This latter solution works so long as you have access to the source.

It should be clear that some of the issues discussed here can lead to trouble if you are not careful. In particular, you don't want to end up in a situation where forcing someone to remove a namespace results in them losing access to important functionality, nor do you want to force them to choose between functionality they desire and using your extensions.

It can also be a serious nuisance if you muddy a namespace with what many developers might consider superfluous methods. If you added 50 extension methods to the C# string class, then developers who just want to access the base functionality of that object would always have to contend with your methods, particularly when using IntelliSense.

To avoid or at least mitigate the seriousness of these problems, you should always place your extension methods in unique namespace separated from the rest of your code so that you can easily include or exclude the extension methods from a program. Listings 10 and 11 illustrate this technique.

Place your extensions in a separate file, and give them a unique namespace:

namespace MyCode
{
    public class MyCode
    {
        // Code omitted here
    }
   
}

namespace MyCode.Extensions
{
    public static class SpecialString
    {
        private static string[] stateCodes = 
                {"AL","AK","AZ","AR","CA","CO","CT","DE","FL",
                 "GA","HI","ID","IL","IN","IA","KS","KY","LA",
                 "ME","MD","MA","MI","MN","MS","MO","MT","NE",
                 "NV","NH","NJ","NM","NY","NC","ND","OH","OK",
                 "OR","PA","RI","SC","SD","TN","TX","UT","VT",
                 "VA","WA","WV","WI","WY"};

        public static bool IsState01(this string source)
        {
            if (source == null) return false;
            source = source.ToUpper(); 
            foreach (var item in stateCodes)
            {
                if (source == item)
                {
                    return true;
                }
            }
            return false;
        }

        public static bool IsState02(this string source)
        {
            return (source == null) ? false : stateCodes.Contains(source.ToUpper());
        }
    }
}

In this code I show you two alternative ways to implement the IsState extension method. The second, which uses LINQ, is probably easier to maintain. You can access the extension methods in a namespace MyCode.Extensions like this:

using System;
using MyCode;
using MyCode.Extensions;

namespace ConsoleApplication1
{
    class Program
    {            
        static void Main(string[] args)
        {
            MyCode myCode = new MyCode();
            // Use My Code here.
            string test = "WA";
            if (test.IsState02())
            {
                Console.WriteLine("{0} is a state", test);
            }
        }
    }
}

In this code your extension method is available and the code compiles. Comment out the third using statement and your extension method would not be available and the code would not compile. The developer would, however, still have access to the functionality found in the MyCode namespace. You could perhaps improve this technology by putting your extensions in their own assembly with its own namespace. You could then be sure that developers could choose to include or exclude the extra weight of your extension methods when they ship their code.

Though extension methods are particularly useful in LINQ, they are now a part of the language, and if used with caution, they can be useful. Placing them in their own namespace is a best practice that should help you get the most from this feature.

Cut Development Time: Use LINQ

Charlie Calvert — Tue, 17 Jun 2008 01:37:46 GMT

When Microsoft employees talk about LINQ publicly, we haven't tended to emphasize how much time you can save by using it. This is perhaps because we don't want LINQ to be labeled as simply another RAD tool designed to save time. Nevertheless, it is becoming clear to me that shorter development cycles may be one of the first major benefits of LINQ to be widely recognized by the community.

I first began to notice the importance of this issue a month or two ago at a customer visit in San Diego. I asked if anyone at the company we were visiting was using LINQ. Only one person raised their hand. I asked him about his experience, and one of the first things he said was that he was able to get a lot of work done very quickly. DBA's at our session immediately chimed in with the usual objections about moving queries out of the database and into a codebase, and from there the discussion wandered off on a predictable tangent. Yet since then I've remembered that user's experience with rapid development, and the obvious enthusiasm he had for his subject.

The subject came up again during other stops in Southern California. The same point was raised by several developers I spoke with at Tech Ed, and again in a recent MSDN article by Dr. James McCaffrey. He said that LINQ reduced the time it took him to write test procedures by 50 percent. He added that LINQ to SQL made his test code "much shorter, much cleaner, and therefore easier to create, modify, and maintain."

Of course, LINQ has many other benefits. It provides a single unified query language that can be used across multiple data sources including SQL and XML. It is integrated into the C# language, allowing you to harness the power of .NET and the Visual Studio IDE when writing queries. It is both transformative and composable, allowing you to combine queries from multiple data sources in myriad ways. It uses a succinct and elegant declarative style of programming, and it is extensible so that you can run LINQ queries against any arbitrary data source. Yet sometimes it is simplest just to think of LINQ as a fast, elegant way to get a lot of work done quickly. In this day and age when we are all struggling to work with huge amounts of data, and to complete complex tasks in a short period of time, anything that will simplify our lives is welcome. LINQ is one of those things that just makes it easier to get work done quickly.