System.BadImageFormatException at Couchbase.Lite.Support.NetDesktop.Activate()

Mobile Couchbase Lite
1

We have a Couchbase Lite 2.x Windows console application and we want to run it as a Windows Service. The console version of the app runs fine but I converted it to a Windows Service and when we try to start the service we get this error:

Exception Info: System.BadImageFormatException
at Couchbase.Lite.Support.NetDesktop.Activate()
at IN2L.EclipseSyncService.DatabaseManager.GetInstance()
at IN2L.EclipseSyncService.EclipseSyncService…ctor(Boolean)
at IN2L.EclipseSyncService.Program.Main(System.String)

Note: This service worked well under Couch Base Lite 1.44. But now we have upgraded to 2.1.2 . I did check the service installer dependencies and they look like they picked up the 2.1.2 dlls.

2

You mean on the same machine it fails as a service but works as a console app?

3

So I got it working. I have NOT enabled text logging

        example: NetDesktop.EnableTextLogging("c:\\temp");

When NetDesktop.Activate() is invoked, NetDestop looks for a subfolder “CouchbaseLite\Logs” and if it’s not there and you have not called NetDesktop.EnableTextLogging then you get the error. I created a post-build command that makes sure that the folder is created and the seamed to fix my issue.

4

The method you are referring to is the default directory for binary logs. You can override this with SetBinaryLogDirectory which is in the Support namespace.

This is deprecated as of the next release in favor of a more consolidated logging facility so this will be less of an issue.

EDIT I still don’t understand why this would cause the exception in question though.

5

The exception that is thrown when the file image of a dynamic link library (DLL) or an executable program is invalid. If you get a BadImageFormatException when interfacing with a native DLL, it almost always means that you are trying to interface with a 32-bit DLL while running in the 64-bit CLR, or vice versa. In most cases you might be facing the problem with your website after deploying on server.

Make sure that you are not having 32-bit / 64-bit conflict. So, you need to adjust your application pool to Enable 32-Bit or 64-Bit accordingly. Set the Target platform setting on your c# EXE project, not your class library project. Alternatively, you can ship both 32-bit and 64-bit DLLs with different file names, define separate P/Invoke stubs for each version, and decide which one to call at runtime. The easiest way to do this would probably be to wrap your native calls in an interface (e.g., INativeMethods) and choose which implementation to instantiate at runtime based on IntPtr.Size. With this method, you could still target AnyCPU.