Two things are important to keep in mind when working with unmanaged components. First, remember that an interop assembly is not a replacement for the COM server; it is a stand-in, or proxy for it. The interop assemblies produced by tlbimp and RAD Studio are not transformations of the component's unmanaged code into managed code. Every file required by the component in an unmanaged deployment environment, must also be deployed in a managed environment in addition to the interop assemblies. Second, the .NET Framework's interop services do not circumvent the requirement of registering the COM server on the end-user's machine. Note the registration requirement also applies during the development of your managed application. 

As with any other .NET assembly, an interop assembly can be deployed alongside the managed executable in the installation folder, or it can be deployed in the GAC. If you deploy the interop assembly into the GAC, you must give it a strong name during development. Primary interop assemblies are always deployed into the GAC; however, just because an assembly is deployed to the GAC, does not automatically make it a primary interop assembly. An interop assembly is designated as a primary interop assembly by using the /primary command-line option of the tlbimp utility. The IDE currently has no built-in support for creating primary interop assemblies. Unmanaged COM servers can be deployed anywhere on the end-user's machine, however, as noted previously, you must still register unmanaged components when your application is installed.