REQUEST: Customize ComHost server registry name

[forderud]

This request is a follow-up to #62529 that improved the default naming of the ComHost server name in the registry based on the ProgID in .Net 7.0. The COM class name in registry is now always <namespace>.<class-name> (e.g. "MyNamespace.MyClass"). This is a good default, but it would still be beneficial to also have a mechanism to allow customizing this name, so that the class can e.g. be named "My class".

ASK: Could it be possible to use the [Description("..")] attribute or similar for overriding the ComHost server registry name?

Background: I'm working on a plugin-based SW architecture that uses COM class names in the registry for plugin identification. Providing an ability to customize the name would enable improved plugin naming when using .Net for the implementation.

Steps to reproduce

1. Open the https://github.com/dotnet/samples/tree/main/core/extensions/COMServerDemo/COMServer project
2. Upgrade to Target Framework ".NET 7.0"
3. Build the COMServer project
4. Register COMServer.comhost.dll with regsvr32.exe
5. Open RegEdit.exe and observe that the server name is "COMServer.Server" ("CoreCLR COMHost Server" if using .Net 6) in the Computer\HKEY_CLASSES_ROOT\CLSID\{DB1797F5-7198-4411-8563-D05F4E904956} registry folder:
   

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[AaronRobinsonMSFT]

This seems like a reasonable request. However, the cost here is non-trivial. The biggest issue is that the code involved in setting Registry keys is in native. This means we would need to update the clsid map file format to contain this information, which means updates to the SDK and runtime code. I'm not opposed to this effort but honestly continuing to add minor convenience features for COM registrations seems like a very minor win.

Ideally, the solution would be to move the majority of the COM server Registry key setting code into managed code in the ComActivator class and then we could reflect on the type and consume new attributes. I would argue this is the correct fix and then these new features would be trivial to add. That work though is going to be a bit more effort and will require some indication from the broader community that this has higher priority over other features in flight.