COM is not that popular with .NET because the Global Assembly Cache (GAC) and the internal manifests built in to .net assemblies solves the same purpose that COM registration does.
Here is a useful article that might help explain it, here is a snippit from it
.NET provides a completely new approach to creating and deploying
components, which are also known as assemblies. With COM, the
developer has to register the component on the server -- i.e, its
information had to be updated in the system registry. The purpose is
to keep the information of the components in a central location so
that COM+ can find the appropriate component.
With .NET assemblies, the assembly file encapsulates all the meta data
required in special sections called manifests. [...] Since the
information about the component is kept in manifests, the developer
doesn't have to register the component on the server, and several
versions of the same component can safely co-exist together on the
same machine.
The article does not actually mention the GAC, but any cross vendor interaction or binary backwards compatibility you would do with COM can be handled in .NET by the vender registering the assembly in the GAC and your program using that assembly.
The only time .NET uses COM is when interoperating with unmanaged code that was written originally for COM.
However, many vendors don't even use the GAC today either, what they will do is ship a assembly that the programmer can add to the project and deploy with the exe, typically using NuGet to distribute it.