.NET Framework 4.6.2转.NET Core：不支持DLL解决方案咨询

Hey there, let's break down practical fixes for each of those unsupported libraries—these are super common hurdles when moving from .NET Framework to modern .NET, so you’ve got this.

1. System.ComponentModel.Composition (MEF) #

The classic MEF library isn’t supported in .NET Core, but there’s a modern replacement: MEFv2 (packaged as System.Composition). Here’s how to make the switch smoothly:

• First, install the NuGet package: Install-Package System.Composition
• Swap your namespace references from System.ComponentModel.Composition to System.Composition
• Adjust container initialization: Ditch CompositionContainer and use ContainerConfiguration instead. Example:

  // Old MEF code
  var catalog = new AssemblyCatalog(typeof(MyExport).Assembly);
  var container = new CompositionContainer(catalog);
  container.ComposeParts(this);
  
  // New MEFv2 code
  var configuration = new ContainerConfiguration()
    .WithAssembly(typeof(MyExport).Assembly);
  var container = configuration.CreateContainer();
  var myExport = container.GetExport<IMyExport>();
  

• If you’re already using .NET Core’s built-in DI, you can bridge MEF exports into the DI container with extensions like System.Composition.Hosting or third-party tools like Autofac (which has native MEF integration).

2. System.Runtime.Remoting #

.NET Core completely phased out Remoting because it relied on legacy runtime features. The solution depends on what you were using Remoting for:

• Inter-Process Communication (IPC): Replace with modern alternatives:
  • gRPC: Lightweight, high-performance RPC framework natively supported in .NET Core. Define contracts with protobuf, then generate client/server code.
  • Named Pipes: Use System.IO.Pipes for fast, secure same-machine process communication.
  • HTTP APIs: For cross-machine calls, a simple ASP.NET Core Web API works reliably.
• Dynamic Proxies: If you used Remoting for proxy objects, switch to libraries like Castle DynamicProxy or the built-in System.Reflection.DispatchProxy to create dynamic proxies.
• AppDomain Cross-Code Execution: .NET Core doesn’t support AppDomains. Instead, split code into separate processes, use DI for modularity, or leverage AssemblyLoadContext for isolated assembly loading.

3. System.ServiceModel (WCF) #

.NET Core has partial WCF support—client-side functionality is solid, but server-side support is limited. Here’s your playbook:

• WCF Clients:
  • Use the WCF Web Service Reference Provider tool (right-click your project → Add → Connected Service → WCF Web Service Reference) to generate client proxy code, just like you did in .NET Framework.
  • Install matching NuGet packages: System.ServiceModel.Http, System.ServiceModel.NetTcp, or System.ServiceModel.Security depending on your WCF binding.
• WCF Servers:
  • For most cases, migrate to modern alternatives like ASP.NET Core Web API (REST) or gRPC—both are better supported and future-proof.
  • If you need to keep existing WCF services running, leave them on .NET Framework and have your .NET Core app call them via HTTP/gRPC as a temporary bridge.
  • For advanced WS-* protocol needs, niche third-party libraries exist to bring full WCF server support to .NET Core, but these are last-resort options.

Remember, migration doesn’t have to be all-or-nothing. You can incrementally replace these components, test each change, and gradually move your app to .NET Core.

内容的提问来源于stack exchange，提问作者karthikraja