Publish DotNet component as Active-X
* I have a collegue working in Visual Studio (Enterprise edition I think)
* He is creating DotNet objects which include DotNet components, but for some of them we wish to provide an Active-X wrapper so that they can be used from within Visual Basic 6 (and Delphi-7)
* At present he is doing this manually, but it is fairly time consuming.
* I would have expected that since DotNet provides access to component properties using reflection that there would be a way of automatically publishing all the component properties in the Active-X component in Visual Studio but we have not been able to find one.
* If there is a way of doing this within Visual Studio I would be very happy to hear about it.
* Alternatively is there a tool available which would allow us to pick up a DotNet component and provide an Active-X wrapper and .tlb file to allow it to be used in a VB6 Project
* The language in use is C#
* He is creating DotNet objects which include DotNet components, but for some of them we wish to provide an Active-X wrapper so that they can be used from within Visual Basic 6 (and Delphi-7)
* At present he is doing this manually, but it is fairly time consuming.
* I would have expected that since DotNet provides access to component properties using reflection that there would be a way of automatically publishing all the component properties in the Active-X component in Visual Studio but we have not been able to find one.
* If there is a way of doing this within Visual Studio I would be very happy to hear about it.
* Alternatively is there a tool available which would allow us to pick up a DotNet component and provide an Active-X wrapper and .tlb file to allow it to be used in a VB6 Project
* The language in use is C#
ASKER
Thanks this was helpful and we can now access the component from within VB6, except that the properties and methods are not visible in the VB6 Intellisense system. This means that when we type ObjectName. or InterfaceName. we do not get the list of properties
The object we are trying to use is the DotNet rich text box and the definition in use in C# is shown below.
Do you know what we need to do to be able to use the VB6 Intellisense?
[ProgId("TPScratchy.RichTe
[Guid("8fb7f710-0881-40ea-
[ClassInterface(ClassInter
public partial class TPRichTextBox : System.Windows.Forms.RichT
{
[DesignerSerializationVisi
}
The object we are trying to use is the DotNet rich text box and the definition in use in C# is shown below.
Do you know what we need to do to be able to use the VB6 Intellisense?
[ProgId("TPScratchy.RichTe
[Guid("8fb7f710-0881-40ea-
[ClassInterface(ClassInter
public partial class TPRichTextBox : System.Windows.Forms.RichT
{
[DesignerSerializationVisi
}
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks very much for this it looks like it will resolve our issue.
Microsoft did a good work of enabling .NET application to work with Active-X (COM) components, but could not do the reverse. .NET came out some 10-15 years after COM. They could not know when they designed COM what would be in .NET, and some feature of .NET components are not available at all to COM applications. They did not expect a lot of programmers to do it, so there is not tool to automatically create a wrapper in this direction like the Interop mechanism does when you want .NET to reference COM.
The main problem comes from data types. Some of them, such as Date, have changed their format. Others, such as Long, did not exist in VB6 (The VB6 Long is the .NET Integer - Long is bigger in .NET and there is nothing similar to a .NET Long in a VB6 application).
The question is not one of a wrapper, it is one of designing the .NET component so that it is compatible with COM. The only ones I encountered where Long and Date, but there are probably others. I did only one very simple thing of that type, so I did not have time to discover all the possible problems.
As far as those are concerned, you should not use Long in your .NET component. Methods and properties that return ou accept dates should accept dates and return dates that are compatible with the COM format, that is to use the FromOADate and ToOADate methods of the Date type for conversions. There is probably a similar problem with the VB6 Currency type, because there are FromOACurrency and ToOACurrency methods also available, although I did not have to check those because there was no Currency type involved in the project that I worked with.
Another thing that gave me problems is overloading, that did not exist in COM. You need to use optional parameters instead.
An important thing to do, once the component has been designed with those types of things in mind is to set a few compilation properties. In the project's Properties window, under Assembly Information in the Application tab, make sure that you have a GUID that the Make assembly COM-Visible checkbox is checked. This will generate the necessary informations so that the .NET dll will be registered in the registry upon installation.
You also need to make sure that the dll is properly registered, which is a prerequisite for COM to be able to find a dll. .NET dlls do not need to be registered, so by default they are not. Most tools that creates installations have a property, an option or a switch somewhere that enables you to specify that the dll must be registered upon installation.