C# application referencing /clr:netcore creating its own static instances

[fiercekittenz]

I have a WPF net5.0-windows C# application that references a /clr:netcore targeted Managed C++ library. The C# application instantiates a static instance of a core system. When the Managed C++ accesses that instance, instead of seeing it already exists, it creates its own. Any usage of it goes through "native" handles and crashes when it accesses code that isn't available to /clr:netcore (example: Microsoft.Data.SqlClient).

What can be done to stop this behavior, or is this new and intended as of /clr:netcore?

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have a WPF net5.0-windows C# application that references a /clr:netcore targeted Managed C++ library. The C# application instantiates a static instance of a core system. When the Managed C++ accesses that instance, instead of seeing it already exists, it creates its own. Any usage of it goes through "native" handles and crashes when it accesses code that isn't available to /clr:netcore (example: Microsoft.Data.SqlClient).

What can be done to stop this behavior, or is this new and intended as of /clr:netcore?

Author:	fiercekittenz
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[AaronRobinsonMSFT]

@fiercekittenz This is known issue with C++/CLI and how it works in .NET Core 3.1/.NET 5+. WPF is particularly sensitive to this issue and is described at dotnet/wpf#1700.

@vitek-karas and @elinor-fung This seems like another manifestation of the single ALC issue we've been tracking. Is there a specific issue we are using in the runtime?

[AaronRobinsonMSFT]

/cc @agocke

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have a WPF net5.0-windows C# application that references a /clr:netcore targeted Managed C++ library. The C# application instantiates a static instance of a core system. When the Managed C++ accesses that instance, instead of seeing it already exists, it creates its own. Any usage of it goes through "native" handles and crashes when it accesses code that isn't available to /clr:netcore (example: Microsoft.Data.SqlClient).

What can be done to stop this behavior, or is this new and intended as of /clr:netcore?

Author:	fiercekittenz
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[AaronRobinsonMSFT]

I believe #61105 is tracking this general problem.

[elinor-fung]

Also related: #62754

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have a WPF net5.0-windows C# application that references a /clr:netcore targeted Managed C++ library. The C# application instantiates a static instance of a core system. When the Managed C++ accesses that instance, instead of seeing it already exists, it creates its own. Any usage of it goes through "native" handles and crashes when it accesses code that isn't available to /clr:netcore (example: Microsoft.Data.SqlClient).

What can be done to stop this behavior, or is this new and intended as of /clr:netcore?

Author:	fiercekittenz
Assignees:	-
Labels:	area-AssemblyLoader-coreclr, untriaged
Milestone:	-

[fiercekittenz]

Thanks. I did stumble upon that yesterday through some clever web searches. It should be documented somewhere though. I blew 2 days of engineering time trying to figure out what was going on until I fumbled into the other issue thread.

[elinor-fung]

Closing based on #66486 - C++/CLI DLLs targeting .NET 7 will be loaded into the default AssemblyLoadContext.

Documentation was added in dotnet/docs#28850