Windows ComHost COM registration in HKCU instead of HKLM?

[smourier]

As far as I know, currently, to register a COM object written in .NET 5 (or .NET Core 3.x for that matter) we need to

"Open an elevated command prompt and run regsvr32 ProjectName.comhost.dll. That will register all of your exposed .NET objects with COM." from here

https://docs.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com#register-the-com-host-for-com

I think the relevant source is here: https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/comhost/comhost.cpp#L309 it seems pretty much hardcoded for HKEY_LOCAL_MACHINE.

As you know, registering COM component in HKCU (HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID for the CLSID, etc.) is pretty common and supported by "COM" in general (CoCreateInstance, etc.). It's also supported by tooling such as Visual Studio's ATL and Windows' regsvr32.exe with the help of DllInstall (optional) DLL export:

https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-dllinstall

It has the enormous advantage of avoiding elevated rights for setup, installers, etc.

Can support for this be added to comhost?

In the meantime, is there any way to do this with current .NET 5? Should I write a custom comhost? How?

[Wraith2]

I'm aware that registering com servers in the user hive functions but is it a supported configuration? You cite using DllInstall but that simply allows you to integrate custom registration logic it doesn't provide you a supported way to register user rather than local machine level servers.

As far as I'm aware registration free com using manifests is the suggested way of dealing with registration elevation permissions requirement issues.

[smourier]

Supported by who? what? As I said, yes, it's supported by CoCreateInstance, and COM/Windows in general, including all Shell API (Explorer, Common Dialogs, etc.).

I know DllInstall in itself doesn't allow anything special, I'm not specifically attached to that, but try Visual Studio ATL's and you'll see that's how it supports HKCU registration in the wizard-generated code:

// DllInstall - Adds/Removes entries to the system registry per user per machine.
STDAPI DllInstall(BOOL bInstall, _In_opt_  LPCWSTR pszCmdLine)
{
	HRESULT hr = E_FAIL;
	static const wchar_t szUserSwitch[] = L"user";

	if (pszCmdLine != nullptr)
	{
		if (_wcsnicmp(pszCmdLine, szUserSwitch, _countof(szUserSwitch)) == 0)
		{
			ATL::AtlSetPerUserRegistration(true);
		}
	}

	if (bInstall)
	{
		hr = DllRegisterServer();
		if (FAILED(hr))
		{
			DllUnregisterServer();
		}
	}
	else
	{
		hr = DllUnregisterServer();
	}

	return hr;
}

registration-free means you must distribute the components with the clients. This answers different scenarios.

[AaronRobinsonMSFT]

I'm aware that registering com servers in the user hive functions but is it a supported configuration?

At present, it is not supported in .NET Core 3.0+ or .NET 5. COM registration is only supported for the HKLM hive. This was chosen for security reasons. In .NET Framework the behavior had issues that were not appropriate and relied upon legacy registry behavior from the Windows 95/98 days. We are now explicit about this and force HKLM.

As far as I'm aware registration free com using manifests is the suggested way of dealing with registration elevation permissions requirement issues.

Yes. That would be our suggested workaround.

registration-free means you must distribute the components with the clients. This answers different scenarios.
Can support for this be added to comhost?

@smourier Your concerns with RegFree COM are valid and I empathize with the issue. I don't personally think we should be continuing some of the questionable COM practices of yore, but do recognize there are applications that have been built up around this option. We can absolutely add support for it, as you discovered it is hardcoded and wouldn't be technically difficult to add a flag or some metadata that indicates where one would like the registration to go. When it was implemented the "most common" scenario was selected - not a lot more thought put into it.

Feel free to propose a mechanism in this issue's description or we can prioritize it as is with other interop feature requests. I would imagine a new attribute would suffice or perhaps extend ComRegisterFunctionAttribute? Both of these would have to go through the official .NET API review - I am more than willing to help shepherd them. Non-API impacting suggestions are possible as well (i.e. environment variable during registration or modify .clsidmap generation, we would likely need an API for the later). I haven't given any of these options much though so feedback/initiative from you or the community as to direction would be appreciative to start the process.

[smourier]

Thanks for your answer.

If such a feature is added, it's very important to decide where registration happens at deployment time vs compilation time. This is what the ATL-generated code does.

So, my initial idea was really not to change any .NET API but instead add support in comhost for a DllInstall parameter that would instruct the registration to happen in HKCU instead of HKLM. So, COM-support related code stays in COM-support related binaries, impact on .NET is minimal.

Since .NET 5 requires each COM coclass guid to be specified, I could even imagine a DllInstall command that could be able to support one component in HKCU, another in HKLM, but maybe that's too complicated. By default, all components would be in HKCU or all in HKLM.

regsvr32 (which supports DllInstall) is very well known and in fact already referenced in the .NET Core doc here: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.comregisterfunctionattribute?view=net-5.0) but that would support custom installers calling DllInstall too.

[Wraith2]

Adding the ability to perform user registrations would also have an effect on tools that generate or gather registration information. For example when I last used WiX to generate installers the official advice was not to try and invoke DllInstall dynamically at install time but to do a gather step and embed the resulting registry alterations. Properly written this won't change if registration if in hkcu instead of hklm but I expect there to be improperly written apps out there that only redirect hklm because that's all that was supported. This is why I asked whether it was a supported scenario, while I know per-user registration works if it isn't supported it can put consumers in a situation where they are doing something that could cause a support ticket to be rejected.

For clarity, I like the idea and I think extending ComRegisterFunctionAttribute with a per-user flag would be a nice way to do it, but I also think there will be ecosystem knock-on effects.

[govert]

@AaronRobinsonMSFT You say:

In .NET Framework the behavior had issues that were not appropriate and relied upon legacy registry behavior from the Windows 95/98 days.

Do you have some more information or a reference about these issue?

The registry behaviour under the Office Click-to-Run environment (I think it is related to App-V) has also been problematic in recent Office versions, with undocumented registry types and unexpected behaviour in different versions.

In general the component developer has little control over the environment into which this must be installed or run, so so some flexibility about the registration is very valuable - when it runs, registry vs. SxS activation contexts, and some HKCU plan if possible.

[AaronRobinsonMSFT]

In the meantime, is there any way to do this with current .NET 5? Should I write a custom comhost? How?

Missed this query. It is entirely possible and one could use the existing source to start. One missing aspect from the source is the need to link against our public low level host API (i.e. nethost.lib). A sample exists for that here.

regsvr32 (which supports DllInstall) is very well known and in fact already referenced in the .NET Core doc here: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.comregisterfunctionattribute?view=net-5.0) but that would support custom installers calling DllInstall too.

@smourier Yep. Support for COM in .NET Core 3+ and .NET 5 was designed to make the UX align with long standing COM tooling. This may be a difficult change in the short term but we are hoping it aligns better with long standing COM developers as opposed to .NET providing an alternative COM registration methodology. Your suggestion to use DllInstall aligns with that goal.

I personally have no issue with enabling DllInstall support, but as @Wraith2 said the UX is going to require some thought.

For example when I last used WiX to generate installers the official advice was not to try and invoke DllInstall dynamically at install time but to do a gather step and embed the resulting registry alterations.

@Wraith2 Yes that is indeed the correct advice. WiX and MSIs handle the reference counting logic for the installation whereas regsvr32 doesn't. I agree with your general sentiment here and before we support this we would need to investigate some existing use patterns to ensure existing developers can still accomplish their goals.

Do you have some more information or a reference about these issue?

@govert Unfortunately those details aren't something I am permitted to discuss for various reasons. I can say we are now explicitly registering in the HKLM hive to ensure we know where the server is registered. This provides explicit behavior that aligns with work done in the OS during the Windows Vista time frame. I really can't comment further.

[lauxjpn]

The traditional way to write the COM related registry keys in the HKCU hive on demand is to use the OaEnablePerUserTLibRegistration and RegOverridePredefKey functions.

Once you have moved the registry context to HKCU, you would just load the YourApp.comhost.dll via LoadLibrary and call its DllRegisterServer or DllUnregisterServer entry point.

All HKCR related keys are then written to HKCU\Software\Classes instead of HKLM\Software\Classes.

---

While regsvr32.exe never had a user-level registration feature, there are tools out there that do this, in case you don't want to implement it yourself. One of those tools is RegSvrEx, though it does not seem to call OaEnablePerUserTLibRegistration (might be worth a PR).

I've also got some .NET code I could publish (just in case anybody is interested at some point in the future), which does all that and that I have been using for years in scenarios, where Reg-Free-COM via manifests is not an option (e.g. when you want to load components into Office applications, but can't get elevated and of course can't just modify the manifest file of the Office app).

---

Feel free to propose a mechanism in this issue's description or we can prioritize it as is with other interop feature requests. I would imagine a new attribute would suffice or perhaps extend ComRegisterFunctionAttribute?

@AaronRobinsonMSFT I would also suggest a new attribute (or attribute pair). I am also interested in that, because of .NET's current lack of TLB generation. So when I manually generate a TLB from an IDL file via MIDL.exe, I want to register the type library during the standard registration process. This is currently only possible by using the ComRegisterFunctionAttribute, which is conceptionally not the right place to do this (especially with multiple COM classes in one assembly).

[AaronRobinsonMSFT]

This is currently only possible by using the ComRegisterFunctionAttribute, which is conceptionally not the right place to do this (especially with multiple COM classes in one assembly).

@lauxjpn I'm not sure I follow this. The function marked with ComRegisterFunctionAttribute is immediately following registration so I am curious where you feel the right place for this? Would your suggestion be something akin to TlbRegisterFunctionAttribute?

[lauxjpn]

Would your suggestion be something akin to TlbRegisterFunctionAttribute?

@AaronRobinsonMSFT Something like that. It does not necessarily have to be tied to the TLB, but it should be called only once per DllRegisterServer/DllUnregisterServer call.

Maybe an additional attribute can be introduced, that could then be placed on a class, marking it as a [ComRegistrationClass] or something similar. Then the [ComRegisterFunction] and [ComUnregisterFunction] attributes could be reused in this context on the classes methods. The class level attribute could be restricted to static classes. Enumerating the decorated classes in ComActivator should not be much of a performance concern, since registration is usually not done on a hot path (and usually even outside of the normal application runtime).

A more modern approach would be to use something convention based, but this would break with the pattern to use attributes, that has been established for COM in .NET about 20 years ago, so its probably not a good idea.

[AaronRobinsonMSFT]

but it should be called only once per DllRegisterServer/DllUnregisterServer call.

So I could be mistaken here, but a function with that attribute is only called once during the respective DllRegisterServer/DllUnregisterServer call. How would the above suggestion differ in this case?

The class level attribute could be restricted to static classes. Enumerating the decorated classes in ComActivator should not be much of a performance concern, since registration is usually not done on a hot path (and usually even outside of the normal application runtime).

This would be creating a lot of new policy for a system that we don't believe will continue to evolve much. Is there a perception that this approach is something that will grow in popularity which would make investment important or slowly decrease as time progresses? Office - which has historically been the most popular .NET COM interop consumer - seems to focus far more on JavaScript Add-Ins.

Note: I am not suggestion COM or Office COM extensions aren't important. I am trying to understand the community perspective and if this is a growing area to invest in or if this area may not warrant time to prioritize improvements in.