Welcome to the Dart White Paper repository. We have created this section to publish White Papers about our technology, ideas for IT solutions implementing TCP and UDP based communications, tips for using our products, and opinions about current and coming technologies. Along with these articles, readers will have the opportunity to respond with their own ideas and we will publish those comments along with the articles. If you have a comment on any article, please submit it to comments@dart.com.

Thinking About Finally Replacing those ActiveX Controls with Shiny New .NET Components?

Top 10 11 Reasons to Upgrade Your ActiveX to .NET
Because lists to 11 are just better than lists to 10.

Published January 2011

1. The PowerTCP and PowerSNMP .NET product line has a newer design, incorporating lessons learned from maintaining the venerable ActiveX product line. Also, ActiveX has some inherent interface deficiencies, such as no method overloading. Therefore, the .NET components have a more streamlined, intuitive, easier-to-use interface than their ActiveX counterparts.

2. The ActiveX product line is a legacy line. The .NET product line is current technology, and is therefore maintained and enhanced with new features with more frequency than the ActiveX line.

3. The .NET products support superior documentation systems. In addition to the chm help included with ActiveX, .NET products include versions for Visual Studio-integrated MS Help 2.0 and MS Help Viewer.

4. Although you can develop 32-bit applications that will run on 64-bit operating systems (using WOW64), you cannot develop 64-bit applications that use ActiveX controls.

5. Using ActiveX in .NET applications requires construction of a runtime callable wrapper (RCW) class. This added layer means an inherent performance hit compared to the managed .NET components.

6. Programming against the RCW can result in a modified interface, as ActiveX member names may be changed due to .NET naming restrictions. Also, this means it is a bit more difficult to find the correct documentation for these members.

7. The Microsoft COM licensing model utilized by ActiveX is not fully implemented in .NET. Using controls dynamically in code requires extra steps to integrate the licensing resource into the application. Licensed objects that are not controls requires a work-around. Using controls in .NET Web Applications, Web Sites and Services, and Windows Services also requires a deployment work-around.

8. Using ActiveX controls that require event notifications (especially server and PowerSNMP controls) do not function correctly in .NET Windows services, as there is no message pump to process event messages.

9. ActiveX deployment requires COM registration, whereas .NET component dlls can be X-copied when desired. Also, most ActiveX controls require deployment of multiple dlls.

10. Unlike .NET components, only one version of an ActiveX control can be used on any machine. All applications on the machine that utilize the control must use the same version, which could result in compatibility problems when older versions are replaced. This is commonly referred to as "dll hell."

11. The ActiveX line was designed for the single threaded apartment model and does not use many of the capabilities of .NET. The .NET product line utilize objects and conventions that other .NET classes use, such as streaming interfaces and native security certificate classes.

For more discussion, see .NET and the New Component Paradigm: Moving from ActiveX to the .NET Framework.