Paulo Morgado : C#

LINQ To SQL Tips & Tricks: String Operations

Paulo Morgado — Tue, 13 Oct 2009 00:51:43 GMT

LINQ brought developers a very user friendly and domain independent style of writing queries.

The fact that the way queries are written is domain independent doesn’t mean that any query will compile the same way or even run the same way. You’ll always need to know how the provider will behave.

LINQ To Objects, for example, will compile queries as a Func<> delegate and the query methods will return IEnumerable(T) implementations.

On the other hand, LINQ To SQL will compile queries as an Expression<Func<>> (which is, in fact, an expression tree) instance and the query methods will return IQueryable(T) implementations.

Because LINQ To SQL queries are compiled to an expression tree, that allows the provider to treat the query elements as it sees fit.

In this case, this means that all operations that can be done on the database will be done on the database and the developer must be aware of this when she/he is writing the queries.

Lets take an example using the AdventureWorks database (if you don’t have it, you can download it from here).

I want to build a list of salutation for every employee that has the SalariedFlag set, in the form of:

[Mr.|Mrs.|Miss] <first name> <middle name> <last name>

But there’s also one detail about the data in the database: FirstName, MiddleName and LastName may have trailing spaces and I don’t want them.

This is a simple query like this:

var q1 = from e in context.Employees
         where e.SalariedFlag
         select
            ((e.Gender == 'F') ? ((e.MaritalStatus == 'S') ? "Miss" : "Mrs.") : "Mr.") + " " +
            e.Person.FirstName.Trim() +
            (e.Person.MiddleName == null || e.Person.MiddleName.Trim().Length == 0 ? " " : " " + e.Person.MiddleName.Trim() + " ") +
            e.Person.LastName.Trim();

and it will be executed as:

SELECT ((((
    (CASE
        WHEN UNICODE([t0].[Gender]) = @p0 THEN
            (CASE
                WHEN UNICODE([t0].[MaritalStatus]) = @p1 THEN @p2
                ELSE @p3
             END)
        ELSE CONVERT(NVarChar(4),@p4)
     END)) + @p5) + LTRIM(RTRIM([t1].[FirstName]))) + (
    (CASE
        WHEN ([t1].[MiddleName] IS NULL) OR (LEN(LTRIM(RTRIM([t1].[MiddleName]))) = @p6) THEN CONVERT(NVarChar(MAX),@p7)
        ELSE (@p8 + LTRIM(RTRIM([t1].[MiddleName]))) + @p9
     END))) + LTRIM(RTRIM([t1].[LastName])) AS [value]
FROM [HumanResources].[Employee] AS [t0]
INNER JOIN [Person].[Person] AS [t1] ON [t1].[BusinessEntityID] = [t0].[BusinessEntityID]
WHERE [t0].[SalariedFlag] = 1
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [70]
-- @p1: Input Int (Size = 0; Prec = 0; Scale = 0) [83]
-- @p2: Input NVarChar (Size = 4; Prec = 0; Scale = 0) [Miss]
-- @p3: Input NVarChar (Size = 4; Prec = 0; Scale = 0) [Mrs.]
-- @p4: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [Mr.]
-- @p5: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- @p6: Input Int (Size = 0; Prec = 0; Scale = 0) [0]
-- @p7: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- @p8: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- @p9: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 3.5.30729.4926

If you notice the query, there are a lot of text operations going on for each row.

Depending on the number of rows or database load this can prove to be very bad. The result might even be just a timeout.

So, how do we force the string operations to occur on the client instead of the database?

Only IQueryable<T> will be translated to T-SQL. So, all we need to do is change the type of the enumerator being iterated.

One way to do this is using the the AsEnumerable method of the Enumerable class.

The query would now be written as:

var q2 = from e in context.Employees.Where(e => e.SalariedFlag).AsEnumerable()
         select
            ((e.Gender == 'F') ? ((e.MaritalStatus == 'S') ? "Miss" : "Mrs.") : "Mr.") + " " + e.Person.FirstName.Trim() +
            (e.Person.MiddleName == null || e.Person.MiddleName.Trim().Length == 0 ? " " : " " + e.Person.MiddleName.Trim() + " ") +
            e.Person.LastName.Trim();

and it will be executed as:

SELECT
    [t0].[BusinessEntityID],
    [t0].[LoginID],
    [t0].[NationalIDNumber],
    [t0].[JobTitle],
    [t0].[MaritalStatus],
    [t0].[BirthDate],
    [t0].[Gender],
    [t0].[HireDate],
    [t0].[SalariedFlag],
    [t0].[VacationHours],
    [t0].[SickLeaveHours],
    [t0].[CurrentFlag],
    [t0].[rowguid],
    [t0].[ModifiedDate],
    [t1].[BusinessEntityID] AS [BusinessEntityID2],
    [t1].[PersonType],
    [t1].[NameStyle],
    [t1].[Title],
    [t1].[FirstName],
    [t1].[MiddleName],
    [t1].[LastName],
    [t1].[Suffix],
    [t1].[EmailPromotion],
    [t1].[AdditionalContactInfo],
    [t1].[Demographics],
    [t1].[rowguid] AS [rowguid2],
    [t1].[ModifiedDate] AS [ModifiedDate2]
FROM [HumanResources].[Employee] AS [t0]
INNER JOIN [Person].[Person] AS [t1] ON [t1].[BusinessEntityID] = [t0].[BusinessEntityID]
WHERE [t0].[SalariedFlag] = 1
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 3.5.30729.4926

As you can notice, text operations are no longer done on the database, but all the columns of both tables are being returned. And this is still a bad thing because we are using network bandwidth with data that won’t be used.

The way to choose the columns that will be retrieved from the database is by selecting only the ones wanted in the select statement. But because we still want string operations the be done on the client, we’ll need to project the desired columns into an intermediary object. Since we won’t need this object outside the query, we’ll use an anonymous type.

The query would now be written as:

var q3 = from n in
             (
                 from e in context.Employees
                 where e.SalariedFlag
                 select new
                 {
                     Gender = e.Gender,
                     MaritalStatus = e.MaritalStatus,
                     FirstName = e.Person.FirstName,
                     MiddleName = e.Person.MiddleName,
                     LastName = e.Person.LastName
                 }
             ).AsEnumerable()
         select ((n.Gender == 'F') ? ((n.MaritalStatus == 'S') ? "Miss" : "Mrs.") : "Mr.") + " " + n.FirstName.Trim()
         + (n.MiddleName == null || n.MiddleName.Trim().Length == 0 ? " " : " " + n.MiddleName.Trim() + " ")
         + n.LastName.Trim();

and it will be executed as:

SELECT
    [t0].[Gender],
    [t0].[MaritalStatus],
    [t1].[FirstName],
    [t1].[MiddleName],
    [t1].[LastName]
FROM [HumanResources].[Employee] AS [t0]
INNER JOIN [Person].[Person] AS [t1] ON [t1].[BusinessEntityID] = [t0].[BusinessEntityID]
WHERE [t0].[SalariedFlag] = 1
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 3.5.30729.4926

Notice the call to Enumerable.As Enumerable to translate the LINQ To SQL query into a LINQ To Objects query.

And, to end this long blog post, if you don’t use any string operations on the query, they, obviously, won’t be translated to T-SQL:

var q4 = from e in context.Employees
         where e.SalariedFlag
         select BuildSalutation(e.Gender, e.MaritalStatus, e.Person.FirstName, e.Person.MiddleName, e.Person.LastName);

where BuildSalutation is implemented as:

private static object BuildSalutation(char gender, char maritalStatus, string firstName, string middleName, string lastName)
{
    return ((gender == 'F') ? ((maritalStatus == 'S') ? "Miss" : "Mrs.") : "Mr.") + " "
        + firstName.Trim()
        + (middleName == null || middleName.Trim().Length == 0 ? " " : " " + middleName.Trim() + " ")
        + lastName.Trim();
}

and it will be executed as:

SELECT
    [t0].[Gender] AS [gender],
    [t0].[MaritalStatus] AS [maritalStatus],
    [t1].[FirstName] AS [firstName],
    [t1].[MiddleName] AS [middleName],
    [t1].[LastName] AS [lastName]
FROM [HumanResources].[Employee] AS [t0]
INNER JOIN [Person].[Person] AS [t1] ON [t1].[BusinessEntityID] = [t0].[BusinessEntityID]
WHERE [t0].[SalariedFlag] = 1
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 3.5.30729.4926

Have you noticed that this T-SQL query is pretty much the same in the previous example?

If you are still reading this, I hope you now aware of how you write your LINQ To SQL queries affect the generated T-SQL.

PowerShell For The .NET Developer

Paulo Morgado — Fri, 18 Sep 2009 00:03:12 GMT

Some time ago I needed to have the validationKey of the machineKey element of an ASP.NET application changed and found out that ASP.NET doesn’t provide a command-line tool (or any other) to do this.

Looking around I found several applications and code samples to do it, but to have a system administrator do this I needed to test and document the application and it was to much work for such task.

I’ve always been a supporter of the idea of PowerShell but I never used it my self. Just because I almost always have Visual Studio open and writing a simple console application is quicker and easier than learning PowerShell.

This time I decide that I would do a PowerShell script instead.

In C# I would have done something like this:

class Program
{
    private static string GenerateKey()
    {
        var buff = new byte[64];
        (new System.Security.Cryptography.RNGCryptoServiceProvider()).GetBytes(buff);
        var sb = new System.Text.StringBuilder();
        foreach (var b in buff)
        {
            sb.AppendFormat("{0:X2}", b);
        }
        return sb.ToString();
    }

    private static void Main(string[] args)
    {
        var path = args[0];
        var config = System.Web.Configuration.WebConfigurationManager.OpenMachineConfiguration(path);
        var systemWeb = config.GetSectionGroup("system.web") as System.Web.Configuration.SystemWebSectionGroup;
        var machineKey = systemWeb.MachineKey;
        machineKey.ValidationKey = GenerateKey();
        config.Save(System.Configuration.ConfigurationSaveMode.Modified);
    }
}

How would it be in PowerShell? As simple as this:

function GenerateKey
{
    [System.Byte[]]$buff = 0..63
    (new-object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($buff)
    $sb = new-object System.Text.StringBuilder(128)
    for($i = 0; ($i -lt $buff.Length); $i++)
    {
        $sb = $sb.AppendFormat("{0:X2}", $buff[$i])
    }
    return $sb.ToString()
}

[System.Reflection.Assembly]::LoadWithPartialName("System.Web")
$config = [System.Web.Configuration.WebConfigurationManager]::OpenWebConfiguration("<path>")
$systemWeb = $config.GetSectionGroup("system.web");
$machineKey = $systemWeb.MachineKey
$machineKey.ValidationKey=GenerateKey
$config.save("Modified")

Wonder how I got from no knowledge of PowerShell to this? Simple. Something that every real .NET developer has and loves: .NET Reflector (with a PowerShell add-in, of course).

LINQ With C# Book Is Finally Out

Paulo Morgado — Sun, 17 May 2009 23:39:51 GMT

It’s finally out!

The LINQ Com C# (LINQ With C#) book that Luís and I wrote is out. Well, mostly Luís than I.

This book, published by FCA, is targeted at anyone that already knows C# 2.0 and wants to know learn the new features introduced with C# 3.0 that made possible LINQ (Language INtegrated Query). The examples in the book are written in C#, but Visual Basic get be get from the book’s site.

	Title:	LINQ Com C#
	Authors:	Luís Abreu / Paulo Morgado
	ISBN:	978-972-722-547-7
	Number of Pages:	216
	Format:	17,0 x 24,0 x 1,3 cm (6.7 x 9.4 x 0.5 in)

The book can be found here:

Help Typemock Launch Its New Visual Basic .NET Friendly API And You Might Get A Free License

Paulo Morgado — Tue, 13 Jan 2009 21:32:00 GMT

Typemock is announcing today a new version of Typemock Isolator (5.2).

One of the coolest features in the new version is the inclusion of a new VB .NET unit testing API. This 'VB friendly' API was designed and written in VB.NET, for VB.NET developers. It uses the strengths of the VB.NET language to allow easy and intuitive use of the isolation API, for easier unit tests on any piece of .NET code.

If you are you a blogger, webmaster, or internet columnist, you can get your free personal license by helping Typemock launch their new 5.2 version for Isolator - the best tool to unit test VB.NET applications.

Although this version is targeted to unit test VB.NET applications, C# applications with unit tests built using Visual Studio 2005 can also benefit from this API.

How can you get the free license?

Post the text below on your blog (as is, with links) and tell them about it . If you are in the first 25 to mail them after posting, your license will be on its way!

If you have a VB.NET dedicated blog, you'll get a license automatically (even if more than 25 submit) during the first week of this announcement.

A few simple requirements:

You must own a website, blog space or internet column, older than 2 months, or get permission from the owner of such a site.
Your post must include the text below (including the links) between *Begin* and *End*.

*Begin*

Programming Visual Basic applications?

Typemock have released a new version of their unit testing tool, Typemock Isolator 5.2.
This version includes a new friendly VB.NET API which makes Isolator the best Isolation tool for unit testing A Visual Basic (VB) .NET application.

Isolator now allows unit testing in VB or C# for many ‘hard to test’ technologies such as SharePoint, ASP.NET MVC, partial support for Silverlight, WPF, LINQ, WF, Entity Framework, WCF unit testing and more.

Note that the first 25 bloggers who blog this text in their blog and tell us about it, will get a Free Full Isolator license (worth $139). If you post this in a VB.NET dedicated blog, you'll get a license automatically (even if more than 25 submit) during the first week of this announcement.

Go ahead, click the following link for more information on how to get your free license.

*End*

Once you post this in your site, just drop them a line at vb@typemock.com with your name and the post URL to get your free license.

Hurry up – this offer is limited to the first 25 general bloggers, or to VB.NET dedicated bloggers who will post this in the first week.

Disclaimer: This is an offer from Typemock as announced at http://blog.typemock.com/2009/01/get-free-isolator-licnese-for-helping.html. I’m just a fan.

The Future Of C#

Paulo Morgado — Wed, 03 Dec 2008 01:17:00 GMT

If you were able to attend this session at PDC or Tech-Ed EMEA Developers, you were presented with a first class presentation of the future of C#, presented, respectively, by Anders Hejlsberg and Mads Torgersen.

For the near future (.NET 4.0) C# will have:

Dynamically Typed Objects
Optional and Named Parameters
Improved COM Interoperability
Co- and Contra-variance

A preview of the compiler as a service was shown, but that’s not for the .NET 4.0 / Visual Studio 2010 timeframe. Probably, not even for the next.

Starting with .NET 4.0, C# and Visual Basic will converge in terms of features and follow a path of co-evolution going into the future.

No! That doesn’t mean that XML literals will be in C# in a foreseeable future. What that means is that the above list also applies to Visual Basic.

Talking of Visual Basic evolution, the _ line continuation character has been retired. If you have any use for the underscore, please visit http://www.unemployedunderscores.com/.

Resources:

C# Future
Microsoft Pre-release Software Visual Studio 2010 and .NET Framework 4.0 Community Technology Preview (CTP)
Charlie Calvert's Community Blog
PDC Session: TL16 - The Future of C#

Presenter: Anders Hejlsberg

PPTX | WMV-HQ | WMV | Zune | MP4
PDC Session: TL12 - Future Directions for Microsoft Visual Basic

Presenter(s): Paul Vick, Lucian Wischik

PPTX | WMV-HQ | WMV | Zune | MP4

MSDN Ramp Up Program

Paulo Morgado — Fri, 07 Nov 2008 00:53:35 GMT

I just came across this: www.MyRampUp

Ramp Up is a free, online, community-based program that can help users save time in learning Microsoft technology.

The easy-to-access content (provided by subject-matter gurus) is specifically tailored to the Ramp Up program, and offered in a variety of forms (whitepaper, v-lab, codecast and slidecast).

The currently available routes are:

Currently, there are no assessments in the program, so it's quicker than ever to graduate and receive the reward (25% off on certification and 50% off on e-Learning - only for graduates of Ramp Up).

LINQ With C# Book

Paulo Morgado — Sun, 21 Sep 2008 23:42:00 GMT

Luís just broke the news on our LINQ with C# book.

I was honored with the invitation from Luís to write this book with him for FCA, for which he has already published a few books [^] [^] [^] before.

This will be an entry level book in Portuguese targeted to anyone wanting to learn LINQ with C#.

It has been a fun project with great discussions (only possible because we have half an ocean between us :) ).

PDC2008: Meet Me In Los Angeles

Paulo Morgado — Thu, 04 Sep 2008 00:23:28 GMT

It’s not the first time I try but, for one reason or another, this is the first time I will go to the PDC (Microsoft’s Professional Developers Conference).

According to the site “The PDC is designed for leading-edge developers and software architects. If you’re interested in the future of the Microsoft platform, you’re responsible for the technical strategy in your organization, or you’re a highly skilled developer who likes to delve deep into the heart of the platform, then the PDC is for you!”. If you fit this description, hurry up and register. Early bird discount has been extended until September 8^th.

What I like most of these events is networking with Microsoft staff and other attendees. So, if you want to meet me, I’ll be glad to meet you.

Clone Detective For Visual Studio

Paulo Morgado — Thu, 28 Aug 2008 22:41:36 GMT

Clone Detective is a tool that integrates with Visual Studio and uses the ConQAT (Continuous Quality Assessment Toolkit) to analyze C# projects and search for duplicated source code.

Watch the videos and see if this is the tool you were looking for.

StyleCop 4.3 Is Out

Paulo Morgado — Wed, 20 Aug 2008 23:36:21 GMT

The StyleCop team announced the release of a version 4.3 of the StyleCop tool. You can get it from here.

On this version there are some bug fixes, new rules and documentation.

Also in this version, the list of errors and warnings goes to the Errors List window like with the compilers. I whish that the errors and warnings would also be sent to the Output window.

SDK documentation on how to author custom rules and integrate the tool with custom build environments is expected soon.

More On Another Way For Using The “using” Keyword

Paulo Morgado — Mon, 11 Aug 2008 00:47:50 GMT

In the past I presented another possible use for the using keyword: as hints on LINQ.

I’ve been giving some thought about this lately and refined my proposal.

var q = from person in personCollection using MyEnumerableExtensions
        group person by person.LastName into g using new MyOtherComparer()
        orderby g.Key using new MyComparer()
        select person;

The above query would be converted to:

var q = MyEnumerableExtensions.OrderBy<string, Person>(
    MyEnumerableExtensions.GroupBy<string, Person>(
        personCollection,
        person => person.LastName,
        new MyComparer(),
    ),
    g => g.Key,
    mew MyOtherComparer()
);

What do you think of this?

How About Property Assignment And Collection Adding Like Object And Collection Initializers In C#?

Paulo Morgado — Sun, 10 Aug 2008 23:27:22 GMT

C# 3.0 introduced object and collection initializers. It is now easier to initialize objects or collections:

var person = new Person { FirstName = "Paulo", LastName = "Morgado" };

var persons = new List<Person> {
    new Person { FirstName = "Paulo", LastName = "Morgado" },
    new Person { FirstName = "Luís", LastName = "Abreu" }
};

var personDirectory = new Dictionary<string, Person> {
    { "Lisboa", new Person { FirstName = "Paulo", LastName = "Morgado" } },
    { "Funchal", new Person { FirstName = "Luís", LastName = "Abreu" } }
};

Wouldn't be nice to be able to do the same on already created objects and collections?

But, what would the syntax used be? Something like this?

var person = new Person();
person = { FirstName = "Paulo", LastName = "Morgado" };

var persons = new List<Person>();
persons += {
    new Person { FirstName = "Paulo", LastName = "Morgado" },
    new Person { FirstName = "Luís", LastName = "Abreu" }
};

var personDirectory = new Dictionary<string, Person>();
personDirectory += {
    { "Lisboa", new Person { FirstName = "Paulo", LastName = "Morgado" } },
    { "Funchal", new Person { FirstName = "Luís", LastName = "Abreu" } }
};

What do you think of this?

C# And Visual Basic Generate Different Expression Trees

Paulo Morgado — Mon, 04 Aug 2008 00:23:00 GMT

(This was pointed out to me by Frans Bouma and explained by Jon Skeet)

Imagine you have this set of classes:

public class A
{
    public virtual string P
    {
        get { return "A"; }
    }
}

public class B : A
{
}

public class C : B
{
    public override string P
    {
        get { return "C"; }
    }
}

And this class:

public static class Reporter
{
    public static void Report<T>(T target, Expression<Func<T, string>> expression)
    {
        Console.WriteLine("Expression: {0}", expression);
        Console.WriteLine("\tDeclaring Type: {0}", ((expression as LambdaExpression).Body as MemberExpression).Member.DeclaringType);
        Console.WriteLine("\tInvocation Result: {0} for {1}", expression.Compile().Invoke(target), target.GetType());
        Console.WriteLine();
    }
}

The above class writes to the console the lambda expression, the declaring type of the property and the value of the property for the target and the target’s type.

Now, let’s look at what happens when used from this C# code:

Reporter.Report(new C(), (A a) => a.P);
Reporter.Report(new C(), (B b) => b.P);
Reporter.Report(new C(), (C c) => c.P);

Reporter.Report(new B(), (A a) => a.P);
Reporter.Report(new B(), (B b) => b.P);

Reporter.Report(new A(), (A a) => a.P);

The output will be:

Expression: a => a.P
        Declaring Type: A
        Invocation Result: C for C

Expression: b => b.P
        Declaring Type: A
        Invocation Result: C for C

Expression: c => c.P
        Declaring Type: A
        Invocation Result: C for C

Expression: a => a.P
        Declaring Type: A
        Invocation Result: A for B

Expression: b => b.P
        Declaring Type: A
        Invocation Result: A for B

Expression: a => a.P
        Declaring Type: A
        Invocation Result: A for A

On the other hand, if used from the equivalent Visual Basic code:

Reporter.Report(New C(), Function(a As A) a.P)
Reporter.Report(New C(), Function(b As B) b.P)
Reporter.Report(New C(), Function(c As C) c.P)

Reporter.Report(New B(), Function(a As A) a.P)
Reporter.Report(New B(), Function(b As B) b.P)

Reporter.Report(New A(), Function(a As A) a.P)

The output will be:

Expression: a => a.P
        Declaring Type: A
        Invocation Result: C for C

Expression: b => b.P
        Declaring Type: A
        Invocation Result: C for C

Expression: c => c.P
        Declaring Type: C
        Invocation Result: C for C

Expression: a => a.P
        Declaring Type: A
        Invocation Result: A for B

Expression: b => b.P
        Declaring Type: A
        Invocation Result: A for B

Expression: a => a.P
        Declaring Type: A
        Invocation Result: A for A

Why the differences? It’s because of each language’s specification and compiler:

The C# compiler will issue a virtual call to the virtual member in the class where it’s declared as virtual.
The Visual Basic compiler will issue a virtual call to the overriding member on the class that overrides it.

Microsoft Source Analysis for C# (aka StyleCop)

Paulo Morgado — Wed, 04 Jun 2008 23:12:22 GMT

I’ve learned from a fellow GASPer of the release of Microsoft Source Analysis for C# (aka StyleCop).

It’s still a work in progress but it’s already very useful.

Stretching Type Inference

Paulo Morgado — Tue, 22 Apr 2008 00:35:00 GMT

Note: Code in italics is not actual C# 3.0 syntax.

Local Variable Type Inference

C# 3.0 brought us local variable type inference mainly because of LINQ. The output of a query can vary from an IEnumerable<T> or an IQueryable<T> to a single instance of T where T can even be a projection which means that its type is an anonymous type.

Take the following query as an example:

from p in persons
select new { Name = p.FirstName + " " + p.LastName, Age = p.Age };

If persons is an IEnumerable<Person>, the output of the query will be an IEnumerable<T> where T is an anonymous type.

Now the question that arises is: How do I declare a variable to receive the output of the query?

The solution was the introduction of the new var keyword that instructs the compiler to determine the type of the output of the query. Now, all it takes to declare a variable to receive the output of the query is:

var q =
    from p in persons
    select new { Name = p.FirstName + " " + p.LastName, Age = p.Age };

Since the compiler can infer the type of something that looks so complex, it's obvious that it can infer the type of something so straightforward as:

var v = new Dictionary<Point, Stack<Person>>();

It's obvious that this is the same as:

Dictionary<Point, Stack<Person>> v = new Dictionary<Point, Stack<Person>>();

with less typing and margin for typing errors.

Field Type Inference

The same technique could be applied to field inference:

class Class
{
    private someDicionary = new Dictionary<string, List<string>>();

    // ...
}

with the same benefits of less typing and margin for typing errors.

If field type inference were to be applied to public fields, one constraint must be enforced though: the inferenced type cannot be or have as a type parameter an anonymous type.

But I wouldn't recommend that because it would be easy and not obvious that a small change in the field initialization could bring unobvious changes to the public interface of the class.

Method Output And Parameter Type Inference

Since type inference would be possible outside of methods, should it be allowed on method output and parameter values? Something like this:

class SomeClass
{
    private listOfStuff = new List<Stuff>();

    public void DoIt()
    {
        if (CreateList(out this.listOfStuff))
        {
            ProcessList(ref this.listOfStuff);

            this.listOfStuff = TransformList(this.listOfStuff);
        }
    }

    private bool CreateList(var out list)
    {
        list = new List<Stuff>();
        return true;
    }

    private void ProcessList(var ref list)
    {
        // ... 
    }

    private var TransformList(var list)
    {
        return list;
    }
}

which look very strange and confusing, to say the least. We shouldn't go there.

Constructor Inference

Every since I saw local variable type inference the first time, I have the feeling that more could have been done.

Let's look at this hypothetical set of declarations:

Dictionary<Point, Stack<Person>> v = new();
Point p = new(1, 2);

It's as easy to the compiler or a human reading the code that this is the same as:

Dictionary<Point, Stack<Person>> v = new Dictionary<Point, Stack<Person>>();
Point p = new Point(1, 2);

And this can be more powerful than local variable type inference and used in a lot more scenarios:

class Class
{
    private Dictionary<string, List<string>> someDicionary = new();
    private Point p;

    public Class()
    {
        this.p = new(1, 1);
    }

    public void SomeMethod()
    {
        AnotherMethod(new());
    }

    private void AnotherMethod(List<string> arg)
    {
        // ...
    }
}

Where To Stop?

The compiler could as easily infer the type of a local variable in this:

public void SomeMethod()
{
    var v = new();
    AnotherMethod(v);
}

Do we want to go there? I don't think so.

Ambiguities

C# 3.0 also brought object initializers. Instead of this:

XmlReaderSettings settings = new XmlReaderSettings();
settings.CheckCharacters = false;
settings.IgnoreWhitespace = true;

XmlReader reader = XmlReader.Create("someURI", settings);

we can just write this:

XmlReaderSettings settings = new XmlReaderSettings() { CheckCharacters = false, IgnoreWhitespace = true };

XmlReader reader = XmlReader.Create("someURI", settings);

or this:

XmlReader reader = XmlReader.Create("someURI",  new XmlReaderSettings() { CheckCharacters = false, IgnoreWhitespace = true });

Wouldn't it be nice to just write:

XmlReaderSettings settings = new() { CheckCharacters = false, IgnoreWhitespace = true };

C# 3.0 object initializers also allow constructor parenthesis to be omitted:

XmlReaderSettings settings = new XmlReaderSettings { CheckCharacters = false, IgnoreWhitespace = true };

which would lead to:

XmlReaderSettings settings = new { CheckCharacters = false, IgnoreWhitespace = true };

which looks exactly like an anonymous object creation expression and could lead to some confusion and ambiguities.

But it would be nice to just write:

XmlReader reader = XmlReader.Create("someURI", new { settings.CheckCharacters = false, settings.IgnoreWhitespace = true });

Wouldn't it?

TypeMock: How to Make Reflective Mocks More Natural

Paulo Morgado — Thu, 31 Jan 2008 23:56:00 GMT

Like I said before, this as been on the back of my mind for a while.

A while back I introduced a way to get the MethodInfo of a method in a strongly typed way using LINQ, and that's how I'm going to make Reflective Mocks more Natural.

Well, it's as easy as this:

public static class MockExtender
{
    public static IParameters ExpectAndReturn<T1, T2, TResult>(this IMockControl mock, Expression<Func<T1, T2, TResult>> expression, object ret, params Type[] genericTypes)
    {
        return mock.ExpectAndReturn((expression.Body as MethodCallExpression).Method.Name, ret, genericTypes);
    }
}

(For now, I'll leave to someone else the implementation of the rest of the overloads)

With this implementation it's possible to handle static classes (a limitation of Fredrik's implementation).

As for private methods, just let Visual Studio (2008, in this sample) and TypeMock do their magic.

So, to test this class:

public static class Class1
{
    public static string PublicMethod(string param1, int param2)
    {
        return PrivateMethod(param2, param1);
    }

    private static string PrivateMethod(int param2, string param1)
    {
        throw new NotImplementedException();
    }
}

We just write this test:

[TestMethod()]
public void PublicMethodTest()
{
    string param1 = "param";
    int param2 = 5;
    string expected = "return";
    string actual;

    Mock targetMock = MockManager.Mock(typeof(Class1));

    targetMock.ExpectAndReturn((int i, string s) => ClassLibrary1.Class1_Accessor.PrivateMethod(i, s), expected).Args(param2, param1);

    actual = Class1.PublicMethod(param1, param2);

    Assert.AreEqual(expected, actual);
}

How about this for clean and simple?

TypeMock Snippets For Visual Studio

Paulo Morgado — Sun, 13 Jan 2008 23:37:00 GMT

I've just created a set of code snippets for Visual Studio for my most used features of TypeMock. Feel free to use it.

Stop Designing for Testability (by Eli Lopian)

Paulo Morgado — Wed, 26 Dec 2007 21:25:54 GMT

Eli Lopian from TypeMock™, has an article on CodeProject about the disadvantages of design for testability and how to use TypeMock™ to remove these disadvantages while keep the advantages of unit testing.

I have to say that I agree with Eli: design for testability is BAD. It exposes more that it needs just for the purpose of testing and might increase the number of classes and interfaces that need to be implemented, tested and maintained. It also increases the attack surface of the system being built.

I am a firm believer in code for testability. Using tools like Visual Studio and TypeMock™ you can easily test private members of a class. You can do almost the same you would do in design for testability without exposing what doesn't need to be exposed and go even further by factoring your code in smaller methods easier to test.

Unit Test Patterns for .NET (from TypeMock™)

Paulo Morgado — Wed, 26 Dec 2007 20:21:39 GMT

There is a good set of articles about Unit Test Patterns in the TypeMock™ site:

Unit-Test Patterns for .NET - Part I
This article looks at patterns in unit testing and describes the main patterns found in tested .NET code. It also describes the problems with each pattern.
Unit Test Patterns for .NET - Part II - TypeMocks
Programmers who have incorporated unit testing into their development process already know its advantages: cleaner code, courage to refactor, and higher speed. But even the most die-hard unit testers can falter when faced with testing a class that relies on system state for its behavior. This article looks at the TypeMock pattern that can help you solve these problems.
Unit-Test Patterns for .NET - Part III - Natural TypeMocks™
In this series, unit-test patterns and the advantages that it brings have been discussed. Although there is great power in using TypeMocks, there are times when the reflective API can falter when refactoring code. This article will look at how to test the interaction between classes using Natural Type Mocks to solve these problems.

TypeTypeConverter vs. TypeNameConverter

Paulo Morgado — Sun, 25 Nov 2007 22:37:45 GMT

Some time ago I complained about the fact that a TypeConverter for Types was missing from the .NET Framework.

At the time I had search for one in the framework but only found internal or private implementations.

As it turns out, the version 2.0 of the .NET Framework introduced a TypeNameConverter that does practically the same thing as my TypeTypeConverter, beside the poor naming.

I say poor naming because the documentation for TypeConverter states that "The most common type of converter is one that converts to and from a text representation.". This converter does not convert from text to a Type Name but to an instance of Type. Nevertheless, it's in the framework and you should use this one instead of mine.