I've been using VS2008 Team System Dev Edition since it hit MSDN, and it improves on 2005 in almost every way, although not necessarily that much. C# 3.0 and LINQ are definitely the best things about it, and Team Build in TFS is a lot better (read: usable).

As you say, though, the stuff I really want remains "H1 2008":

ADO.NET Entity Framework, which will do the things I need that LINQ to SQL doesn't;

Parallel FX, especially the Parallel LINQ which will make multi-core support a breeze;

ASP.NET 3.5 Extensions, especially the MVC Framework;

SQL 2008 and the Sync Framework, so I can stop faffing about with SQL 2000's appalling merge replication;

Windows Server 2008, although (waiting upon waiting) that'll be of even more interest when they add ASP.NET support to the Core Web Server.

There's also the vague promise of Rosario, the assertedly much-more-improved Team System, although my cup runneth over so much I haven't even downloaded the CTP for that yet.

I know this question marks me as an old-timer, but: how is the quality of the code generation?

Yes, code generation. Will the VS2008 C/C++ compile my program to code that runs optimally for a given CPU type? Does it support generation of post-SSE2 SIMD instructions? Does it support auto-parallellized code for use on multi-core CPU? Will Microsoft's framework du jour make my program high in memory consumption?

It's a given that Visual Studio is more bloated that it's predecessor, and that Microsoft will use it to push their latest paradigm. I just want to know what all this fluff buys me for the end product - the code generated by the compiler.

Aren't you confusing VS with the SDK...?

VS is a development environment, not a compiler, all it does is call the compiler in the background - you don't need VS to write your C++ code, it's merely a tool to *help* you write it.

Things like LINQ etc are features of C# 3.0, not VS - VS just gives us the intellisense to help us utilise it easily.

"there are several other changes that are part of the plumbing behind LINQ and that are also more useful in general. One example is type inference, where the type of a variable is inferred from the value to which it is initialized.

In C#, you use the var keyword:

var s = "Reg Developer";

gets you a strongly-typed String variable."

How is this possibly useful? You still have to type var instead of string so at best you have saved yourself from typing 3 characters - at worst you have been given the opportunity to code an unmaintainable mess where everything is defined as a var at the top of the class and the unlucky sod that comes along afterwards has to trawl though the code to find out where it's first assigned in order to work out the type!

I just want to second that argument. I don't see how using 'var' constitutes strong typing. Surely one of the useful attributes of strong typing is that you can very quickly recognise the type of your variable from something mundane as its declaration. var seems to me the equivalent of:

C#:

object blurgh = new string("blurgh");

unless I'm shurely mishtaken. At least with the above, you, the developer, you know, the part of the development process with a brain, controls the type of the variable. I guess it's to entice the PHP boys/girls over (not that I'm getting at PHP but there's a time and a place...)

Don't make the mistake of equating C#3's "var" keyword with Javascript's "var". The two are entirely different, even if they are (unfortunately) named the same.

The var foo = "bar" example is very simplistic. Consider the keystroke savings in:

var q = Customer c => db.Customers.Where(cust => cust.ID == c.ID).Select(new Foo(c));

versus

Expression<Function<Customer, IQueryable<Foo>>> q = ...;

It is plainly obvious that naming expressions of lambdas involving nested generic types is onerous. It is also something that shows up frequently in LINQ.

Incidentally, the var keyword is *required* for use with anonymous types. Since the identity of the type is not knowable except by the compiler itself, this allows the programmer to still write the following strongly-typed code:

// must use var, because there is no name for the type

var q = db.Customers.Select(c => new { c.LastName, c.FirstName, HalfAge = c.Age / 2 }).First();

q.LastName = "Eubanks";

// q.Age = "One"; // compiler error -- q.Age doesn't exist

// q.HalfAge = "One"; // compiler error -- q.HalfAge is strongly typed

// q = "Two"; // compiler error -- q is strongly typed

-- Keith J. Farmer [MSFT], ex-LINQ to SQL/now-Silverlight

Re: "var at the top of the class"

The compiler would be happy to tell you that:

"The contextual keyword 'var' may only appear within a local variable declaration"

I would recommend downloading the compiler and actually trying out the new features. It's easier, and more accurate, than pure speculation.

Anon, Robert: the most important thing about the var keyword in C# is that it can only be used when declaring and initializing in a single statement. So you can't say

var x;

x = 1;

You have to say

var x = 1;

which will declare x as an int for the life of the variable: you can't assign a string value to it later. As Keith says, it's not particularly useful when dealing with ints, strings and so on, and in my code I still use the type name for those. And when you're creating a new instance, it's still easier (IMO) to specify the type and let Intellisense fill in the "new" bit.

But it is necessary for the anonymous types and LINQ stuff, and it's also pretty useful when you're getting an object back from a method and you don't want to type the whole namespace-qualified class name. I really like being able to say

var cn = Server.GetConnection();

var cmd = cn.CreateCommand();

...

var dr = cmd.ExecuteReader();

It's also important to note that Intellisense knows what type the variable is and provides the methods/properties just as if you'd specified the type name.

HTH.