compiling a .net application with either a 32-bit or 64-bit dll

Question

I have an application that we wrote here at work that uses the SharpSVN wrapper for SVN. It has served us well of the past few years. However, we have started bringing in 64-bit systems and our application cannot seem to access the SharpSVN dll on these systems.

I have downloaded the 64-bit version of the SharpSVN dll and I am wondering what to do next. I cannot stop my 32-bit users from using the application, so I need to be able to compile for both platforms. Luckily, with this application, we split different layers of the ntier stack into separate projects within the solution so my business layer that utilizes the SharpSVN dll is on its own.

How would I go about compiling both a 32-bit and 64-bit version of my application without having to maintain two copies of the project?

Answer 1

From the description, it sounds like your vb.net application is built with the Any CPU option, which means it would run as a 64-bit application on a 64-bit machine. In that case, it would not load the 32-bit DLL.

Rather than try to use both a 32-bit and 64-bit version, you should be able to just change it to run as 32-bit. Simpler deployment. Under the project properties build tab, choose x86.

Answer 2

Build your tool using the x86 platform (as opposed to Any CPU), and it will be loaded as x86 code even on 64-bit systems.

Or you can do something like

class SharpSvn64 {
    [DllImport("sharpsvn64.dll")] extern public static void DoSomething();
}

class SharpSvn32 {
    [DllImport("sharpsvn32.dll")] extern public static void DoSomething();
}

class SharpSvn {
    static readonly bool Is64 = (IntPtr.Size == 8);

    void DoSomething() {
        if (Is64)
            SharpSvn64.DoSomething();
        else
            SharpSvn32.DoSomething();
    }
}

Edit: Since SharpSVN is managed, PInvoke wouldn't be the answer, so building x86 executables are probably the way. Or, if the interface is identical, you MAY get away with subscribing to the AddDomain.AssemblyResolve event and choose which assembly you want in that. I don't know if this is a good idea, though.