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