Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
430 views
in Technique[技术] by (71.8m points)

.net - Options for using System.Data.SQLite in a 32bit and 64bit C# world

I understand WHY the System.Data.SQLite.dll is provided in 32 bit and 64 bit builds. So lets not dwell on that and move on. :)

Since it is done this way it seems to make pure C# development a tad more difficult with 3 choices to make.

  1. Is to support only 32-bit and force there managed assembly to compile x86 and deal with that in running in 32 or 64 bit, and there by lose advantages of when you are on a 64 bit environment.

  2. Is to force 64 bit and only support 64 bit and losing the ability to run on 32 bit but gaining all the advantages of 64 bit.

  3. Is to create two versions of their assembly one that compiles x86 and uses 32 bit SQLite and another that compiles x64 and uses 64bit SQLite. It prevents using "ANY" as a compile option and being able to easily deploy a single build to either type. Its not so horrible to manage from a development point of view as we will need two projects. Only having the C# code officially in one, and the other will just use "links" to the code in the other. This is for compiling purposes only. Still leaves us with having to manage two outputs to for deployments.

With all that said I am only looking for confirmation that the above are the only correct choices.

If however there are other choices that I am overlooking please let me know. Specifically if there is way to get a single C# DLL that can compile to ANY so it can take advantage of 32 or 64 bit depending on where its run and still use System.Data.SQLite.dll.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

This is an elaboration of the answer from Springy76. Do this:

public class AssemblyResolver
{
    public static void HandleUnresovledAssemblies()
    {
        AppDomain currentDomain = AppDomain.CurrentDomain;
        currentDomain.AssemblyResolve += currentDomain_AssemblyResolve;
    }

    private static Assembly currentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        if (args.Name == "System.Data.SQLite")
        {
            var path = Path.Combine(pathToWhereYourNativeFolderLives, "Native");

            if (IntPtr.Size == 8) // or for .NET4 use Environment.Is64BitProcess
            {
                path = Path.Combine(path, "64");
            }
            else
            {
                path = Path.Combine(path, "32");
            }

            path = Path.Combine(path, "System.Data.SQLite.DLL");

            Assembly assembly = Assembly.LoadFrom(path);
            return assembly;
        }

        return null;
    }
}

Make sure the paths generated point to the correct locations for either your 32 bit or 64 bit SQLite Dlls. Personally I've had good results with those in this NuGet package: http://www.nuget.org/packages/SQLitex64

(You only need to use the NuGet package to get hold of the compiled SQLite Dlls. Once you've got them, remove the reference to SQLite in your project created by NuGet and the NuGet package itself. Indeed, leaving the reference in place can interfere with this solution as SQLite will never be recognised as an unresolved assembly.)

Call 'HandleUnresolvedAssemblies()' as early as possible, preferably during any Bootstrapping.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...