[THIN] .NET framework -- thin client industry acceptance

  • From: "SteveC" <stevec@xxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Sun, 14 Dec 2003 11:04:32 -0500

I am not running a TS/MF "large" server farm by any means, installations I
have dealt with in my travels have never crested over 100-200 simultaneous
users on 2-6 hosts in a farm.

However, I think .NET should be part of a standard install, tested and
integrated into any TS/MF setup out there.  Just you used to always make
sure you had the most up-to-date versions of the IE, VB6, and MDAC (and
sometimes VFP) runtimes installed, you should take the .NET one into
account.  

For one thing, v1.1 of the framework is a standard part of a Win2K3 server
load, and you probably don't want any surprises when going to that platform
when (not if) you upgrade, so understanding it now is a really good idea.

Multiple versions of the framework can sit side-by-side on any computer.
Microsoft worked very, very hard to make .NET like Java in that a
framework/runtime installation lives only in a given directory and changes
only affect that directory.  To test what I mean, start up FileMon from
SysInternals, then install .NET v1.1, then v1.0, then SP1 for 1.0.  Then run
a .exe that was compiled for v1.0 and one for v1.1 - they never touch each
other.  If you want to disable v1.0 on a system, it's as easy as renaming
the "v1.0.3705" directory to "v1.0.3705-idontneedthis", and now the 1.0
runtime can't be used.

I would choose a "new style" .NET application over an "old style" (MFC, VB,
VFP, etc) any day.  .NET Winform apps (and services) either implement
re-writes of Win32 that was very hard to create or wrap hard-to-use
functionality.  For example, it is easier for a .NET developer to do screen
drawing for an MDI application and give it a taskbar icon for status events,
compared to a non-.NET programmer.  So you can be more comfortable as a
TS/MF admin that the program is going to do what it is supposed to do,
because a developer usually takes the path of least resistance in
development.  To get the same MDI/taskbar functionality, a programmer making
an equivalent app in VB/VFP/VC++ is going to have to make something custom
(possibly buggy), use an ActiveX controls (possibly requiring a user to be
an Administrator or worse), or do something undocumented (which might not
work at all under MF).

The security layers in .NET are also very well thought-out.  As an
administrator, you can decide if *any* .NET program will run at all based on
your certificate, or what users can run *any* .NET program based on roles.
CLR Code Access Security grants permissions to use .NET apps to users, and
declarative security attributes (essentially in-app ACLs) give even more
fine grained control.  

Installation in .NET, along with versioning, is very well thought-out as
well.  Versions of applications run side-by-side, just like the
runtime/framework itself, and applications each have their own PKI-derived
signature, which goes beyond the GUID/typelib sceheme of traditional Windows
apps.  If you install version 1.0 of a well-written COM application, then
version 1.1 in another directory, then version 1.0 again, you will have to
work from a "negative assumptive" standpoint that there might be a support
DLL conflict somewhere.  With .NET, because each version runs independently,
you can take a "positive assumptive" standpoint.  It's a little easier on
your nerves.  ;)  Plus, no-touch-deployment WinForms will allow any user to
logon to a MF session and "launch" an app, when it actually downloads over
HTTP into the users %temp% space and runs, and when they close their session
the app goes away - now that is ease of installation.

I don't think the "compact" argument is a good one against .NET.  Even if
you have versions 1.0, 1.1, and the upcoming 2.0 installed on a system, you
are talking somewhere in the neighborhood of 75mb of runtime.  I don't think
that's an unreasonable amount of space on any server that runs MetaFrame.
And the .NET executables are tiny in comparison, because all the stuff they
need/use is in the runtime already.  I put together a standard data-entry
WinForm with some grids and some bells and whistles and it came in around
50k.

On the stability issue, a .NET app's metadata can be read, so you as an
admin have extra ammunition in looking at an app to see where/if any unsafe
or possibly unstable code exists.  In a non-.NET app, that is nearly
impossible without serious tools and knowledgeable staff.  A .NET
application is not necessarily 100% managed code, sometimes P/Invoke is
required to do a special function that is not in the framework.  However,
managed does not necessarily mean stable (I can write an app that constantly
divides by zero and runs your CPU at 100% in .NET pretty quickly) and
unmanaged does not necessarily mean unstable (I have called/used the
unmanaged CAPICOM DLL from .NET apps for 3DES), but as an admin you can grab
Anakrino or any of the .NET app assembly-viewer tools and peek at the
metadata yourself and see if you care.

All modern windows apps have dependencies.  A "pure Win32" app is going to
rely on MFC and who knows what else.  Part of the problem is that it was
hard to develop certain kinds of apps, for example those that behave under
TS/MF, and "pure Win32" was kind of like the wild west.  With .NET,
Microsoft is attempting learn from their Win32-anything-goes mistakes (and
some stumbles that the Sun/Java world made) and create a new platform for
developers to use. 




---orig
From: "Alexander Danilychev" <teknica@xxxxxxxxxxx>
Subject: [THIN] .NET framework -- thin client industry acceptance
Date: Fri, 12 Dec 2003 21:34:47 -0800

Hi,

I would like to solicit opinion from people that run large server farms 
regarding .NET framework acceptance, i.e. whether .Net is common as a 
standard install.

As we all know there are new applications on the way that require .Net 
framework (20Mb+) with 2 flavors of .Net already out there (3rd on the way).

If given a choice between two identical applications -- "old style" 
Win32(/64?) and a new, ".Net" based, which one would you choose?

".Net" should be more stable if it is a "100% managed code" application with

advanced UI.

Win32 apps are usually more compact and do not require acceptance of ".Net" 
;) In fact these apps can be self-contained with now external dependencies 
and thus easy to distribute.

Anyone ?

********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
*********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm

Other related posts: