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?

 

[jsteph]

<< If however I need to make make changes to a part of it (like a dll)
ThunderBear,
From a technical standpoint, is that possible with .Net? Can you use .Net to rewrite a .dll used in a non-.Net VB project, and will it work on clients without the clr? If that's possible, (ie. total backward compatibility with non clr clients) then that sounds like a good opportunity for us to wet our feet in .Net to prepare (or hedge) for the future.

If the clr is needed, it would be a hurdle for us now to prepare all clients, but moving into the future it sounds like the clr will be an integral part of the new MS OS's.
--jsteph

 

[chiph]

From a technical standpoint, is that possible with .Net? Can you use .Net to rewrite a .dll used in a non-.Net VB project, and will it work on clients without the clr? If that's possible, (ie. total backward compatibility with non clr clients) then that sounds like a good opportunity for us to wet our feet in .Net to prepare (or hedge) for the future.

jsteph -
Sure is -- you write your .NET assembly with a COM-callable wrapper (CCW -- also called COM Interop). Then any COM-aware application can call it. Works best when your application is already architected in a modular fashion.

Dilettante -
I've been holding on on contributing to this thread even though, as you may know, I'm a big fan of .NET.

In your list, you put the size of the redistributable (20mb) as number 1. I believe that this is only a concern for shrink-wrap software authors. Anyone who is in a corporate environment (medium-to-large size companies) will likely already have an automated software distribution system. For the shrink-wrap guys, yeah, they have to include it on their distribution media, as they cannot assume that their users will already have it installed.

Since anyone doing development of any size is probably already using CD-ROM for media, adding another 20mb of data to it only has a slim chance of bumping the size up enough to require a 2nd CD. And even so, that's only another 50 cents in cost (plus some for the duplication costs, etc).

It's the smaller companies who will have a problem with the runtime -- the kind of places where the IT staff walks around from desk-to-desk installing software.

Even there, all they have to do is go to Windows Update, launch it & walk away, telling the user to reboot when it tells them to.

Chip H.


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

 

[dilettante]

Thanks for your input chiph.

I didn't begin this thread to take a potshot at .Net in general. My point is that it seems to be very much like Java in many regards, especially in terms of its greatest success being at the server rather than the client.

What I was &quot;fishing&quot; for was a better sense of how much this might not be true (i.e. how widespread are .Net client and standalone applications). Further, if the deployment of the runtime environment is not what is slowing this, then what is?

I have the impression that while JVMs are large and have quirks among them, desktop Java was impeded by other issues. Slow execution, clunky GUI packages, and so on. This isn't meant as a swipe at Java either, I'm just saying I don't see much in the way of Java on the desktop aside from web applets here and there.

The shrink-wrap software sources do indeed have CDs as a deployment medium, and this addresses the size issue for them. Smaller outfits doing Internet (download) deployment are stymied though, but they can always offer CDs as well as downloadable &quot;slim&quot; distributions (letting the customer install the redist package on their own).

But users in corporate environments are running into snags. Two of my larger clients are resisting deployment as unnecessary, and choose to &quot;wait until there is demand&quot; before rolling it out. The security policies in place prevent the users from self-installing anything (including security patches). The ability to deploy the redist does me no good without the will and some follow-through. This leaves me in a &quot;chicken and egg&quot; situation. I can't provide .Net solutions until the runtime is there, and there won't be a runtime until there is a large enough application suite to force its deployment.

This is almost a non-issue in small shops. Where I get resistance is in places where they have &quot;network administrators&quot; who don't want the boat rocked. They typically cite version 1.1 and now Whidbey as &quot;evidence of instability.&quot;

Maybe I'm not being clear enough. I'm not trying to argue specific points. I'm more interested in whether or not to expect .Net on the desktop to take off anytime soon. Right now the lack of &quot;.Net ready&quot; clients prevents me from letting my team move in this direction. In most cases these desktops haven't even moved to WinXP, so I can't hold my breath for a quick Longhorn depoyment either.

 

[theoxyde]

True enough on the desktop end. The main reason that it has taken off as a server tool is because you simply don't have to deploy anything to the client system to use it -- only the server. Java probably wouldn't have ever become a household word without its server capabilities either.

Slow adoption of new technologies is not a new thing. However, if the CEO of Xyz company decides to buy into a new application package that requires the .NET framework, it will probably get deployed. The aforementioned &quot;don't rock the boat&quot; admins are always going to be there and we would all still be using Win 3.x if they had their way.

There won't ever be a demand for the framework, per se. Nobody is going to be looking specifically for a .NET app, but the apps may demand it. Our shop is like many others. We have loads of VS6 apps that aren't going to go away anytime soon, but all new development is being done in .NET. Some of the old apps are being rewritten in .NET if there is a particular feature .NET brings that will make it worthwhile.

 

[chiph]

I have the impression that while JVMs are large and have quirks among them, desktop Java was impeded by other issues. Slow execution, clunky GUI packages, and so on. This isn't meant as a swipe at Java either, I'm just saying I don't see much in the way of Java on the desktop aside from web applets here and there.

We actually use a desktop Java product at work to track our time. Biggest complaint I hear from my coworkers is that it &quot;doesn't work like a Windows app&quot;.

I fooled around with Java back in the 1.0 JDK days, and you're right - no one would seriously want to use it for developing an application. It took about 18 months before the decent development tools came out & people started to understand the new technology. With .NET, that 18-month long teething period is about over -- the folks who were using Notepad & csc.exe to build their apps are moving to VS.NET, and it's now a stable product that developers can use to write shippable code.

I can't provide .Net solutions until the runtime is there, and there won't be a runtime until there is a large enough application suite to force its deployment.

When they upgrade to MS-Office 2003, the framework will be there. Or, like I said, run WindowsUpdate to get it. It's also already in Windows Server 2003, so server apps should be an easy sell.

This is almost a non-issue in small shops. Where I get resistance is in places where they have &quot;network administrators&quot; who don't want the boat rocked. They typically cite version 1.1 and now Whidbey as &quot;evidence of instability.&quot;

They just don't want to add to their workload!

Seriously, Network Admins will *always* oppose new software because it represents a change to the environment, and to them, change is bad because it causes instability, and instability means they don't get their yearly bonuses. You have to get the users on your side -- you as a vendor will never get the admins to agree with you.

I'm more interested in whether or not to expect .Net on the desktop to take off anytime soon.

Honestly, I would expect to see large desktop apps very late in the rollout. Writing a product that is a) non-trivial, and b) depends on the users having the framework, and c) having security set right (so they have permissions to run it), is a huge risk to someone like Lotus, or any other large ISV. They don't want a zillion support calls &quot;When I run it from the network share, I get a security error!&quot;. I expect we'll start to see internal apps (for clients with internal development staff) very soon now, as they are writing to solve a business need, and they can control the runtime environment.

One of the things I noticed way back when in the Java rollout is that a lot of companies had an initial &quot;splash&quot; of announcements, and then things got quiet as their development teams went to work. About 2 years later is when you started to see the product GA date announcements. So I would expect to see more commercial apps shipping in the next 6-12 months.

Chip H.


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

 

[MasterRacker]

According to this article, Longhorn, by MS strategy, is what is going to drive .NET on the desktop.


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

 

[MasterRacker]

Woops! Forgot to paste the link:

http://rss.com.com/2009-1016_3-5103226.html

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

 

[sleipnir214]

Anybody have a comment on this article?

http://zdnet.com.com/2100-1107_2-5108026.html

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[jsteph]

Amen.
--jsteph

 

[dilettante]

Well, I hate being controversial, because it sure doesn't get me anywhere. But...

Who is this guy who wrote the article? Longhorn suite?

All I've heard of is Longhorn the desktop OS, along with an assemblage of technologies that make it different from, say, Win XP.

I have no idea how he dragged Java into the discussion of desktops. Desktop Java is hardly much of a living and breathing beast either as far as I can tell.

To me anyway, this guy just comes off as yet another &quot;anybody but Microsoft&quot; troll in a Java tee shirt.

Myth #1 Well, the guy's an idiot, that's clear enough. He seems to think Loghorn is an Office release.

Myth #2 Random spewing and subjective assertions (and bears, oh my!). Almost as bad as this (my) post.

Myth #3 Again, I can't see the dots he is trying to connect. Java vs. Longhorn? I don't see the comparison here at all. Nobody said you can't run Java on a Longhorn desktop. Maybe he's trying to allude to some of the new application environment technologies Longhorn offers such as Avalon, WinFS, and Indigo?

Myth #4 I'm lost again. He starts out talking about customer upgrades but his rant only discusses developer tools.

Myth #5 Lots of whining and moaning about &quot;standards&quot; here, but then he reveals himself to be an IBM lackey. I don't think there is any platform more proprietary, clumsy, or expensive to develop for than Websphere, but I admit I haven't looked at BEA's recent offerings. Are we supposed to drink that Kool-Aid? I see shops bringing in Websphere as an excuse to offshore their development, where IBM and partners have lots of low-ball contractors standing at the ready.

Summary: Pretty amusing article.

Conclusion: Check his credentials, he works for an IBM Partner peddling Java & Webshere training and certs and consulting services (how did I guess?).

Another link (though a year old):

http://www.objectwatch.com/issue_42.htm

 

[sunila7]

I agree with dilettante this guy doesnt seem to know head or tail of what he is talking about

Sunil

 

[sleipnir214]

So nothing he says has any validity?

There are not, for example, multiple interim versions of Visual Studio .Net on the horizon?

Do users commonly use more then 30% of the features of a product?

That Microsoft has made public the standards that will make Longhorn work, so that they aren't closed-spec?

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[dilettante]

I'm sorry, sleipnir214, I should have bitten my tongue. I wasn't trying to start anything heated and I should have abstained from posting in a knee-jerk manner.

I don't think the issue is whether the author might have had a fact right here or there or some valid positions. What struck me was the way he seemed to lash out at random. A lot of it was just plain wrong too, especially his point about interoperability in &quot;Myth 5.&quot;

The article started out as if it was a criticism of Longhorn. This quickly turned into some kind of Java (vs. what?) issue, and ended as a Websphere commercial. Maybe I took the whole thing wrong, and should have considered it in the context of this thread regarding development of desktop .Net applications. If I look at it that way, the part in &quot;Myth 4&quot; where he mentions the proliferation of Visual Studio releases on the horizon does fit right in here. I agree it is quite relevant to the original thread topic.

Mr. McCune might have made his case better if he had presented it as a contrast between the new .Net application models (as well as the tools) to be introduced with Longhorn vs. other alternatives.

I'm still confused by his &quot;Myth 1&quot; meanderings. Maybe somebody can explain it to me.

In &quot;Myth 2&quot; he seems to be complaining that the Longhorn roadmap offers choice. Of the choices he listed, he seems to want to lock the world into his choice #3: Java. By the way... which one is Windows? Hardware or middleware? ;-)

Longhorn supports desktop and client applications. So I don't see why he dragged in Java (dead on the desktop, on life-support as a client) or Websphere (clearly server technology). I suppose that's why so much of what he said seemed out of place.

I think I can stand by my previous post on this article. Rereading both the article and my own blathering above still doesn't change my impression very much. I should have been much more thoughtful about presentation though.

 

[chiph]

I agree with dilettante -
The guy at ZDNet just sort of rambles on, and has a conflict of interest.

I'd be more inclined to listen to Bob Cringley:

http://www.pbs.org/cringely/pulpit/pulpit20031113.html

He's got a better track record of being right (or pretty darn close).

Chip H.


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

 

[SpiderBear6]

LOL - Great article Chip... thanks for that.

 

[sleipnir214]

But was the article I posted factually incorrect? Particularly the facts I questioned?

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[Tarwn]

Yes there are interim versions of VS.Net planned, no I doubt most users even use 30% of features in a product (and I seriously doubt anyone uses 100% when we are talking about larger app's like office apps), and yes MS has pushed several protocols Longhorn is based on/using through standards committess and they have been adopted as public standards.

As far as the rest of that article, it's obvious that it is merely the authors already conceived thoughts on the matter. There was likely no research involved and very little planning and it's more of a &quot;This is my opinion, I won't tell you where I get my facts, you just have to listen to it&quot; article than an informative read, but hey, think dilettante pretty much covered a lot of the issues I had with it, so I will leave it at that.

The second posted article was interesting, and also mostly an opinion-based article, but definatly written with more forethought and clarity. As far as the content, I found it an interesting way to interpret MS's goals and actions, but not really that informative on the whole Longhorn subject.

Anyways, just my reactions and thoughts,
-T

_{01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111}
The never-completed website:

http://www.tiernok.com/

 

[chiph]

sleipnir214 -

The part of the article dealing with .NET &quot;interim&quot; versions is being disingenuous. It's like asking why Microsoft didn't release Office 2003 first, rather than going through 10 prior iterations.

Tarwn -

Bob Cringley used to be the gossip columnist for ComputerWorld magazine. He's the one who started the whole &quot;Spencer the Cat&quot; thing. He got fired at some point for cheesing off one of their big advertisers, and so he's gone freelance. He's also the guy who wrote &quot;Triumph of the Nerds&quot; that got made into a PBS miniseries.

(No, not the one with the Tri-Lambdas vs. the Alpha-Betas. But that one was fun to watch too). ;-)

Chip H.


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

 

[sleipnir214]

chiph:
Your analogy is flawed. 10 years ago, Mi&cent;ro$oft could not possibly have known where development of Office would have taken them by today. They do know where Office is going in the next several years.

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?

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[dkediger]

Maybe current in the latest tweak to the framework, or eventually, the final version of the Longhorn system objects, but they haven't so far made it backward incompatible or hinted that they will.