We are using a VB.NET print module that runs with our current NET EXPRESS dialogs. We are trying to use this print module in our Visual COBOL migration. One of our developers believes if it is compiled as a 32 bit module it can be integrated into our new Visual COBOL projects. We are trying the PREFER 32 option from Visual Studio to recompile this VB.NET module. Are there any other factors with which we should be concerned since it was originally part of NET EXPRESS? Thanks for any insights.

Our final environment will be Visual COBOL 2.2 under Visual Studio Professional 2013 under Windows 2012 within a HYPER-V deployment. At first it appeared that Hyper-V was interfering but now we are having problems with the print module itself.

  • How were you calling this under Net Express? If you compiled this an a managed .NET .dll exposed as COM Interop then you would still call this the same way in a native Visual COBOL program in the same manner as you did in Net Express. If it is a 32-bit module then your Visual COBOL native project should have a target of x86.

    If you are using a managed code project in Visual COBOL then you can simply add a reference to the VB.NET project and then instantiate it and invoke its methods directly.

    Can you elaborate a bit on exactly how the interface works under Net Express and what type of project template you are using under Visual COBOL?