You have two problems, or actually, one problem and one half problem (since its a warning from the regasm utility).
The first, "COM Interop Registration failed", is caused due to the fact that in your project settings you have set the "Register for COM Interop" flag which means that upon finishing a build, Visual Studio will try to register this assembly for COM interop. This sometimes fails, usually when you have certain types and interfaces that are not compatible with COM. So, to resolve this, either turn off the "Register for COM Interop" option in your project settings or make sure you have all the necessery attributes that enables a .NET object to be access through COM.
The second problem, with regasm, is not really a problem, but only a warning. When using the /codebase parameter regasm will register your assembly in the registry for COM interop, but will add another entry in the registry near the ProgId and CLSID of the object called codebase which will tell .NET to load that specific dll from the place it was registered.
One of the things .NET comes to resolve is what some people refer to as DLL Hell, which is creates a coupling between the registration of a certain COM object to a specific version. Since .NET supports versioning, and if you want to support side-by-side deployment you can make sure to use an exact version of your DLL by signing it and placing it in the Global Assembly Cache (GAC). When you'll run regasm (this time WITHOUT /codebase) it will not add the codebase entry in the registry but will specify the exact version of the .NET object. When the application will try to load it, it will search for that exact version in the registry, helping you a bit to decouple .NET assembly versions to specific locations.
I've written a blog post in my blog about how .NET loads an assembly, this will make it clearer how .NET loads an assembly when accessed from COM after it resolves what assembly to load from the registry.
