I want to know if anyone has ever successfully hosted a .NET WinForm control in a Visual Basic 5.0/6.0 Form?

I have seen code posted that does register the control as an ActiveX control via adding a few extra registry keys, and as a result these controls are available in the Visual Studio ActiveX Control Test Container.  However, these controls are not referencable by Visual Basic.

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

If I remember correctly, you've got to setup the registry information so that the control is marked with a component category of an activex control, the assembly needs to be somewhere the CLR can load it from, and there must be a registered type library.  Also, the default type library version stamp is 0.0 if you don't have an AssemblyVersion attribute, and VB skips all type libraries with a major version of 0 for some reason.

When we decided not to support VB6 and below, it was a pretty tough decision.  The reason we cut support was that we just couldn't get it to work seamlessly.  The CLR has a very rich and extensible type system, and lots of those types don't map very well to the COM world.  Without a good seamless mapping you can plop the control on a VB form with no problem...but you can't program against it in the VB code.  The best model we could hope for was to force a control author to write the .NET API, and then to expose a different COM compliant API for VB6 and below.  We thought that most people wouldn't want to sign up for that (isn't .NET supposed to be easy?).  I think you'll run into the same issues we did:  You'll get the control to show up on the form designer with few problems, but you won't really be able to write much VB code against it.

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.