4

I've got two assemblies that both contain the same namespace and classes. One is 32 bit and named assembly_x86.dll, and the other is 64 bit and named assembly_x64.dll.

I would like to be able to build the containing application as AnyCPU and have it run without error on both 32 and 64 bit OSes. So I need it to dynamically choose the correct reference at run time depending on the bitness of the containing process. I've been hammering away at this for a while and haven't been able to come up with anything. I feel like I'm probably missing something simple.

My latest attempt was the add references to both assemblies, wire up the AssemblyResolve event and try to replace the 64 bit reference with the 32 bit should it fail to load the 64 bit version like so...

    static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        Assembly assembly = null;

        if (args.Name.Contains("assembly_x64"))
        {
                assembly = typeof(x86_alias::TypeName).Assembly;
        }

        return assembly;
    }

Which results in the following exception:

The located assembly's manifest definition does not match the assembly reference.

Any helpful tips would be very much appreciated. Thanks in advance.

In regard to some comments below I think perhaps I did a poor job describing my goal. Let me elaborate. So say for example there is just a single method in these assemblies I'd like to call - MyClass.MyMethod.

If I build the app with only the reference to the 32 bit assembly and install it on a 32 bit machine it works fine. Likewise, if I build it with a reference to the 64 bit assembly and install it on a 64 bit machine all is good. However, my goal is to not have to have two separate builds of the application. If I deploy to a 32 bit machine I'd like it to call MyClass.MyMethod in the 32 bit assembly, and if I deploy to a 64 bit machine I would like it to call MyClass.MyMethod in the 64 bit assembly.

If the assemblies both had the same name (and version, culture, publickeytoken) I believe it may just work and pick up the proper version. However, since the assembly names are different it does not. So this is how I've come to the conclusion that I need to swap out the reference at run time.

starblue
  • 55,348
  • 14
  • 97
  • 151
Chris
  • 81
  • 1
  • 8

1 Answers1

0

You could do the check of the OS as part of the installation, then deploy only the required DLL based on the OS. The ClickOnce bootstrapper for SQL Server CE does a similar thing.

CodeMan
  • 1,375
  • 1
  • 7
  • 7
  • Unless I'm misunderstanding your suggestion I don't think this would help. Deploying the proper dll is not the issue. The error described above is a result of running the app on a 32 bit OS, and the 32 bit version of the assembly is present. – Chris May 27 '11 at 05:56
  • @chris this means that the problem is not what you describe. Why worry about 64 bit when you can't even get a pure 32 bit solution to work? – David Heffernan May 27 '11 at 06:26
  • My understanding is that the app is compiled for AnyCPU but has a dependency on a DLL that has a specific 32bit and 64bit version. If you only deploy the 32bit DLL and are running on a 32bit OS, then there wouldn't be a problem and likewise for the 64bit OS. There would be no need to try to replace anything at runtime. – CodeMan May 27 '11 at 06:31
  • Sorry, it would not allow me to type my comment in full. So I've elaborated a bit more as to my goal in the original post. Please have a look if you don't mind, and thanks again for your time. – Chris May 27 '11 at 12:11
  • Deployment time switching is very annoying IMO(unless it's a program that integrates deeply with the OS). – CodesInChaos May 29 '11 at 11:39
  • Annoying implying it's something you've successfully accomplished before? If so, would you mind sharing how? – Chris Jun 10 '11 at 23:35