LVOOP factory pattern issue with sub VI execution in child class

[lvABC]

LabVIEW 2012
I have product with multiple communication protocols, among some protocol uses different hardware.
So I created LVOOP using factory pattern, the application had been working great without any issue regarding to loading class and executing selected protocol and hardware.

The application loads dynamically selected .lvclass using “Get LV Calss Default Value.vi” with options 0x10.

Running from LabVIEW 2012 or built application had been working without any issue.
After I installed LabVIEW 2014, I’m having some issue that I can’t explain well enough and doesn’t quite understand the problem. LabVIEW 2014 should not have anything do it my issue.
Same project with all dependencies are included in project and build specifications when running from LabVIEW 2012 works, but the built application doesn’t execute the sub VI in that child class.
The built application loads child class properly without any error, I check if selected class is on the wire by checking type, but hangs on the sub VI that is being called.
When I change my class loading to standard method, it all works fine.

My issue is I can’t load using standard method way because some system may not have all hardware and it may look for system dependencies (i.e. NI-DAQ driver’s .dll, ect) and will break the application.
Any inside why dynamically loading cause issue or tip to resolving will be greatly appreciated.

-lvABC

[PiDi]

Have you tried mass compiling the code?

[lvABC]

Yes, I have mass compiled all VIs.
I did further digging by put pop up dialog box in child VI.
I get pop up in child VI, I get pop up in sub VI that is called in child VI. It gets hung in any VI that uses TCP/IP, UDP/IP, or DLL calls. For example in Analog class it gets hung up on DAQmx Create Task.vi.
For some reason it won’t create task.

[Vijay_J]

If it is only with NIDaqmx API's, I would recommend reinstalling the NI Device Drivers.

If it is happening with all the other plugin drivers with the dll dependencies, issue is something else.

Regards,

Vijay.

[lvABC]

Vijay, it happens with other classes as well.
Analog DAQmx was just an example I posted, since it commonly used.
Thanks

[Vijay_J]

In that case, it looks like a dependency issue.

Is that your plugins are part of your main application build or applications and plugins are build separately?

Carefully look at the build options in LabVIEW 2014.