But, given that Office 2003 allows you to write .NET bits, ...
I'm curious about that statement
chiph. Is there something I've missed?
I know about VSTO 1.0 (and soon 2.0?) but I had the idea that VSTO was a set of COM-interop wrappers and project templates for externally automating Office 2003 programs, Word and Excel if I recall correctly. About the same as using VB6 or VBScript to do the same thing, no?
Then again, a quick look at the literature shows that these two programs have a "hook" in them to scan for a pair of custom document properties and then load an unmanaged DLL on document-load. This DLL then loads your .Net assembly and...
Well my point is it looks like an interim kluge.
.Net
is pretty deeply embedded into the new SharePoint facility that was released with Office System 2003 (even though that is really more of a Windows 2003 Server feature than an Office feature despite the name).
Hmmm... maybe you make a good point. ;-)
I'd be more curious about the stability early adopters have seen so far as things have progressed from .Net 2002 to 2003 to (soon) Whidbey (2005?). This seems like fairly rapid technology-churn, especially considering how much new stuff there is to learn from those coming from Win32 development. Any words of wisdom about the effort required to upgrade a Framework 1.0 application to 1.1? Source-level changes from 2002 to 2003?
Even language syntax and semantics changed some, but I'm sure changes in the base libraries were more serious changes. The IDE has changed too of course, but that's more or less cosmetic. Whidbey sounds like a bigger set of changes yet.
I just wonder if things are still .Not for the time being (regarding serious projects) though perhaps .Now for getting up to speed as a developer.
Whidbey may be strongly tied to the future Longhorn platform, which is far over my horizon yet. I imagine we'll be seeing a few more VS.Net/.Net Framework releases before Longhorn is released, certainly prior to wide adoption. This means the Longhorn tie is weaker than it might appear. This could be doubly so if an interim, limited Avalon release/upgrade is distributed as a Win XP update, as rumored. Indeed, I am starting to wonder about Avalon, and whether or not XAML will be the DHTML-killer technology. There has to be a reason why IE is being left to stagnate.
It may be valid to say "get onboard now or be left behind" from a developer perspective. In the past I have found that when an MS technology is still shiny and new there is more information lying around for the taking to learn how it all works. Later on everyone seems to just assume all of that background, and the important small nuggets of knowledge get harder to track down when you come to the game late. As changes are introduced discussions about them are often expressed in terms of the "delta" from previous incarnations rather than as entities unto themselves. Lacking the assumed "common wisdom" acquired through previous-version experience can make such discussions difficult to appreciate.
That's one reason I wade in from time to time myself even though I have not made a .Net commitment yet. Of course since I've barely waded in up to my ankles my viewpoint is limited and I probably have a lot of misconceptions.
I'm not trying to spread FUD against .Net - if anything perhaps just the opposite. The genie is escaping the bottle and so it could be time to get moving with the changes.
So... C# vs. 5 years out? I'd stop worrying about the dumb language itself. The panic ought to be about .Net ecosystem and keeping up with it all.