The /codebase option is the exact equivalent of the way you used to register COM servers with Regsvr32.exe. You'll have to pick a specific location for the DLL and the path to that location is written to the registry. That's risky, COM servers have a strong DLL Hell problem since their registration is machine-wide. When you update that DLL then any application that uses the server will be affected. Not often in a good way, this very often breaks an app that was not recompiled to use the updated server.
.NET improves on that by being able to store multiple versions of a DLL as selected by their [AssemblyVersion]. The exact equivalent of the Windows side-by-side cache, the GAC for managed assemblies. So old apps that were not rebuilt will continue to run unaffected, still being able to use the old DLL. That's a good way.
Using /codebase is advisable when you are busy developing the server. You can skip the extra required step that registers the DLL in the GAC. Forgetting to do so is painful, your changes won't seem to work because the test app will load the old version. Regasm will display a warning when you use /codebase, warning you about the DLL Hell potential, you can ignore it.
When you let Visual Studio take care of the registration with the Project > Properties > Build tab, "Register for COM interop" checkbox then you get the exact equivalent of Regasm /codebase /tlb. It is more desirable to do it this way because it also ensures that the old version of the assembly gets unregistered, thus avoiding registry pollution. But VS has to run elevated so it can write to the registry.
Using Isolated COM (aka "registry-free COM") is the best way. It lets you store a copy of the COM server in the same directory as the client program and you don't have to register it at all. That however requires tinkering with the client program, difficult if you don't have any control over the client app or if it is the kind of app that other people like to mess with. Microsoft Office apps for example.
