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]

I've said it time and time again--.Net is just another desperate attempt at a virtual machine. Been there, done that--with Java. It only works if every desktop buys into it, and that's not going to happen (but aren't 90% of desktops microsoft anyway--so why again do we need a virtual machine??).

My first experience with Java was trying to get a Java web app--that ran fine on 'my' machine--to run on 5 different 'identical' machines in a classroom environment. Each machine gave a completely different Java incompatibility error. An they were all Windows. Didn't even wait to see what incompatibilities I'd get with linux or sun, etc, etc. I dropped Java then and never regretted it.

But Steve Ballmer will still put on his evil-clown smile and tell everyone that .Net is the future and we must all assimilate. Been there with Microsoft. Why trust him this time?
--jsteph

 

[theoxyde]

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?

Yup. Sure, we still design a lot of the two-tier stuff as well, but all of our secure info is implemented using a web service as a trusted-front-end and encrypted for transport over the network.

Who is running any &quot;killer&quot; desktop tools built with .Net?

Again, yes. Certainly, our &quot;killer&quot; apps are all in-house, but they do things that no commercial product can. We are using .NET for document retention, encryption, and yes... even an in-house designed Instant Messenger that has reduced a major load off of our Exchange server.

.NET is certainly not the &quot;silver bullet&quot; that MS made it out to be, but honestly, who in their right minds believed it would be? Personally, I would love to be able to use .NET assemblies in a C# function from Excel, but that would just be one more tool in the toolbox. But that is the way all technologies should be... tools. MS will likely try to force more people to .NET in the future, but they run the risk of alienating even more potential clients to more open systems (myself included).

.NET has been very good to me for designing applications, but it isn't the One Way. I'm sure I could figure out how to implement much of the same applications without the .NET framework, but I haven't had any complaints thus far about having to install it.

 

[sedj]

>>>> jsteph : a Java web app--that ran fine on 'my' machine--to run on 5 different 'identical' machines in a classroom environment. Each machine gave a completely different Java incompatibility error.

This was probably due to your unwillingness to give Java a go (or understand it's deployment procedure). We develop on Linux and Win32, and then deploy on Linux and Solaris - with no inompatiblity problems. You just need to know what you're doing. Every language has its idiosyncraices.

 

[jsteph]

sedj,
<<Every language has its idiosyncraices

But that was my point about Java--java was supposed to not have those issues--the mantra was &quot;Write once, run anywhere&quot;. Sure, anyone can go to each client machine and make sure you have the correct version of Netscape, or IE, and the plug-ins, etc. etc.--then yes, I'm sure it can work. But that's too many 'ifs'. I can do that with a VB app--make sure all the client's have Windows, then run the setup.exe and bam--I'm there. Java was supposed to do away with all of that, and in my opinion, there's still some micromanagment of client machines neccessary for a Java desktop app to work. Same with .Net--a 27 meg (compressed--I'm sure the actual footprint is larger) install is not trivial.

Anyone can make a 'virtual machine' and have their programs run in that vm--IF you ensure ALL clients have that vm loaded. Not much different than saying &quot;my VB program runs anywhere--as long as Windows is loaded and setup.exe is run&quot;. How much different is that than .Net? Consider, in the early '90s I remember seeing alot about Windows Emulators for the mac, sun, etc. Back then one of the issues was that you'd have to put this huge thing on the machine, about 12 Meg back then if memory serves. .Net is essentially a Windows Emulator. Huge by the early '90s standard, but I concede it's not so big by today's standards. And the verdict isn't even in yet on how .Net apps are running on Sun, Linux, and Mac desktops ( I'm talking about .Net desktop apps--not web apps using .Net).
--jsteph

 

[Tarwn]

Firstly, I have written some &quot;killer&quot; apps in .Net, multi-tier and all the fun stuff.

Secondly, I have to agree on your Java experience. It's not correct to compare it to havng VB running on a windows machine with setup.exe running, the problem in that statement being Windows.

Also, interpreted languages are not running as if they were on a Windows emulator (or to reverse, if your using Python). The VM/Framework/Interpreter is tying into the specific system commands for that OS while emulators are applications that simulate the original designed for environment with no real tie in to the actual platform they are running no beyond the fact that they were compiled tio run on that platform.

Yes, I agree the .Net framework is bloated and eating 15,000k just starting a .net program is a little nasty, but I remember all of these comments being made when Java came out and rather than be an underdog it's oine of the major languages taught on the university level now.


And as far as platform compatibility issues, write it in Java and make the one or two changes it may take to work on multiple platforms, then write it in C, get your hands on several differant compilers and start making that work for every platform...

-T

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[jsteph]

tarwn,
Ok I'm starting to get a clearer picture of .Net. But how, for instance does the .Net framework deal with, say a Mac, or Aix on, say a big IBM box? Aren't we back to the 'least common denominator' here--that you can only work with the intersecting set of commands that are common to every single platform you hope to run on?

For instance, one may be able to write a .Net app that can run on all platforms, but--and I can't think of specifics offhand--I've got to guess there are a lot of commands or functionality that are very useful that are Windows specific, and that a program may rely on some of these things. How would that be translated to, say, a unix based machine? Specifically, say I have a VB app that makes extensive use of the Windows API. Let's say this app is enterprise-wide and a core app. We just accquired a division that has Linux workstations on some risc box. I want to convert this app to .Net because I'm falling for all the hype about a .Net app being able to run anywhere. What would you say are the chances that this app could be successfully converted with full functionality to run on all platforms? And wouldn't it be cheaper to convert the new division to wintel workstations?
--jsteph

 

[Tarwn]

The chances are probably not all that good considering that the last time I checked the status of free projects working on frameworks for *nix systems they weren't really done (though it has been a while).
Depending on what the app does and how solid the current version of it is, you might be better off replacing the nix boxes (which will piss off a lot of new employees from the other company) or write a version for those nix boxes that ties into the existing system, which should take less time than developing one version to work on both.

Technically, I guess, thats against the the whole spirit of write once run anywhere, but I haven't seen .Net actually achieve more than the capabilities for that yet. There are several other OS-specific frameworks out there, in various states of completeness, but we have not yet gotten to the point that Java is at (or Python for that matter).

As far as tying into core-Windows libraries: Yep, the Windows framework does do that, but then the BSD Framework will tie into core-BSD libraries, the MacOS-X version will/does tie into many of the same libraries as the BSD version (similar undercarriage), etc. Thats sort of the idea. Sure funciton A will be more efficient on OS A because OS A has a better inner implementation of that function, but Fnction B may actually be faster on OS B because it has a slightly more effificent internal method of handling those types of calls.

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[dilettante]

Hmm... I don't recall any promises that .Net applications would &quot;run anywhere.&quot; It was developed and introduced as a Windows technology.

Going beyond that though, specifications for several chunks of the technology have been offered to standards bodies. This is the enabler for efforts such as Mono, but even Mono is only targeting Linux for now as I recall, though I agree that a Linux Mono could be used as a stepping-stone to other Unix-like and Unix platforms.

The only obvious way for non-Windows users to employ .Net technology right now is to use some non-.Net client to access a server running .Net mid-tier applications. This could be a C or Java client application using web services via SOAP where the services are .Net applications for example.

My original question was asking &quot;are people deploying .Net client applications on Windows?&quot; The idea of doing this on other client platforms seems quite a bit more remote than that.

Indeed, the primary differences I see between .Net and Java are:

* .Net is language-neutral, Java is Java.

* .Net is for Windows, Java promised &quot;write once run everywhere.&quot;

 

[jsteph]

Are there any plans for MS to convert their own applications to .Net? For example, Office 200x, if it were written entirely in .Net would open this MS Office for use on any platform, most notably Linux boxes.

This of course increases the MS Office sales, but would hurt their OS sales since I'm seeing that one of the major reasons Linux hasn't taken off is because most businesses use MS Office in their day to day operations. And the other xOffice type apps (StarOffice, Ximian, etc.) aren't up to par or compatible with what these businesses currently use. If this hurdle were overcome, then I think we'd see Linux take of in a huge way.

My guess is that MS would rather control the OS market than the Office market, but if they see Linux start to gain market share on it's own, that is, without the help of MS Office compatibility, then MS may change their mind on this.
--jsteph

 

[jsteph]

dilettante,
I composed my last one before your last message was posted, so I guess my questions about Office and .Net on Linux are moot.

But if .Net is Windows-only, one of my original questions was why isn't windows already compatible with itself? Why do they need to introduce all this complication just to make a Windows app compatible with Windows? I guess one thing is the language-neutrality, but how is this playing out? And doesn't that also have some sort of 'least common denominator' issue as well?
--jsteph

 

[dilettante]

jsteph,

Seems like a very good question to me too.

I suspect that .Net was inspired by a number of things offered by Java.

A big one is security related, the whole &quot;managed code&quot; bit to protect the OS and other applications as well as databases and other storage.

The other big one may well be to isolate applications from the underlying hardware and OS. While some of the 64-bit processors are largely i386 compatible, others are less so. There is also the issue of small platforms such as handheld computers, phones, and so on - which typically use very different processors and Windows OSs. Also along these lines, trying to get people off the old DOS-based Windows has been a very painful process. Some applications were just too hard-wired into Win9X and application compatability issues consumed enormous resources at Microsoft - part of the reason for XP's &quot;bloat.&quot;

In general, making Windows applications compatible across different flavors of Windows.

There were other issues of course, such as trying to get away from traps and dead-ends in the older architecture. DLL-Hell is one of these.

But .Net also offered an opportunity to &quot;move on&quot; in many other areas. ASP was a really great thing for Windows web developers. It suffered from a lot of ills though: performance problems due to interpreted script, state management headaches that had to be solved over and over again by developers, threading issues, ... a whole lot of things that ASP Plus (a.k.a. ASP.Net) addressed.

There was an opportunity to build on the lessons learned in using and extending ADO. Grafting things like remoting and client-side disconnected processing on was getting messy. So Microsoft now has the much more powerful and &quot;rationalized&quot; ADO.Net offering as a data-access architecture.

The whole web services, XML, SOAP, etc. shtick (hula-hoop?) was easier to integrate into a new platform at a fundamental level. All of this can be done natively on Windows, but it isn't quite the &quot;first class citizen&quot; there that it is in .Net's implementation.


Maybe somebody who's &quot;.Net feet&quot; are &quot;wetter&quot; than mine could give a clearer (and almost certainly more concise) answer.

 

[dkediger]

My .NET feet aren't any wetter than dilettante's, but his previous post pretty much sums up the overall breaks in .NET from the previous VisualStudio tools. Of course. Microsoft themselves have had a hard time describing the .NET universe.

Apart from the web services side show, at the most basic level think of .NET as a higher-order abstraction of the Windows/system environment to the coding environment than previous Microsoft APIs/tools. Similar to how the HAL is an abstraction of the physical hardware to WinNT/2K/XP.

Not to say that Microsoft is intent on producing .NET CLRs for other OS environments, but I think they have prepared themselves to do this if needed.

 

[MasterRacker]

(I must've been online too long today but I just can't resist....)

Here's what .NET is all about:

http://www.bbspot.com/News/2003/09/net_well.html

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

 

[dilettante]

Silly, somewhat off topic, but a giggle nonetheless.

 

[Tarwn]

From what I have gathered Microsoft is not planning on creating CLR's for any other OS's, thought employees have created a shared source version for BSD systems.

My comment above on &quot;run anywhere&quot; as it pertained to .Net is that it has the capability to have other CLR's written to allow it to &quot;run anywhere&quot;, but that doesn't mean CLR's will be written for all systems out there.

MS is looking at .Net as it's future. Messaging, Office, SQL Server, etc and so on will be moving more towards .Net. The next generation of windows (Longhorn, aka WinFX aka Windows Frameworks) will be all about .Net. They are looking at WinFX at being the next step in the cycle from MSDOS => Win16 => Win32 => WinFX/WinFS (WinFS being the actual file system).

I have a poster they were nice enough to give me that shows the major components of WinFX then breaks those down into all the .Net libraries. Lots of nifty stuff in there (System.Speech.Synthesis, System.Storage, etc).

In my opinion .Net is moving ahead strongly. Most languages have a much slower kick off into mainstream use, but of course MS has the name and language names so that helps.

.Net will be replacing the standard API's (or so they say).
64 bit processors will be getting increased useability with newer releases of the framework (well, AMD's and Itanium 2's).

MS is getting ready to whip up yet another version of Visual Studio (2004 I believe), so obviously they are depending on the success of .Net for their future. I think any company with that much pull (and cash) that depends on a suite of languages like this is going to be able to push them pretty far.

As far as my own uses are concerned, I haven't uninstalled VS6 yet, but I'll give it a few more months and if I still haven't touched it it's going to be sacrificed for more game HD space

-T

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[infinitelo]

dot net is far from dead, as the next version of windows will be based on the clr. the fact that it has the flexability to run managed and unmanaged code, it is a merging of languages, not platforms.

from a stratigic stand point being able to run source from other platforms on windows boxes but not the other way around would be a huge advantage. im under the opinion that open office was a wake up call for microsoft. the plan of attack will be over the next five years to get open source code running on windows boxes, without concern what platform it was intended for. Then for the .net developers an easy task of changing the user interface to windows forms and you get a much tighter hold on users than before (but it looks better in xcel, yea but is that worth $500?) why did we move the host file to /ect????

im not opposed to microsoft products, just the price and the life cycle of my computers is five years not three. the operating system has to outlast the power supply.


if it is to be it's up to me

 

[SpiderBear6]

I just want to make a small comment. Everyone is saying what a pain it is to have to install .net on every machine.

&quot;The .Net redist package (runtime, if you will) is a bloated pig at well over 20MB.&quot; - how is this a bloated pig? The average &quot;small&quot; hard drive these days is 40GB. Also once this is installed, to install the app is kiddies play and incredibly small. The setup of a decent sized app of mine fits on a floppy. If it's is pain of actually installing .Net, well we have always had to &quot;install&quot; software, why is .net a different pain?

 

[jsteph]

<<If it's is pain of actually installing .Net, well we have always had to &quot;install&quot; software, why is .net a different pain?
>>
That was part of what I was wondering--but from the other side.

Yes, I understand a bit more about the advantages of .Net, but my situation--a real world big-business situation--(in which a dozen or so of us voted on and voted .net down) was this:

We have a large, core enterprise order entry/scheduling/logistics system written in VB, using an IBM P670 backend. Yes, we've been through .dll hell, but after some (ok, many) headaches, it's gone.

We looked at .Net and many thought that it might help when we have aquisitions that were non-windows (which I now know is moot). We also have a C junkie on the team who was dying to have this thing done in C#.

Even with that misinformation, which worked in .net's favor, and a rabid c-junkie, my main reasons (as I suggested several posts above) and several others' were:

1.The cost of rewriting the app.
2.The many 'unknowns' of dotnet (even Gates himself said it wasn't fully ready yet).
3.Why?

These were too costly and too risky, and too vague, respectively to consider it.

We've got a setup CD now that will install this very complex app with one button press (thanks Wise), and it is truly a smooth robust app (thanks team), and also blazingly fast (thanks IBM). There just was no compelling reason to write that app or anything new for that matter--in .Net. Our add-ons and ancilliary stuff is all VB. And it works. .

So .Net will have to wait until it all shakes out--or until some compelling reason crops up--such as Gates deciding that Windows 2007 won't support any app not written in .Net. And that's a not as unlikely as some may think.

--jsteph

 

[SpiderBear6]

I totally agree with you jsteph. If the app you have is working and does what you want in the time that you are happy with then in my opinion there is absolutely no reason to rewrite it just because a new technology has come out. We are taking that stand in my office. There is no way I am going to write code just so that it is in .Net. If however I need to make make changes to a part of it (like a dll) which are fairly large (and would almost require a rewrite anyway), then I usually rewrite it in .Net. Any new development is done in .Net. So basically eventually most of our apps will be in .Net (except those that haven't been changed in years).

Too many people use the reason of &quot;It's a new technology&quot; as a justification to rewrite everything. Why does it have to be all .net or nothing? Just like the Java and Microsoft arguement... why do you have to choose all Java or all Microsoft... why not use which ever is best for the job?

As for the unknowns in .Net... haven't found any major showstoppers myself yet. I've written a windows app which talks to a web service on a web server passing information (which is compressed and encrypted) securely to it which is then referenced by another application. I am in the process of also writing a client/server based system for a company. The only real headaches I had were with the bootstrapper but that was solved by the release of the bootstrapper addin for visual studio.

As a side note: I personally think that Visual Studio.Net is light years ahead of Visual Studio in functionality and usability.