.net – Is it possible to register a .NET assembly for COM interop without adding registry entries

It does the same thing as running Regasm.exe with the /tlb and /codebase options. The /codebase option is probably the one you forgot. Regasm likes assuming you put the DLL in the GAC and generates a warning when you don't. The GAC is indeed a very good way to avoid DLL Hell, always a COM problem. But not appropriate on your dev machine, you don't want to pollute the GAC while developing and testing the code. It only matters on your user's machine, the one that's likely to be exposed to multiple versions.

Using the wrong version of Regasm.exe on a 64-bit machine is another way to get in trouble, there are usually 4 versions on your machine. Be sure to distinguish the 32-bit and 64-bit versions (c:\windows\microsoft\framework vs framework64), they write different registry keys. You want to pick the one that's compatible with the client app. Using both is okay too, .NET code can run in either mode, but pretty unusual. And distinguish between the v2.0.50727 (.NET 2.0 through 3.5SP1) and the v4.0 versions. Picking the right Visual Studio Command Prompt is half the battle.

"Make assembly COM visible" is a big hammer to make all public types in the assembly [ComVisible]. Rarely desirable, you will want to select the specific types that you want to be visible, like you did in your snippet.

After the assembly is built, it needs to be registered so that a COM client can find it back. Which only uses a number to identify the object he wants to create, the GUID, an extra lookup is necessary to find out what DLL implements it. Registering involves writing keys in the HKLM\Software\Classes\CLSID\{guid} portion of the registry. You can do it yourself by running Regasm.exe /codebase /tlb or you can leave it up to the build system to do it automatically after building the assembly.

Which is what "Register for COM interop" does. It is desirable since it ensures that the old copy of the DLL gets unregistered automatically before it is overwritten, that prevents registry pollution. VS needs to run elevated to have write access to those registry keys, one reason for making it optional. Or you just don't want to register it, common on build servers. I can't comment on why you'd sometimes not get the .tlb without more diagnostics.