>Rick, I think you've focused in narrowly on the hype behind the ease of deployment issues for CLR applications; you .Net apps will be as sensitive to variants in the CLR as current deployments are to traditional versioning issues. What we're going to see IMO is an associated bloat in deployment size in the managed code arena, which will end up with multiple CLR engines being needed to reside on a single station, to be managed in a fashion reminiscent of the side-by-side COM and DLL version supported starting with Win2K. The encouragement of .Net developers to deploy with explicit reliance on tools like the Windows Installer technology will end up requiring the incorproation of that technology at the lowest levels of managed code implementation behind the scenes. In order to gain aceptable performance, greater burdens will end up being placed on execution platforms at all tiers, as each tier will require potentially multiple CLR engine sets, with slightly different versions of the
>.Net namespaces supported by each. Thank god the cost of local storage and system RAM is shrinking, because the cost of suppoting these things will bulk up the requirements of thin-client computing platforms tremendously.

I agree, if this how this will play out. I haven't been able to really dig out any information on versioning of the CLR and how it effects code, but at this point even with minor changes in the beta versions the exact version of the CLR needs to be running.

THe biggest problem IMHO is not so much the disk usage but the distribution issue - most software is coming off the Web these days via download and the .NET framework is a 30 meg download.

>At some point, there's going to be a realization that there are flaws in the web services model of computing where behaviors must cross the web service interface; the contract embedded in XML will need to extend to data as expressions of process intepretable in a common cross-platform engine, a la the UCSD p-code initiative of the 1980s, or more recently, the myth of cross-platform Java, which while stated as "Write once, run everywhere" is far closer to "Write once and debug everywhere".

Huh??? What does this mean? How does this relate to this topic?


>I don't see either as native language or development platforms; certainly, both have an internal script language, usable to either modify internal behavior through the creation of internally-interpreted functions, but there's no capability other than as a server and consumer of other's servces really present in either; they are ideal interface exposure objects, but lack the ability to host the myriad decision processes outside of their rather limited world-view.

They won't need to because the CLR languages engines will allow exposure of everything via XML. SQL Server already does this in a limited way, I supect Office's future scripting engine and objects will do the same. Microsoft won't care that it only serves other Microsoft products I suspect especially in hte Office world.

That wasn't really my point - it sounded like John was saying that these products would be re-written in a .Net language. I think what he was alluding to really was the scripting languages using CLR code, which is probably a good idea for consistency. T-SQL is one of the ugliest wanna-be languages around <g>...