In this deep dive article on equal operator overloading Jonathan Allen clears the air on overriding the equality operator. In the article Jonathan provides code samples in both VB and C# to demonstrate the nuances of each .NET language. He also covers usage in both structures and classes.

This coming Thursday, Microsoft is hosting the annual Toronto Architect Forum at their offices in Mississauga. The target audience is architects that are *not* in the financial service industry. Here's the agenda:

As you can, I've secured the ever so popular "right after lunch" time slot. I don't know if there are detailed abstracts online for each session, but here is mine:

LINQ: Architectural Implications

Support for Language Integrated Query in the .NET 3.5 Framework promises to simplify and unify querying operations across object collections, relational data, DataSets and XML. The opportunity to simplify or even eliminate the notion of a data access layer is one many architects are considering. During this session we will quickly introduce the capabilities of LINQ, LINQ to SQL and the upcoming Entity Framework, and then discuss how this may affect the design of our data access logic moving forward.

Back in the days of fxCop, (before we had to pay for code analysis in Team Developer) if you didn't like an error/warning, you could have your request to ignore said message in an external central file.

With the advent of Visual Studio Team Editions for Developers 2005, suppressions were stored as attributes in front of blocks of code. Look on the bright side we were told - now you could see your suppressions inline with your code, versioned alongside, etc. But we lost some things with this as well. Now if you were doing major code sweeps adding suppressions, you would be touching lots of files, creating some unnecessary code churn.

Another scenario may involve a given developer doing a sweep for localization, or security, compliance, etc. In fxCop, different developers could have different settings & suppression files.

Well, Visual Studio 2008 to the rescue. Code Analysis will now give us back this capability.

One of the little pet projects I'm working on is to take a code analysis pass, and cross reference that with a change set. The goal is to generate a report of obvious warnings related to the code I'm churning. We can't be perfect here as sometimes code analysis will return an error to a line of code you didn't change, but it is indirectly caused by that. The only way to truly get a clean report would be to do a code analysis before & after the checkin - that might be too much. But this would definitely be a great report for a build - to compare code analysis passes on previous builds.

One of my readers was watching the DNRTV episode I did on LINQ recently and had this question:

At some point, when you're explaining object initializers and anonymous types, you say something regarding extension methods, like how they could be used with the anonymous types. I'm not sure how that'd work: if the anonymous type gets named dynamically as something like "<Projection>F__4", and if the extension is declared during compile time as something like "method (this type)", how can we extend the dynamic class?

He is correct in pointing out the difficulty. These projection or anonymous types have dynamically declared names and when you declare an extension method, you must specify the type after "this" in the argument clause.

One thing that is not obvious is that the type specified after “this” in an extension method doesn't have to be the exact type, but can be an ancestor or interface implemented by the type you are ultimately wishing to extend.

public static float GetArea(this IPolygon shape){...}

As an example, the above extension method could be used as an extension method over anything that implements IPolygon.

The downside is that anonymous types (and linq projections) inherit directly from object and I don't expect that they will implement any special interfaces (the goal is too keep them simple for C# 3.0). What are you left to do? Create extension methods on "object". That is certainly a theoretical option I suppose, but that seems a little bit extreme.

To be honest though, try to think of real cases when you'd want to extend an anonymous type. If the type is truly anonymous, you know absolutely nothing about it, and what assumptions can you really make about it in an extension method? Truly, in some cases, you are going to choose to implement a named type instead of an anonymous type, and it appears that we'll see refactoring support in the tools to promote an anonymous type to a real type. This is a very likely scenario.

The reasonable cases that I can think of where anonymous types are the preference (i.e. I have no burning need to have a named type) but still need (and can) extend them, is when they are used in the context of a collection or another generic type.

For a good example of that, let's take a look at some of the extension methods provided by Linq itself.

public static class Sequence {

public static IEnumerable<T> Where<T>(

this IEnumerable<T> source,

Func<T, bool> predicate) {

foreach (T item in source)

if (predicate(item))

yield return item;

}

}

Consider that this is an Extension method for anything IEnumerable<T>. In this case, we're using this extension method against an IEnumerable collection of type <T> - a generic. That generic type could be an anonymous type. But the important information here is that we know something more about the anonymous type here and that is that it's used inside of an Enumerable collection, and hence we can provide the value of iterating through it in the foreach, evaluating some criteria, and yielding the items that pass the criteria into another collection.

This past week we saw the final bits of SQL Server 2005 and Visual Studio 2005 get shipped up to MSDN Subscriber Downloads. Next week we'll see the official launch of these same products to the rest of the world, ushered in with a rolling thunder of launch events and parties stretching into the rest of the month and beyond. Microsoft does a great job of fostering community with events like this.

Technically there is a lot to like about the updates to the platform and I share most of Joel's top picks. I've been building applications, consulting and teaching developers on this platform for 4 years now and it feels quite legacy, if not common place, to me now. However, in many peoples' eyes, this becomes a critical moment in time: .NET is no longer a 1.0 product. Of course I'm speaking about groups who are not developing anything significant in .NET today, and with this maturity milestone, allows them into this “new“ world.

We've been watching the adoption and market maturity of .NET closely for the past few years, and a bit to my surprise I'm starting to see a lot of groups come to .NET for the very first time with 2.0.

This coming Tuesday I have the great pleasure of being involved in the ushering in of this new era at the Toronto launch where we are expecting between 3,000 and 4,000 developers and IT professionals come together. Early statistics are showing that somewhere between 35-50% of these folks are new to .NET. Similar events are taking place all over the world during this week and stretching out into December and beyond. For Canada, Toronto is just the first stop in a long list of cities from coast to coast. Personally, I'll be presenting at Toronto, Ottawa, Vancouver, Montreal, Quebec City and Halifax.

The overwhelming registration statics tics in all cities tells me two things: Firstly that .NET 2.0 is going to be adopted very quickly. Secondly, and more importantly, is that the software development industry in Canada is vibrantly growing and that indeed....Software Matters!

Consider two things:

Software costs a lot of money to design, build, test and deploy. Much more than it should.

Software projects fail at an alarming rate. Failure can be defined as any of the following: Late, Over Budget, Under Functionality, Buggy, Doesn't meet requirements.

Yet despite these two glaring issues, the business value of software is so compelling, that people are willing to keep investing in building software at increasing rates.

And then there is Visual Studio and SQL Server 2005:

One of ASP.NET 2.0's design goals was to reduce the number of lines of code in a typical application by over 50%.

SQL Server 2005 has been enhanced to be more reliable and secure, while at the same time bringing the 4GL productivity associated with C#, VB.NET and the .NET Framework into the database engine itself.

Visual Studio Team System 2005 was built from the ground up to help project's stay on track by integrating developers, architects, testers, project managers and other stakeholders into a common extensible repository known as Team Foundation Server.

Jon Galloway is scared by code maintainability problems introduced by DLinq. Jon and I share a common PowerBuilder background, where you could put SQL right inside your PowerScript (not unlike Progress either). This is not really a DLinq problem, but a code separation, high cohesion-loose coupling problem. The answer back in the PowerBuilder day was to put all your data access in datawindows. The .NET answer today would be componentized DataAdapters or DataReaders, but we still see the bad practice of people intermingling data access code in other areas of their application. But perhaps maybe DLinq does make this a slippery slope. Maybe we should all just stick to TableAdapters - yikes!

Oakleaf links to some Erik Meijer research articles from MSR related to C-Omega. There is also a nice presentation from Erik linked to there as well.

Andrew Conrad talks about projections and DataSets. While this isn't specifically related to LINQ/DLinq, it's interesting and solves similar problems. And the cool part about this, is that it's coming with ADO.NET 2.0/Whidbey (no need to wait for LINQ/DLinq in Orcas).

What am I missing? Drop me a line on this blog. I'm heading out next week to a VB Software Design Review and the MVP Summit in Redmond, just because there isn't enough new technology in my life these days.

A lot of the questions about XLinq are around how it will sit beside/replace XQuery (and other XML query/transform techniques). Back when I first started doing some .NET 2.0 training in February, I was a bit miffed that XQuery had not made it into the .NET Framework. Now don't get me wrong, it's not the most elegant thing in the world, but the excuse that “it's not a standard YET, so we can't put it in the framework“ seemed a little insincere given that the SQL team had managed to jump over that hurdle. But given LINQ/XLinq, maybe this now makes sense. We'll have to get our feet wet and see how LINQ evolves over time into a shipping product.

Paul Wilson has a critical review of DLinq. He rightly questions the “sqlserver only“ aspect of DLinq. I'm hopeful that this is only a temporal condition. Paul also mentions, among other things, poor support for stored procedures in DLinq, but at this point, I'm not convinced that is all too important. I have to think about that some more.

I have to say that the LINQ syntax in VB hits much closer to the mark than C#. More on that later. What is everybody else saying out there about LINQ?

Erik Meijer says that VB has become his “programming language of choice.“

Sam Gentile “LINQ is freaking cool“, but he's feeling the beta pain because the VB and C# tech previews work with Beta 2 of 2005 and he just installed the VSTS release candidate.

Rédo believes LINQ “will represent a tectonic shift in the way that VB programmers will work with data“.

Somasegar believes that LINQ is a signifiicant developer productivity enhancement and he wants to hear your feedback.

Sean Chase points out some interesting ideas using lambda expressions with LINQ.

Frans Bouma compares DLinq to O/R mappers and points out the negative side of attribute based mapping for use in cross db platform support. There is a good follow up discussion in the comments on that post.

Marius Gheorghe likes the LINQ idea, but not so much the implementatio and seems to agree with Frans.

Ben Galbraith gives his comments on LINQ from a Java perspective. In particular, he's happy to see the type inference feature added to C# and wishes Java could do the same. The comments also contain some interesting discussion on Java and .NET.

Over at the SPS Weblog, LINQ is inspiring a Visual FoxPro Object-Oriented SQL. Don't get crazy, he's only got 1 hour of development under his belt.

As you may have heard, the LINQ(Language Integrated Query) Project was announced publicly today at PDC. There will be a lot more information coming throughout the week, but here's the resources available as of today.