Correct me if I am wrong here, but the DLL Hell issues arise from MS side of the fence. The poster-child for DLL Hell is ADO/OLE-DB. It seems as though one cannot go 3-6 months w/o a new version. I don't recall DLL-Hell Issues with my own components. Rather, the DLL-Hell issues are in getting disparate software from MS to work. i.e., getting Visual Studio, Office, ADO, etc to all place nice together.

On one hand, I see the need for MS to get these issues cleaned up. I see the DLL-Hell issue as a distinctly separate issue, one that I think is solved by different teams cooperating and working together, instead of against each other.

Tying the DLL-Hell issue into sweeping changes on the developer-tool side to me is folly. That of course is not to say that tools should not move forward. However, as I see it, there is a mismatch between the goals and the problems that are being attempted to be solved...

As far as DCOM is concerned, I never bought into it. It was difficult to setup and get working. And ultimately, it was a flawed idea. The interdependence between client/server and the reliance of an open channel of communication was/is fragile at best.

If there is/was one good thing to come out of COM +, it is the idea of queueed components. Queued components is a logical extension of MSMQ and MTS. To me, this is where Win2K shines and how Windows, more than ever, is a credible development platform. It was/is a solid move forward. At the same time, it built on what has proven to be a good technology.

If DCOM seemed like a risky scheme to me, with the interdependence and all, how am I to feel with .Net? If anything, the interdependence is greater. I have real issues with trying to make this stuff work on a public internet. For that matter, I don't think I want to try.

And, I still am trying to figure out where I would use .Net in the set of apps I build now. The type of apps I build now make use of a rich client, middle-tier components, and SQL Server. i.e., they are the types of apps that VFP excels at building. VB 6 does well with them as well. I have to ask the hard question of what .Net gives me that I don't have now. For starters, there is a learning curve that I don't have to deal with..< bg >... Seriously however, it is a cost that the client would have to suck up. I would be remiss if I could not demonstrate some benefit that would justfiy the cost. I am sure this is a point not lost on you or anybody else at MS that has an ounce of business acumen.

I take your quote to heart, that folks that have apps that are working fine, perhaps should not upgrade to .Net. Yes, I know I am para-phrasing here, but still, the gist I have right... I am one of those folks. Perhaps the day will come where I will dive into .Net for a web-based app. Chances are good however, that I am going to stick with what works first. Technology needs to mature.

Marketing-driven technology does not work. Technology driven by the collective experience of the field, in a word.....works. I still contend that .Net was cooked up in a lab, away from the realm of reality.


IMO, DLL-Hell issues are nothing more than a manifestation of the fact that the disparate MS teams have to get their collective shit together. Why on Earth should a developer have to give up what has proven to be a good platform.

The point is that if MS wants to go forward with .Net, do so. However, for those that followed and invested in MS's message from only a few years ago, MS should support those folks as well. Taking VFP out of the box is a good start for VFP'ers. At least the VFP community won't be weighed down by .Net anymore.

Strength and Honor...

< JVP >








>>I still have to scratch my head. For 2.5 years, MS was pushing WinDNA and COM Components as THE way to build scaleable applications that could be deployed on a LAN or the Web. And now, all of that is suddenly bunk.
>
>It is not "suddenly bunk". It is a reaction to a) the experiences of customers building DNA apps with COM and running into issues, including but not limited to: security, scalability, DLL Hell, remoting, etc. In addition, the Web is evolving to a world where Web sites talk to each other, in other words, the world of Web Services. In that world, XML is key.
>
>So, sure I suppose that we could have kept COM and just added the ability to work better with XML, but that wouldn't have solved the DLL Hell issues and the issues people have run into with DCOM and other things. So we made the call to move COM forward and integrate XML through and through.
>
>Don't forget that before settling on the current naming (CLR, .NET Framework), this stuff was called COM+ 2.0. It is an evolution of COM (
>a significant one, yes).
>
>Robert