Is Desktop .Net Dead?

[dilettante]

I've been scrounging lately trying to determine whether to put more effort into a move to .Net technologies. No matter what we might like the state of development to be, there is still a strong persistence to the 2-tiered application model: a fat, fat client application hitting a back-end database.

What I keep bumping into are the same facts over and over again:

[ul][li]The .Net redist package (runtime, if you will) is a bloated pig at well over 20MB.
[li]Each release is even bigger (betas, RCs, 1.0, and 1.1 so far).
[li]J# just means more stuff to install.
[li]Few corporate shops have any plans to deploy .Net to the desktop.
[li]Longhorn is years away, and deployment will take even more years. How many shops have even begun migrating to WinXP?
[li]The whole thing is still very much in flux. We can expect another new release within 12 to 18 months. More deployment headaches.
[li]You see very, very little on Scripting for .Net, and what is out there dates back to 2001.
[li]VSA seems to be a dead technology (VSA was to be the VBA for the .Net world). VSA's vaunted IDE doesn't even seem to be available anymore.
[li]Even Office 2003 still incorporates VBA.
[li]I see no hint of an IE version release supporting .Net until Longhorn debuts. Yes, I know about .Net components via the <object> tag, that's not the promised level of support though.
[li]Remember all that talk about &quot;rich, Windows Forms&quot; clients deployed over the 'net and talking to back-ends via web services? Anybody doing that?
[li]We are close on the heels of 2004. Who is running any &quot;killer&quot; desktop tools built with .Net? IM clients? Archive utilities? Encryption tools? Graphics software? PIMs? Sheesh! Text editors? Games?[/ul]
So where are we?

In my view .Net remains locked as a server technology. For the most part a server technology to support n-tiered architectures where n > 2. The problem is, many clients are utterly uninterested in investing in the infrastructure necessary to support anything besides 2-tiered applications. It can be tough enough just to get the smaller guys (< 100 seats) to buy into the idea of a server supporting Oracle or SQL Server (&quot;why can't we just keep using Access and our file servers?&quot.

I'm not suggesting .Net is dead. Where permitted it does a great job server-side. But using it on desktop machines just doesn't seem to be materializing as a realistic option.

&quot;Deja vu all over again.&quot; Remember Java?

How are others handling this? Am I missing something that ought to be obvious to me?

 

[chiph]

sleipnir214 -

So, they're not releasing multiple interim versions of Visual Studio that users will have to upgrade annually in order to keep current in .Net?

I've met one of the guys who worked on .NET, and he basically said that they decided on a feature set that they felt the typical developer could write an application with. Certainly .NET isn't 100% complete at this point -- one of my pet peeves is that the email classes are nothing but wrappers over the COM CDO component (i.e. slow, fragile, & feature-poor). One of the consequences of .NET not being &quot;done&quot; yet is that you have releases every few months or so to correct things & add new functionality.

How often to have product releases is a balancing act - if they come out with them too soon, the ISVs are in continuous upgrade mode and don't have time for writing applications. If they wait too long, then some of the problems (design, implementation, and otherwise) don't get fixed quickly enough, and they have to issue service packs, which are really expensive to do.

Like dkediger says, Microsoft so far has done a good job of maintaining backwards compatibility. They've also allowed for people having multiple versions of the framework on their PCs, so if you've got an app that was written against the 1.0 Framework, you can still run it without penalty. I've been very pleased so far.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[sleipnir214]

chiph:

It sounds to me, then, that while they figure out .Net, Mi&cent;ro$oft had better be giving the upgrades to Visual Studio and not charging for them.



You seem pretty hip to what's going on with .Net, so let me ask you the $64 question:

What will .Net on the desktop give me that I don't already have? I can see its benefits from a client/server standpoint, but what's the benefit of the additional complexity on a standalone desktop?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[chiph]

What will .Net on the desktop give me that I don't already have? I can see its benefits from a client/server standpoint, but what's the benefit of the additional complexity on a standalone desktop?

The ROI comes in with faster time-to-market, more robust code (due to object-oriented development and try..catch exception handling), and improved software quality.

Of course, you can still write bad code with it, just like you can with any other tool, but generally, the framework guides you into doing things the right way.

But back to the desktop question -- because .NET is written around MSIL (Microsoft Intermediate Language), if MS were to change operating system platforms in a major way (either by going to 64 bits, or possibly a more radical change like switching to PowerPC CPUs), all that would be needed is a new runtime. So the benefit then is that your application (provided it only uses .NET calls) is potentially portable.

And... speaking of portability. As you may have heard, Novell recently bought Ximian, the folks working on Mono. They've just released their product roadmap:

http://www.go-mono.com/mono-roadmap.html

Which says that Mono 1.0 will be released 1Q2004 or early 2Q2004. There will then be a Mono 1.2 which will have many of the features announced in Whidbey (Generics, etc), as well as (finally!) support for Windows Forms.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[tipmiser]

1.0000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000001:1 that a lot of apps don't
work on the new WinFS of the Longhorn dev project. And really, Longhorn
probably will be a much delayed product.

Is Longhorn supposed to be a more robust, enterprise OS?

Because, really no Windoze version yet can match a Unix server in the data center.

 

[chiph]

> that a lot of apps don't work on the new WinFS of the Longhorn dev project. <

That may be true. Everytime a new version of Windows comes out there are some apps that don't run because their developers didn't follow good practices.

> Is Longhorn supposed to be a more robust, enterprise OS? <

Longhorn is intended for the desktop, so it will be a replacement for XP. I expect it will need Windows Server 2003 on the backend in order to get the most benefit from it.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[MasterRacker]

May or may not apply but here's oodles of .NET info:

http://searchwin2000.techtarget.com/bestWebLinks/0,289521,sid1_tax285410,00.html

Jeff
If your mind is too open your brains will fall out...

 

[jsteph]

<<Of course, you can still write bad code with it, just like you can with any other tool, but generally, the framework guides you into doing things the right way.>>

Does .Net force good practices? Does .Net disallow outside code, ie, standard C++ or VB .dlls? No to both. I'm not trying to be negative, but human nature shows that the same people who code badly now will code badly in .Net. They'll just not use the Try/Catch error handling model in the same way I see so many VB apps with NO error handling whatsoever except to say &quot;Damn user keeps keying in the wrong values&quot; and other deflections. They'll incorporate their existing .dlls because .Net allows that, and they'll think up some other excuse when the next OS crashes their app that uses such .dlls.

The good part of this for the .Net crowd may be that those poor coders will not use .Net, keeping the 'gene pool' of .Net coders clean, but that's not in MS's best interest as far as market share and visibility of .Net, which is possibly one reason .Net allows such practices. C++ has, from what I've seen, more disciplined coders in general, but far fewer custom apps are done in native C++, instead RAD solutions, generators, powerbuilder (is that still around?), and 4Gls like VB are preferred. You can't squeeze blood from a turnip, and as chiph's tagline says--there's no such thing as a free lunch--good coding won't come to bad coders just because of a new language. We'll still see poorly coded, innefficient .Net apps in large numbers, just as we do today with many VB and generated apps.

As far as I can see, the point about portability to other *Microsoft* OS's is a reasonable direction, but doesn't that go back to the often crippling issue of 'least common denominator'?
--jsteph

 

[chiph]

The good part of this for the .Net crowd may be that those poor coders will not use .Net, keeping the 'gene pool' of .Net coders clean, but that's not in MS's best interest as far as market share and visibility of .Net, which is possibly one reason .Net allows such practices.

I try not to get into talent-wars, but I do recognize that some developers are better/worse than others.

For example, I just pointed out (again!) in the VB6 forum that using the Replace() function to double-up single quotes in string-concatenated SQL is a Very Bad Idea. But I'll be ignored because it's easier to do it the bad way. Inertia is such a drag.

We'll still see poorly coded, innefficient .Net apps in large numbers, just as we do today with many VB and generated apps.

In the VB.NET forum (I hate to keep picking on VB, but if the shoe fits...), there was someone who didn't want to nest their try..catch blocks because it caused too much indenting in the code. Someone else suggested they break it up into two functions then. To which they basically said that doing so was too much work.

What do you tell them in that situation? &quot;Dude, you're making dumb decisions&quot; is probably not what they want to hear.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first