Running Vanatec version 4.3.19.797 (OpenAccess 2.0) on x64 but forcing it to run as x86

[Mustafa]

Hi,

We have an application built using an old version of Vanatec 4.3.19.797 (OpenAccess 2.0) that uses .Net 2.0.  The application is a console (DOS) one that references other projects (DLLs) which are compiled to x86.  This application was done in VS2008.  If we run this application on XP or any 32 bit systems then it works fine.  When we tried to run it on x64, we always get the BadImageFormatException error.  We tried setting the executable and the DLL it is complaining about (which is the one referencing the Vanatec DLLs) to 32 bit using corflags myassembly/DLL /32BIT+ but still no luck.

Any ideas?

Thanks,

Mustafa

[Thomas]

Hello Mustafa,

please have a look at the assemblies (enhanced and not enhanced) that form the application.
At least the .exe (entry assembly) must have specified that the intended runtime is a 32 bit runtime, otherwise a 64 bit runtime could just use it.

Please use corflags on each assembly that is in the application: You should not change anything as long as the assembly is marked as ILONLY. That code is executable in 32 and 64 bit mode.
When an assembly is encountered that states 32BITREQ: 1, this assembly will prevent the application from running in 64 bit runtime. In case there is no strong signature required (or you can resign the application), you might be able to switch to ILONLY code with the corflags tool.
The right way, of course, would be to rebuild the application and have the compiler use the platform target AnyCPU. Then ILONLY assemblies are generated and you are fine to go on 32 and 64 bit.

The BadImageFormatException could be caused by broken strong name signatures. Changing a single bit , even in the header, will make the assembly look 'corrupt'.


Regards,
Thomas
Telerik

 

[Mustafa]

Hi Thomas,

Thanks for your reply.  I tried using corflags on the exe and the vanatec DLL it is referring to but still no luck.  Not sure which other vanatec DLLs I need to use corflags on.  Our application is built using x86 (32bit) so all of it is running as x86 except for the vanatec stuff.  

The reason for running is in 32 bit is because we have to use 32 bit oracle client as our other applications are 32 bit so we are restricted by that.

Would you be able to tell me which other DLLs I would need to use corflags on in order to get it working? 

Thanks,

Mustafa

[Thomas]

Hi Mustafa,

now I understand... I assume that the original, unchanged assemblies would work on 64 bit when a 32 bit CLR is used (done automatically). However, we are indirectly referencing native code from Oracle, and this code needs to be present on the machine. Please make sure to have the 32 bit Oracle client installed for .NET2 and available in the path. The joy of unmanaged code!

You can create a simple x32 console application that tries to load the installed driver:

static void Main(string[] args)
{
    string name = args.Length > 0 ? args[1] : "System.Data.SqlClient";
    var factory = System.Data.Common.DbProviderFactories.GetFactory(name);

    if (args.Length > 1)
    {
        using (var con = factory.CreateConnection())
        {
            con.ConnectionString = args[1];
            con.Open();
            Console.WriteLine(con.ServerVersion);
        }
    }
    else
    {
        Console.WriteLine("Connection String Elements:");
        var t = factory.CreateConnectionStringBuilder();
        foreach (var s in t.Keys)
            Console.WriteLine(s);
    }
}

You can then call the application with "Oracle.DataAccess.Client" to see if the driver is loadable at runtime and the native code can be resolved. In the next step you can additionally pass a valid connection string as the second parameter to see if the connection can be made.

When this 32 bit code is working on the 64 bit machine, then OpenAccess should have no problem with the installed driver, and messing with the corflags is not needed.

Regards,
Thomas
Telerik

 

[Mustafa]

Hi Thomas,

I have Oracle client 32 bit installed on the machine and other applications use it fine.  The issue is not the oracle client but I think it is the fact that our assemblies platform target is set to 32 bit whereas the vanatec is set to AnyCPU.  So on a 64 bit machine, our assemblies will run in 32 bit but when they try to call the vanatec code, because is set to AnyCPU, is it running in 64 bit and therefore our code can't talk to it.  Hence, my question about a way of getting the vanatec DLLs to run in 32 bit mode without having to re-compile or change code etc. 

Thanks,

Mustafa

[Thomas]

Hello Mustafa,

to my knowledge, assemblies that were compiled for AnyCPU can be executed with 32 or 64 bit. Which runtime is choosen depends on the entry assembly (the main function). That assembly controls which runtime is used. You should be able to test that hypothesis when compiling the test application from the last email with AnyCPU and 32 bit and see which runtime is used in those cases:

public static bool Is64Bit
        {
            get
            {
                try
                {
                    return System.Runtime.InteropServices.Marshal.SizeOf(typeof(IntPtr)) == 8;
                }
                catch
                {
                    return false;
                }
            }
        }

Also, would it be possible to figure out which assembly really failed to load? 
Please notice also, that there are two console apps installed in the tools start menu for VS: One reads like
'...x86 Native Tools Command' and one like '... x64 Native Tools Command'. Please double check that the right one is used.
Switching the 32 bit flag via corflags in the OpenAccess assemblies would also require the re-signing of the assemblies AFAIK.

Regards,
Thomas
Telerik

 

[Mustafa]

Hi Thomas,

I tried your original post and the code executed the else part and displayed the data source property names but not values.  I tried it with "Oracle.DataAccess.Client" and "System.Data.OracleClient".  Both just gave me the property names.

I also tried your second post of Is64Bit and it returned True.

On my machine, I have both the 32 and 64 bit oracle clients installed as well as the Oracle database server components which are 64 bit.  Not sure if that will complicate things.

Not sure what these results tell me.  Would you be able to shed some light on it?

Thanks,

Mustafa

[Thomas]

Hello Mustafa,

when Is64Bit returns True that means, the executing CLR runs in 64 bit mode. You need to compile the simple console application for x86: Select the Project -> Right mouse context menu -> Properties -> Build -> Platform target -> x86). Rebuild and let it run then. 
I guess you installed the 64 bit Oracle driver for that machine rather than installing the 32 bit version. That's why you haven't gotten yet an exception from the loading of the Oracle.DataAccess.Client driver.

As a second argument you can pass in a connection string for the database that you want to reach to test whether the connection can successfully be established.

Regards,
Thomas
Telerik

 

[Mustafa]

Hi Thomas,

I compiled it to x86 and Is64Bit returned False.  Our build process ensures that all assemblies are compiled to x86 and some machines where this application is deployed to have either Oracle client 32 bit or 32 bit and 64 bit installed.  

As a separate test, we installed the application on a Windows 7 32 bit version and we still get the same error.

To be honest, this is getting to the point where we may have to re-write the application to not use vanatec at all as it is the only application that does here and we just don't have time to keep investigating it.

Thanks,

Mustafa

[Mustafa]

Just to add that the error refers to the vanatec DLL or one of its dependencies....so may be it is one of the other associated DLLs.

[Thomas]

Hi Mustafa,

I'm not aware that Vanatec used a x86 compiled version, all must be AnyCPU. By playing with the corflags, maybe an assembly was modified and is used now altered? But this is just guessing. We never experienced such an issue before.

Regards,
Thomas
Telerik