VSTS Development Edition + Database Edition

This morning we made the official announcement (general info and press release) of the next release of Visual Studio and the .NET Framework. This includes Visual Studio 2010, Visual Studio Team System 2010 and the .NET Framework 4.0.

In the next release of Visual Studio Team System we will be merging the feature sets of the Development Edition and the Database Edition into a single product. The new product – part of Visual Studio Team System 2010 – will include all of the features in the Development Edition and the Database Edition as well as new capabilities delivering even more value in a single product. This will provide a more complete set of capabilities for building software in today’s data-driven environments.

Bringing these two feature sets together enables you to take advantage of the core tools for application development as well as the necessary tools for database development, including performance profiling, code analysis, code metrics, code coverage, database refactoring, Schema Compare, Data Compare, and more.

If you have VSTS 2008 Development Edition or Database Edition with MSDN Premium you are eligible to get both products through MSDN Downloads. This is an exclusive offer for MSDN Premium subscribers with these products -- we want you to realize the benefit of this merged feature set now.

Beginning October 1, 2008 eligible MSDN subscribers will have access to both the Development Edition and Database Edition through MSDN Subscriber Downloads. This change also applies to customers who purchased Visual Studio 2005 Team Edition for Software Developers with MSDN Premium Subscription and Visual Studio 2005 Team Edition for Database Professionals with MSDN Premium Subscription, who's subscription is still active.

Yes, I'm a P.C.

I LOVE the new "I'm a PC" commercial. It makes me proud to say "I'm a P.C." (OK, that's a bit odd, but what the heck).

I'll admit, I love Apple. In fact, I was a die-hard Apple user for many years before making the move to Windows. Apple makes things very elegant and desirable. Their products, their apps, their Web site...I'll bet their trash just looks good (and it probably operates very intuitively).

The fact is, that I'm a Microsoft guy, and have been for the past 10-years. I've owned Mac's - my last one was the last MacBook before the Intel switch. I've owned iPods - in fact I still have one in my car to play my daughter's Disney songs. I also own Windows P.C.s, Zunes, an XBox, and Windows Mobile phones (OK, I'll admit, I wish Windows Mobile was as sexy as the iPhone, but at least I own my phone instead of renting it).

No real point other than...my name is Doug Seven and I'm a P.C. and I'm proud of it.

A Little on LINQ

Recently I was involved (only a little) in preparing some of the Visual Studio Launch content for the February 27th launch event (and subsequent worldwide events). During the preparation we held "train-the-trainer" meetings where people who would be presenting launch sessions around the world could learn more about the sessions and ask questions. During one of these TTT events a question was raised about a LINQ demo that was written for a session named "Breakthrough Software Development Challenges with Visual Studio 2008".

The Question

Is there a performance impact to joining result sets in LINQ from two different data sources?

This question came up because this is exactly one of the scenarios we demo. Here is my rendition of the demo.

The Answer

I talked to the language teams and this is the truth of the situation.

For cross-domain joins you typically have the choice between really lousy performance or a runtime error – and generally you should prefer the latter!

The original source of the query gets to decide how the query gets executed. If the source is a LINQ to SQL table, for instance, it will simply look at anything it gets joined with, and throw an error if that is not another LINQ to SQL table, entity collection or query result.

If you go the other way, however, and join an in-memory collection (such as the descendents of an XElement, as in our demo) with a LINQ to SQL table or query result, then you are in trouble: It will enumerate the table into memory and do the join on your machine (Yikes!).

The general guidance is: don’t do cross domain joins!

Let me qualify a bit: I am talking specifically about a “Join” operation on large data sources in different domains. There are several things you can still do to work sensibly across domains, such as:

• Query the remote (e.g. LINQ to SQL) data first to yield a small enough result that it makes sense to pull it down and join locally
• Use the Contains() method on LINQ to SQL data, which will take small local collections and actually send them to the db as an IN expression in the generated query

The upshot is that one still has to be aware of the cross-domain joining and manage its impact as an application programmer.

D7