[Mono-list] ".NET 3.0" misnomer

[Jonathan Pryor]

On Fri, 2006-08-11 at 14:05 -0700, reinux wrote:
> Now the problem is this: if nearly all of .NET 2.0 is portable, 

...which is incorrect...

Seriously, there are large parts of .NET *1.1* which aren't portable.

System.EnterpriseServices.dll, anyone?

Hell, System.Windows.Forms isn't exactly "portable."  Not that this is
stopping us, but it was never intended to be a cross-platform toolkit.

Then there's System.Management, System.Messaging, COM interop...

To be insanely literal, everything outside of ECMA isn't necessarily
portable, and ECMA doesn't contain much (~250 classes, IIRC).

Not that minor details like this have stopped us from implementing the
parts that *are* interesting (jchamber's COM interop work, P/Invoke),
even if they're not portable (lupus quote: " P/Invoke is poorly defined
in a non-win32 system.").

> and none of
> .NET 3.0 is portable, and .NET 3.5 will have crucial changes like LinQ,
> there's no guarantee that .NET 3.5 onward won't depend on .NET 3.0,
> therefore making .NET unportable. 

I wouldn't spend too much energy on this argument.

LINQ is supposed to be a very generic framework.  Generic enough to work
for arbitrary object graphs (IEnumerable), System.Xml, and System.Data.

I would like to see how they could make LINQ depend on something as
specific as Avalon & Indigo, while still permitting it to be generic
enough to work with what they've said it would work with.  (I seriously
doubt that it could be done in any rational manner.)

This doesn't mean that other features couldn't be introduced that depend
on the newer WinFX libraries, but even if WinFX isn't termed ".NET 3.0,"
does that really change anything?  Really?

If they _don't_ call it ".NET 3.0", they'd instead require that your
future applications depend on both ".NET 3.0 w/o WinFX" + WinFX -- i.e.
you'd need two dependencies instead of just one.  And nothing stops them
from making ".NET 3.0 w/o WinFX" from depending on WinFX (as a circular
dependency).

There are _far_ better things to spend your energy on.  The naming of
WinFX is quite inconsequential, and was done primarily to keep the
dependencies sane for ISVs (only one dependency to install, not two) and
marketing purposes (to kill the "WinFX is going to replace .NET!"
insanity from those who really don't know any better).

 - Jon