We have a pretty big issue with registering 32-bit and 64-bit primary interop assemblies and maintaining IntelliSense support. We ship both 32-bit and 64-bit COM in-proc servers and register the corresponding 32-bit and 64-bit PIAs. We use the PrimaryInteropAssemblyCodeBase value in the TypeLib entry to point to the location of our PIAs on disk. This PrimaryInteropAssemblyCodeBase value is required to get Visual Studio to locate the XML IntelliSense file for rendering IntelliSense for that PIA -- you point the code base at the DLL and put the XML file next to it and Visual Studio renders the content.
The problem is that with Windows 7, the TypeLib section of the registry is shared, so you can only point PrimaryInteropAssemblyCodeBase at either the 32-bit or 64-bit PIA (not both). If you point it at the 32-bit PIA, then building 64-bit apps using that PIA fails in Visual Studio (and vice-versa if you use the 64-bit PIA location). If you don't use the PrimaryInteropAssemblyCodeBase value at all, then Visual Studio will resolve to the correct PIA via the GAC and builds work -- but IntelliSense is *not* rendered because the XML IntelliSense file obviously is not (typically) installed in the GAC.
Building the PIAs as "Any CPU" does work, but it feels "wrong" since PIAs *really* are, by definition, bitness-dependent. This seems fundamentally broken and I'm wondering how others have not come across this.
Any help or insights are much appreciated.
Kirk Fertitta