We\'ve got a DLL (a COM server) that will compile fine in 32-bit and 64-bit, but the DLL uses the same CLSID and AppID for the 32-bit version and the 64-bit version. Is this
Both versions can (and indeed should) use the same GUIDs for everything.
On a 32-bit machine you can't register or use the 64-bit DLL, so there's no problem there. The 64-bit DLL simply doesn't enter the picture.
On a 64-bit machine the 64-bit DLL gets registered in HKLM/Software/Classes/CLSID (etc.) and the 32-bit DLL gets registered in HKLM/Software/Wow6432Node/Classes/CLSID. (I wonder where you got the advice that you can't register the 32-bit DLL on a 64-bit machine...) A 32-bit client running on the 64-bit machine will look in the normal place in the registry, but the OS will silently redirect it to the Wow6432Node key instead.
This is dealt with inside Windows with a feature called 'Registry redirection' On the 64-bit version of Windows, a 32-bit program gets a different view of the registry. Any access to the HKCR alias or the HKLM\Software root is redirected for the kind of keys that a COM server uses. A 32-bit program actually sees the key values stored in HKLM\Software\Wow6432Node. You can see it with Regedit.exe
This is normally taken care of by an installer, a VS Setup project has the TargetPlatform property for example. If you want to make the COM server available in both 32-bit and 64-bit mode then you should use two installers. Or a 64-bit installer that writes both sets of keys. Having a COM server that can handle both is very unusual in the olden days. But not unheard of when you implemented in .NET for example.