title: Registering x64 Assemblies for COM Interop
body: <p>Scenario: I have a project containgin two C# projects, which for historical reasons must communicate with each other using COM (via COM Interop). The COM Server is an in-process automation object (call this the "Server") and the COM Client is a simple C# Console application that loads the server like this:  </p>
  
  <pre><code>        var objTypee = Type.GetTypeFromProgID("ProgID.Interop3264");
          var objLateBound = Activator.CreateInstance(objType);
  </code></pre>
  
  <p>Visual studio automatically registers assemblies for COM Interop if that option is enabled in the project settings, so that's what I use to register the Server (I'm only interested in the developer experience here, installation is a seperate issue) and everything works fine as long as the projects are set to generate 32-bit code or the COM Client is 32-bit.</p>
  
  <p>The problem comes when developing on a 64-bit system and both projects are set to generate code for 'Any CPU' which results in them running in 64-bit mode. This yields the following error:  </p>
  
  <pre><code>"Retrieving the COM class factory for component with CLSID {6F597EDF-9CC8-4D81-B42E-1EA9B983AB02} failed due to the following error: 80040154."
  </code></pre>
  
  <p>After some investigation, it seems that the MSBuild scripts only perform 32-bit registration.  It does put the ProgID into the 64-bit registry section, along with its subkey CLSID, and the proper classID. But the CLSID{clsid} stuff is not there. It's only in the WOW6432 subtree, for 32-bit. So the activator cannot retrieve the class factory because it can't find the thing.</p>
  
  <p>I'll be really impressed with the SO community if I get an answer to this one, but here goes:</p>
  
  <p>Has anyone else run accross this problem? How did you solve it? What's the easiest way to ensure that COM Interop assemblies get correctly registered on 64-bit development machines?</p>