As far as the build system goes, it's ancient ways are best left to those who know it's secret incantations . Well, its not that bad but there are whole teams dedicated to getting our daily builds done and I have nothing but respect for the feats they
pull off each day. I wish I could tell you more but I haven't plumbed the depths of our build system too far...yet...

Fair to ask if its based on the new build system for Longhorn, or is that is a result of this, Sampy?

Jamie, unfortunatly I'm not really in a place to say what you can and can't get access to. I'm just a dev working hard on VB .Net deployment. Maybe another fellow MS'er can comment more about getting into things like that.

ktegels, I assume you're talking about MSBuild when you talk about the longhorn build system. Whidbey uses MSBuild as it's project format and uses it to build all managed projects (you can see this today in our PDC preview as well as the community preview).
I'd direct you to my former comment about compilers. When developing all this stuff at once, we can only use it to a limited degree and maintain our build stability and our sanity. While I'm sure some where people are building with MSBuild, we still use our
tried and true build system for most of our stuff. We have a lot of investment in it and it gets the job done.

It is very good to hear that you use this thing as well as be proponents for its use day in and day out. To be truthful I have not used much else in the past number of years. Sure I have tried a few other things but Visual Studio and now Visual Studio.net
2002/2003 are all I use for just about evrything.

Here at TAISoftware we have switched almost all of our clients to the .Net way of doing things. One thing we have Not done a hell of a lot of though is use third Party Components. We wrote our own grid, our own Syntactic highliters, our own report engines,
or our graphing components, or our structured drawing containers, our our FTP stuff, or own encrypters/dercypters. Visual Studio .net has given us the power to do all this stuff. I can be just as critical as the next guy when it comes to Microsoft. I just
feel that the folks who bash VS.NET are operating from a position of envy. When it comes to IDE's you'll have to pry VS.NET out of my cold dead hands...

This is such a great thread... I hate to turn it south, but why MSBuild? Why not nAnt? As far as I can see (from my vantage point) there isn't much difference. Am I worng? This is one of the things that I can't understand (aside from distribution issues,
I mean if using nAnt means that it has to be shipped seperatly from VS, I guess I have to live with it), why reinvent something, when MS could contribute to it and make it better (actually "embrace and extend")? nAnt has been around for a while and seems to
be fine. I have personally used ant more than nAnt because the fact that it is written in C# doesn't make a difference if that is the only difference. Anyway, I'm rambling now, but honestly when I look at Whidbey, I get stoked, then I see things like MSBuild,
which didn't originate at Microsoft, but are spoken of as if Microsoft is changing the world, and I back away. I just can't look someone in the face and say "I don't know what you are talking about, MS invented this" when I know different. Hopefully you guys
can tell me I am wrong. Either way, this very moment, I think this site is BAD *! I have that funny feeling you get when you realize a feature of VS that you just *know* is going to make life better. Anyway, what gives, and thanks again for taking this time
with *us*. It ROCKS!

I want to know my csc.exe like I know my wife, can you direct me to any resource that would really get me under the hood. I have MSDN Universal Access.

I was thinking about getting involved with Mono, but I am hesitant as I have been to really want to maintain my "Microsoft Clean-room".

You should look at Rotor instead. It's a CLR/C# implementation we released under a shared source license for researchers and universities to play with, and shares a fair amount of code with the shipping framework. There's a lot of net resources about it out
there, and even an O'Reilly book.

bshankle, I think something which is important to remember when you are asking to name a shipping application
from Microsoft which has been built using .NET is that for many products that MS ships, is firstly .NET didn't come out (out of beta and so on) until around 2002.

So it is expected, new products, sure they can easily be developed using .NET. However, for the products that have been around for awhile, migrating them from unmanaged to managed code will take awhile longer to be released. It'll firstly need to be tested
to check for consistancy with previous versions that were developed, consistancy in what? Well, performance for one sure, migrating the UI probably isn't too difficult, performance will be a factor still though.

In regards to MFC, I would probably be not the best person to comment on it, programmed in it briefly (1 or 2 weeks). There may well have been products developed using MFC, just they either have been superseded, or they were just never released because they
had issues. Or maybe the approach might have been "if it ain't broke, don't fix it"!

That said, you could perhaps think, wait a minute... If something like happened back then, then what's the chances that you'll only see only a smattering of products developed using the current .NET framework out there, and then everyone will already have started
"migrating" everything to say Whidbey.