> but it sounds as though you're making an argument that might as well have been applied to VFP's ability to call the Windows API - oh, just go and write yourself a small Visual C++ or VB wrapper program to interface to the Windows API, and then call that from VFP. The point

I'll second this opinion.

I guess one of the problems I've got with this whole issue is that, generally, most developers aren't entirely sure what they need "X" for until they have a need for it. It's a bit circular, that's for sure. For example, if it was asked, "hey, tell me why you want to be able to hook/listen into the Windows messaging and we might consider adding it", most developers probably couldn't give a good response. A couple people might say that it would be helpful for "X", in which case you're response might be, "well, you can already write some code in C++ to do that. Anyway, it's a good way to get your feet wet with C++.". The only problem with that is most people won't/don't want to/don't have the time to do that. Sure, I can write it. But I've got a lot of other things to get done. If it was available and easy for me to use, I probably would take advantage of it. But once the work involved passes as certain threshold, I can't justify the time or effort to do it.

I'm seeing this .NET wrapper this same way. Sure, I can write a COM wrapper everytime I want to access something in .NET. But, unless I >really< need it, I probably won't. That isn't because I'm afraid of .NET, or I don't know how to do it, it's because the time it takes to create a new project, wrap the class, test it, then deploy it doesn't make sense. If there was a nice utility to take care of most of the grunt work for me, I'd be much more likely to take advantage of it. Performance isn't always everything - unless it's a problem, development time usually wins out.