At the .NET intro that MSFT gave, they went showed the evolution of Duwamish. In the latest version it was just ASP.NET, ADO.NET (I think?), and SQL Server 2000. The details are getting fuzzy as time goes on. I looked like they moved the VB stuff to ASP.NET. I was less code since the tools are more powerful now and they did say that there is a learning curve.

><<
>it's only a matter of time before you have to deal with a dll hell issue of your own making(whether on a proactive or reactive basis)
><<
>
>After all these years, I am still waiting for a DLL-Hell issue of my own making. I guess I will continue the wait...< bg >
>
>
>
>
>
>>The fact that it takes extra collaboration is exactly what makes it bad.
>
>
>I said cooperation. And FWIW, there are still different teams. They should be working with, not against each other...
>
>
>>I'm not sure I agree that it is flawed. DCOM provides for a need. It is client/server to the core and encapsulates a _bunch_ of functionality. There are lots of ideas that depend on an open channel from client to server box, including database connections. I wouldn't call the whole concept fragile. Only in the last couple of years has the idea of disconnected applications come into vogue in place of connected apps.
>>
>
>Yet you agree that it is difficult to setup and get working. To me, that is flawed. And FWIW, the idea being disconnected apps is not a novel/new concept - nor are n-tier applications. The fact that DCOM does require maintaing state to some degree does make it fragile. It is extremely difficult to deal with errors and the like. This is why things like queued components are nice.
>
>
>
>>Hmm, no. Web Services require only that the published interfaces of services remain constant, and even if they don't, it provides for discovery via XSD. And the client and server are completely disconnected (HTTP is a connectionless protocol). So the problems inherent with DCOM are not remotely relevant with Web Services.
>>
>
>My point was a bit more abstract than just DCOM..< s >... It would appear that .Net represents a lot of plumbing behind the scenes. Mind you, if it can be easier, I am all for it. And, I have no reason to doubt that at some point, .Net will be there.
>
>The issue for me is that technology needs to mature. I am just one of many that is sick and tired of dumpting technology that is just coming around the maturity curve, only to have to start a new.
>
>I have no doubts that at some point, I will use .Net. However, it is going to be on my terms. And further, I am not going to play into the hype anymore.
>
>
>
>>
>As far as DLL hell on a single machine, .NET assemblies contain everything that a particular version of software needs, with no risk of one application stomping on another's feet.
>>
>
>No risk????? Sounds like the kiss of death to me. I would be careful of such definite sounding pronouncements.
>
>Remember, with new technology comes new and exciting ways to foobar it all up!!
>
>
>
>>
>.NET might come with its own brand of problems (only time will tell), but they sure won't be the same ones that DCOM/DNA has.
>>
>
>Again, such a definite sounding statement. Perhaps technically they wont be the same. But in the end, if a problem results in an app not getting delivered/running in DCOM/DNA, and with .Net, the app does not get delivered/running, does it really matter? At least with WinDNA, it is the planet of the known. With .Net, it is still theory.
>
>Here is an interesting point with respect to testing. How does one effectively beta test .Net. At least with VFP, you can take your existing apps and run them to see if they work correctly.
>
>With .Net, in order to properly beta test, you literally have to build an app. How many people do you think are doing that? For the most part, betas that are NOT VFP SUCK!! The participation and level of feedback is paltry compared to VFP.
>
>I am looking forward to a Duwamish type app for .Net, so that we can go from theory to reality. Then, all can get a real guage of what .Net has to offer. Until then, it is theory, concept, and conjecture.
>
>
>>
>Whether you have issues or not, it's going to happen, and it's happening already, on a fairly wide scale. Do you use a credit card on the internet? If you do, you are attesting your trust in SSL to handle the security issues. Maybe you won't need to because you'll be practicing law soon, but if you are a developer building business apps, it's only a matter of time before someone asks you to build a fat client app that will access a database in NYC from a branch office in LA. When that day comes, you'll more than likely be building a Web Service.
><
>
>Of course I rely on E-Commerce. However, in those cases, technology is being used that has the benefit of real experience.
>
>As far as building a fat client app that accesss data over the wire, I do that today. And no, it is not a web service. And wes, it works fine. People do this stuff today. I reject the notion that good stuff is not being done today.
>
>ADO/OLE-DB works just fine for these types of apps. The key is in how you leverage the tiers. I am not down on rendering data as XML mind you. It just so happens that clients invoking middle-tier objects that invoke stored procedures that ultimately render ADO Recordsets works very well.
>
>This of course is not to say that at some point in the future, I will take the next step. However, I am not going to throw the baby out with the bathwater. I am not going to all of a sudden, reject what I am doing now in favor of new, untested, untried technology. I am not saying that you are suggesting that either. And, to Robert's credit, he is not saying that either. His voice is a refreshing one at MS.
>
>My point is that folks should just let the hype go by. Wait until the rubber meets the road and some real work gets done with .Net. Then, evaluate that. I would wait for some case studies to learn from others' experiences.
>
>Of course, at the same time, play with it and experiment. When it comes to ones own learning, any investment is good. When it comes to allocating capital dollars for a business, one cannot and should not be as risky. In that latter case, the goal is delivery and ROI, not a debate on technology.
>
>< JVP >