VB Active X DLL fail on 64 bit while we use through VB script

OK, using 32 bit DLL's on a 64 bit OS is going to cause you issues because they are a different bitness.

So you cannot simply call a 32 bit COM component from a 64 bit application. You have 2 options, get 64 bit DLL's to use for your 64 bit application or compile x86 applications on the 64 bit machine.

The 2nd is probably the more likely if you are using 3rd party DLL's etc. and this should be easily achieved by using the

My Project -> Compile tab -> Advanced Settings -> Target CPU and setting it the x86

This then causes the compiler to generate an x86 binaries which are the same bitness as the referenced DLL's.

It works through VB Script, VBA, VB6 and even .net framework 1.1 applications as all they know about is 32 bitness. However installing 2.0 an upwards of .NET framework on a 64 bit machines results in 32 and 64 bit frameworks being installed.

The WOW allows you to run 32 bit apps on a 64 bit box. However as a DLL Is in-process this requires that the application and the class libraries(DLL's) be of the same bitness as they will be brought into the same memory space. If you compile you application for x86 , it will run perfectly happy on a 2003 using WOW because the ActiveX is 32 bit and the Application is 32 bit and they are both in the same process space.

On a 64-bit version of Microsoft Windows, it is possible to run 32-bit applications using the WOW64 emulator. However, processes can only be 32-bit or 64-bit. You cannot have a process that runs both.

A DLL will run in the process space of your application. As both have to be the same bitness and you ActiveX is 32 bit, this means your app also has to be 32 bit.

There is a definately a 64 bit command line compiler for VB in 2005, it is installed as part of the 64 bit framework. That said, the 32 bit compiler can generate x64 code. There is no however no 64 bit version of Visual Studio, so edit and continue doesnt work on 64 bit machine when compiling Neutral or x64. However if you target x86 then edit and continue works just fine. There are 2 compilers on a machine, 3 for 64 bit. MSVB7.dll is used by visual studio (this is 32 bit only), and VBC.exe which reside in the framework folders - there will be 2 (1 32 bit and 1 64 bit) for a 64 bit OS with 64 bit framework installed. These are command line driven compilers. Bother have a targetplatform switch which allows you to compile apps for a different processor (so 32 bit can produce x86/x64/ia64/IL Neutral code and the 64 bit product can product x86/x64/ia64/IL Neutral code)

The reason for you problem is Activex is based on COM technology and these are native code compiled for a specific processor. The default for .NET is .IL Neutral which is JIT Compiled at runtime for the processor architecture of the machine running the app. Except when COM Interop is involved in which case you have a dependency upon the COM components.

No Idea on vb6 activex DLLS in sql 2005 integration services.