How to migrate VB.NET WinForms app using legacy COM/ActiveX controls to 64-bit (.NET Framework 4.8.1)?

Question

Hello Community,

I have a VB.NET application targeting .NET Framework 4.8.1, currently compiled as 32-bit (x86) because it uses several legacy COM/ActiveX controls and references. I want to migrate this application to 64-bit (AnyCPU or x64) for future compatibility and performance.

Here are the COM interop DLLs currently referenced in my project:

• AxInterop.ComctlLib
• AxInterop.MScomctlLib
• AxInterop.MSComCtl2
• AxInterop.Microsoft.Vbe.Interop.Forms
• AxInterop.TabDlg
• AxInterop.MSForms
• Interop.ADOX
• Interop.ComctlLib
• Interop.MSComCtl2
• Interop.TabDlg

Additionally, the application depends on these OCX files (attached screenshot):

• tabctl32.ocx
• ss32x25.ocx
• mscomctl.ocx
• comdlg32.ocx
• comctl32.ocx
• Mscomct2.ocx

---

My Questions:

1. Is there any official or recommended strategy from Microsoft to migrate away from these COM/ActiveX controls to managed equivalents so the app can run in 64-bit?
2. Are there NuGet packages or modern .NET libraries that can replace these controls ?
3. What is the recommended step-by-step migration approach?
   • Should I remove and replace one COM control at a time?
     • Which controls are easiest to replace first?

Any guidance, best practices, or official Microsoft recommendations would be greatly appreciated.

Thank you!
Aman Agrahari

Answer 1

Migrating a VB.NET WinForms application that relies on legacy COM/ActiveX controls to a 64-bit environment involves several considerations and steps. Here’s a structured approach based on the context provided:

1. Official Strategy for Migration: Microsoft does not provide a one-size-fits-all strategy for migrating legacy COM/ActiveX controls to managed equivalents. However, it's generally recommended to replace COM components with .NET managed libraries when possible. This transition helps ensure compatibility with 64-bit applications.
2. NuGet Packages and Modern Libraries: While specific NuGet packages for each of the legacy controls you mentioned may not exist, many modern .NET libraries can serve as alternatives. For example, you can look into libraries for UI controls that are designed for .NET, such as Telerik UI for WinForms or DevExpress components, which provide managed equivalents for common UI controls.
3. Step-by-Step Migration Approach:
   • Assess Dependencies: Start by identifying which COM controls are critical to your application’s functionality.
   • Replace One Control at a Time: It is advisable to replace one control at a time to minimize disruption. Begin with controls that are less complex and have clear managed alternatives. For instance, UI controls like mscomctl.ocx can often be replaced with .NET controls that provide similar functionality.
   • Testing: After replacing a control, thoroughly test the application to ensure that the new control behaves as expected and does not introduce new issues.
   • Gradual Transition: Continue this process until all legacy controls have been replaced. This gradual approach helps manage risk and allows for easier troubleshooting.
4. Considerations for 64-bit Migration: When migrating to 64-bit, ensure that all dependencies, including any third-party libraries or components, are also available in 64-bit versions. If some components are only available in 32-bit, you may need to maintain a 32-bit version of your application or find suitable replacements.

By following these guidelines, you can effectively migrate your application while minimizing issues related to legacy COM/ActiveX controls.

---

References:

• Troubleshoot 32-bit problems
• Troubleshoot COM references

Answer 2

Thank you for reaching out!

There is no supported way to run 32-bit COM/ActiveX (OCX) controls in a 64-bit WinForms application. To migrate to x64 or Any CPU, all legacy ActiveX/COM controls must be removed or replaced with managed equivalents.

Microsoft's recommended approach is to keep the application x86, then incrementally replace ActiveX controls with WinForms managed controls (for example: Tree View, List View, Tab Controls, DataGrid View, and standard dialogs). There is no automatic or tool-based migration.

There are no Microsoft NuGet packages that directly replace these OCX controls. Replacement must be done manually, control by control. Third party WinForms UI Libraries cab be used if advance features are required.

 

To recommended migration steps are:

1. Keep the app x86 and stable on .NET Framework 4.8.1
2. Replace simpler UI controls first (dialogs, tabs, lists, trees)
3. Remove each COM reference after replacement
4. Replace ADO/ADOX with ADO.NET if applicable
5. Switch to x64/Any CPU only after all OCXs are eliminated

 

This is the supported and reliable path for 64-bit compatibility.

 

Let me know if you need any further help with this. I will be happy to assist. If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.