views:

75

answers:

2

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?

+1  A: 

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.

erikkallen
Because the SharpSVN is written in .Net, I have a reference to the dll. Isn't the PInvoke method for unmanaged code?
fizch
as shown below, changing the project to the x86 platform caused the application to hang during load.
fizch
Where below????
erikkallen
sorry, i guess it depends on your sort. in response to the other answer from Mark Wilkins.
fizch
A: 

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.

Mark Wilkins
would i then have to maintain two copies of the project? One that uses the 32 and the other for the 64?
fizch
@fizch, No. Assuming there is no specific reason for needing a 64-bit application, you would just have a single 32-bit build that could be run in either environment.
Mark Wilkins
@Mark, changing my business layer project did not work. When I changed all of the projects in the solution to x86 it would not start the application at all. It kept saying that the app stopped responding.
fizch
@fizch, That seems a bit odd. Did it stop working on the 32-bit platform as well?
Mark Wilkins
I did not try installing on a 32-bit platform at that point. Good question. I just tried compiling it and running it on my system, which is 32-bit, and it ran successfully.
fizch
@fizch, Are there multiple assemblies involved and possibly one assembly is not built with the x86 option? I'm grasping at straws here. .... Or another possibility might be that the 64-bit version of SharpSVN is actually required on a 64-bit OS (I have no knowledge of that). If that is true, then my suggestion of using x86 build options is completely worthless.
Mark Wilkins
I did end up having to create a separate project for the 64-bit solution. I was pressed for time and not making much progress otherwise. The 64-bit version of the SharpSVN dll did need to be used on the 64-bit version of Win 7. I set all of the projects to compile for x64 and the target platform of the setup project as well.
fizch