Hosting WinForm Controls in VB6

I'd like to figure this out too. The closest I've come is to get VB6 to recognize it as an ActiveX control; the missing piece was adding the registry keys for the .NET control's type library (create a normal ActiveX control in C++ and see what it registers). Unfortunately when I try to reference the component VB barfs with a "mscoree.dll could not be loaded" messagebox. Oddly, I can call Form.Controls.Add("mylib.mycontrol","mycontrol1") and add the control at runtime with no problem. That approach has limitations, unfortunately, as it is late bound and doesn't allow much design time support. Also, it seems to hide the true interface for my control, ie accessing a property I know should be there returns the "object doesn't support this property" error. I can also reference my library (as opposed to referencing the Component) and create an early-bound instance of my control. Unfortunately, VB doesn't give me a way to add it to the form's controls list (or maybe I'm missing something, as I'm a C++ programmer mostly).

Also, I assume Microsoft had some reason for not supporting this feature; my guess is they had performance or stability problems and didn't have time to get it fixed for the final release. So, even if we figure out how to do this ourselves, there may be a more fundamental problem.

Hope that helps,
Robert W. Grubbs

I'll have to toy with this again and see if I can get VB6 to recognize it. I was unaware of the version issue at the time I was attempting this. As long as the assembly is loaded into the GAC it should be accessable, correct? I believe that I had everything else set up correctly, but if you have specific information concerning registry keys it would be greatly appreciated.

While I respect Microsoft's decision to not support .NET controls in VB6 Forms I do think that it was a poor decision from a marketting point of view. I think most of us can agree that VB6 is not going away anytime soon and it will remain an incredibly popular language simply because of it's own inertia and due to the lack of a no-touch migration path to .NET (which, believe me, I prefer, but others don't quite vehemently.) As such we're going to live in a mixed market world for quite a while so interopability is vastly important. It was certainly important enough for there to be a large emphasis on COM interopability within the .NET framework and you and I both know that the same concessions must be made when developing a .NET component that needs to usable as a COM component.

I'd personally rather have limited support with a whitepaper on how to avoid possible pitfalls than to have no support at all.