COM objects are a pain with registering them. Taking down a web server to unregister and register a new object is ridiculous. Doing it on NT Workstation\LAN with PWS takes long enough never mind a production server. I believe this is one area that Microsoft much vasty improve VB COM objects.

As for COM\DLL's [classes in VFP] objects (or whatever is the newest verbage), whether in VFP, ASP, or VB, they are a must. For ASP, whether the DLL is created in VB or VFP makes no difference as long as the object is well written and documented.

As for ASP code being more unwieldy then VFP, I seen some pretty sophisticated code in VFP that was written and organized as slop. I can't blame VFP for that, it was the developer's fault. The same goes for ASP ... using SUBs, COMs, and #INCLUDES can go a long way in making the code well organized (but not necessarily well written [the two {organized & written} are not the same]).

>>I don't understand "ASP becomes unwieldy when an application moves from simple to more complex" as I have read here on the UT a number of times. Poor ASP coding techniques becomes no more "unwieldy" then a poorly written FoxPro application. Good coding techniques and well written documentation should be the norm for any language. Then the platform doesn't get "unwieldy". That being said ...
>
>Oh man, you have to be kidding right?
>
>Yes, good coding will help, but not much. I don't care how much you organize
>your code you'll end up with code in places where it doesn't belong with
>ASP. Keeping things organized and efficient is a bitch... and that's
>if you're actually trying.
>
>I look at a lot of code that is produced and ASP code is some of the worst
>I've seen in any kind of development. And this even by otherwise good
>developers that are aware of coding standards and organizing skills for
>code.
>
>Moving to complex Web applications with ASP is a huge step from a simple
>two page app. Much more so than any other development environment.
>I don't think ASP was ever meant to be the end all solution for code -
>I'm certain the idea was that ASP was to be a vehicle as a COM client
>to keep business logic where it belongs - in objects.
>
>Moving to COM is a bear too - registering components, moving them around
>managing the Web server to update code - synching sites. It far from
>straight forward.
>
>Then there's the whole gig of how the COM threading models work in
>ASP - which is utterly mis/underdocumented and ends up killing performance
>of many COM based applications. ASP apps work well when properly
>configured - but watch out for those that aren't.
>
>Believe me, I think ASP is a decent platform for Web development, but
>it sure ain't easy when it comes to building anything but trivial apps,
>especially those that require COM.
>
>+++ Rick ---