Congratulations, Robert. I agree with the masses that you did a great job in opening up Microsoft. I’ll miss your angle on Microsoft and your ability to bridge the Microsoft / Web 2.0 world. Of course, I’ll probably run into you more now. Especially if you listen to Dave Winer — the East Bay is a great place to be.
I wrote about the WinFx name change on Friday, WinFx becomes .NET 3.0.
One of my questions had to do with .NET 2.0 and whether there will be a new CLR. Jason Zander clears that up here: .NET 3.0 is the combination of what was WinFx (WCF, WF, WPF, WCS), and .NET 2.0. So, no, there will not be a new CLR.
Some people have complained that this introduces some confusion because the .NET product version number doesn’t match the CLR. Of course, it could get pretty harry going forward, because .NET is more than just the CLR.
I agree that this can be confusing, but if you buy that the name change is a good idea (which I do) then this is the best solution. The alternative — arbitrarily bumping up component versions to match the product version — is misleading and will cause developers much more headache.
I do hope, though, that we are not heading back to a time when it was nearly impossible to detect what versions of .NET are actually installed. Remember the list of file versions and manifests that you had to pour over to detect which Visual Studio 6 service-pack you had? Did this ever match what was installed on your machine? Not for me.
What we need is a simple tool to tell us what is installed. How about it? Microsoft, can you commit to a simple tool (supported, unmanaged, open-source, available in binary with a free redistributable) to determine exactly which .NET is installed? This will save your ISVs some headache.
I figured that if Brad Abrams, Kryzysztof Cwalina, and Joe Duffy all agreed that you call the async callback before you signal the wait handle, then they must be right. Sure, blocking on the wait handle in the callback results in a deadlock, but perhaps (I reasoned) that is not a supported use case.
Joe refers to a customer who emailed Brad and Kryzsztof about this. That’s me. Then I backed off, figuring that Joe’s original post shed some light on the issue. I’m not usually so quick to defer in this way, but at least I deferred to some really bright guys.
Note: I turned off comments because this post is a major recipient of comment spam.
S. Somasegar has announced that WinFx was confusing and so they have renamed it to .NET 3.0.
I’m indifferent or its good, wierd, or bad. What?
Indifferent: It is just a name.
Good: I like the idea that WinFx == .NET 3.0. It definitively shows how these technologies relate.
Wierd: I liked the name WinFx. As one of my Digipede presentations says, WinFx is was the new Windows API. Is Microsoft saying that .NET 3.0 is the new Windows API? That is hard to believe. Will WinFS end up being in .NET 3.0 or is that something else altogether?
Bad: Does this mean that the CLR is about to have a new version number? As Jesse Kaplan told me at PDC05, the biggest compatibility problem for .NET 2.0 was the version # (oh and installs that rely on the version # or some installation artifact to detect .NET). So is this going to happen again? So soon?
So, does it all matter in the end? I don’t know . . . it probably helps Microsoft focus its branding . . . that is a good thing.
If you are an ISV interested in partnering with Microsoft, I recommend John’s post, Partnering with Microsoft. His advice is top notch.
He follows it up by railing on the Microsoft partner Web sites in Part Deux. This post had me laughing out loud; however, you might not truly get it unless you’ve experienced the pain yourself.
Here are three things I want the C# preprocessor to do. Together they would better support cross-compilation for different .NET versions. Of course, this means that I really want these for C# / .NET 1.1. Too late for that?
1. Ignore all text in #if‘ed out code. Ideally this would simply ignore all text between the #if and the matching #else or #endif. You may think it already does this, but of course it does not. It looks at all of the preprocessor commands. Why do I care? Well, I want to use #pragma warning disable around some specific method-calls to members we plan to make obsolete. This doesn’t work before C# 2.0, so I would like to #if out these pragmas (and turn off all such warnings globally in those builds too, by the way):
#if !__DOTNET11__ #pragma warning disable 618 #endif
Of course, this doesn’t work at all because previous versions of C# choke on the warning pragma. It may be too much to call this one a deficiency, but it sure would be nice if it worked.
2. Allow expressions in #if. See the next one for the reason.
3. Provide compiler-version and .NET version constants. This is kind of obvious, but why do I have to define my own constant (as in the above example)? C++ supports the __CLR_VER constant. Why not C#? I would prefer:
#if __CLR_VER < 2.0 . . . #endif
Of course, this requires expression evaluation and I’m intentionally blurring the distinction between textual constants and mathematical operators.
There are workarounds to these issues, but handling the warnings properly is kind of thorny. I’m a big believer in clean builds, so I think it is worth the time to implement this, but I sure do wish Microsoft had built this in. My understanding is that cross-compilation was not considered a requirement for VS2005 and MSBuild when it was released — not having this kind of support built into the language is another example of that.
FriendFeed Status
About me
Main feed
Email subscriptions