.NET Core should support out-of-proc COM (i.e. LocalServer32)

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

netcore 3.1 c# project offers building com interop assemblies.
However regsvr32.exe applied to generated yxz.comhost.com registers only InProcServer.

Please provide LocalServer32 for netcore com interop!

The issue:

It makes the netcore com component not usable by native clients
This is because the com component is loaded into native client process which does not provide app.config
what netcore runtime is searching for for the entry assembly's app.config as soon as netcore com component chooses to use
System.Configuration.ConfigurationManager which results in PlatformNotSupportedException

The sequence of steps / events

1. netcore com componente ist created
2. revsrv32.exe xyz.vomhost.dll
   only InProcServer is registered
3. native client calls CoCreateInstance
4. netcore com component is loaded into addressspace of the native Process
5. native process calls into the com component
6. com component uses System.Configuration.ConfigurationManager
   for example by using Microsoft.Data.SqlClient
7. System.Configuration.ConfigurationManager throws PlatformNotSupportedException

Making netcore com component true out-of-proc com component would allow true com interop
That is running com component in its own process

---

Original Comments

Visual Studio Feedback System on 7/3/2020, 02:51 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[AaronRobinsonMSFT]

Hi Miroslaw, There are two issues here.

1. Failure using System.Configuration.ConfigurationManager for a .NET Core component.
2. Out-of-proc COM is supported.

These are actually unrelated to one another and providing (2) won't necessarily solve (1).

(1) I believe that System.Configuration.ConfigurationManager typically uses an app.config, but I am not sure it is a hard requirement. I would have to defer to someone like @stephentoub or @jkotas for that verification. The fact that it doesn't work for a loaded COM component makes sense because as you pointed out, the native binary doesn't provide one. I would assume this would be the same issue in .NET Framework.

(2) The implied assumption above for the out-of-proc COM would be that the hosting application would be managed, but that doesn't need to be the case. For example a native out-of-proc COM server could be written that exposes a managed COM component and in that case there would also be no app.config. There are also other scenarios like DllSurrogates that are out-of-proc, but utilize the Windows provided host - they too would lack an app.config.

It seems the specific ask here is a particular type of out-of-proc COM server support that would be a pure managed app process or put another way a managed app that can be generated to act as an out-of-proc COM server. This approach is absolutely possible but does have an annoying limitation compared to .NET Framework. At present there is no support for TlbExp in .NET Core or any dynamic generation of TLBs at run time. This means that the user would need to expose types defined in an IDL and generated for .NET Core or hand authored in C/C++ and defined in some .NET language (e.g. C#). There would also be a decent amount of work in the SDK to support generation of the needed COM assets (e.g. manifests) as well as an example/guidance on how to author an out-of-proc COM server properly in managed. A project template could be created for this scenario but there is a decent amount of complexity to get that right for all users.

I agree that supporting out-of-proc COM is interesting. It can technically be done. It is at this moment simply a manual and non-trivial amount of work for the developer. This is something we will need to consider in a future release since it would impact multiple aspects of the runtime (e.g. interop, hosting, SDK).

/cc @jkoritzinsky @elinor-fung @vitek-karas @agocke

[jkotas]

System.Configuration.ConfigurationManager throws PlatformNotSupportedException

What is the stack trace and error message of the PlatformNotSupportedException that you are seeing?

[mi-dn]

System.TypeInitializationException: 'The type initializer for 'Microsoft.Data.SqlClient.SqlConnection' threw an exception.'

InnerExcewpotion 1
InvalidOperationException: Failed to read the configuration section for enclave providers. Make sure the section is correctly formatted in your application configuration file. Error Message: Configuration system failed to initialize

InnerException 2
ConfigurationErrorsException: Configuration system failed to initialize

InnerException 3
PlatformNotSupportedException: Operation is not supported on this platform.

StackTrace
This exception was originally thrown at this call stack:
System.Configuration.ClientConfigPaths.ClientConfigPaths(string, bool)
System.Configuration.ClientConfigPaths.GetPaths(string, bool)
System.Configuration.ClientConfigurationHost.ConfigPaths.get()
System.Configuration.ClientConfigurationHost.GetStreamName(string)
System.Configuration.ClientConfigurationHost.IsAppConfigHttp.get()
System.Configuration.Internal.DelegatingConfigHost.IsAppConfigHttp.get()
System.Configuration.ClientConfigurationSystem.ClientConfigurationSystem()
System.Configuration.ConfigurationManager.EnsureConfigurationSystem()

[jkotas]

This is #25027 that was fixed by #32195 . You can try referencing .NET 5 preview version of https://www.nuget.org/packages/System.Configuration.ConfigurationManager/5.0.0-preview.6.20305.6 to see whether it fixes the problem you are seeing.

[AaronRobinsonMSFT]

@dougie1970 @DoCode Would a sample for creating an out of proc server help or is the need for real first class support?

[dougie1970]

A sample would be awesome.  I only have 2 classes that are exposed to COM. On 7/21/2020 1:27 PM, Aaron Robinson wrote: @dougie1970 @DoCode Would a sample for creating an out of proc server help or is the need for real first class support? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "#38814 (comment)", "url": "#38814 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[AaronRobinsonMSFT]

@dougie1970 Okay. A sample is something we might be able to offer up. It would also give us a chance to prototype a proper solution and enable more accurate costing.

/cc @jeffschwMSFT @jkoritzinsky @elinor-fung

[AaronRobinsonMSFT]

@dougie1970 @elinor-fung has created an out-of-proc COM server sample using .NET Core 3.1 since that is the minimum supported version. The sample could be re-targeted to ,NET 5 and made more efficient using some of the new interop features.

Please let us know what you think: https://github.com/dotnet/samples/blob/master/core/extensions/OutOfProcCOM/README.md

[AaronRobinsonMSFT]

Now that we have a sample of how we are going to close this issue. If there are more targeted things that would help with supporting this scenario please feel free to file new issues/proposals for those utilities.