咨询：无需转换项目，.Net Framework桌面UI对接.Net Core后端的方案

Great question—this is such a common pain point when modernizing legacy .NET apps without committing to a full rewrite upfront. Let’s walk through the most practical, low-friction solutions to get your .NET Core backend talking to your .NET Framework desktop UI right now, while keeping your future Web/cross-platform goals in mind:

1. HTTP API (REST/gRPC) – The Most Future-Proof Approach #

This is my top recommendation because it aligns perfectly with your long-term plan to move to Web/cross-platform, and it’s fully decoupled.

How to implement: #

• On the .NET Core side: Spin up a lightweight ASP.NET Core Web API project (or add API controllers to your existing Core backend). You can also use gRPC if you need high-performance, strongly typed communication.
• On the .NET Framework side: Use the built-in HttpClient (available in .NET Framework 4.5+) to call these API endpoints. For gRPC, you can use the official gRPC NuGet package for .NET Framework.

Example Code Snippets: #

.NET Core API Controller:

[ApiController]
[Route("api/legacy")]
public class LegacyIntegrationController : ControllerBase
{
    private readonly ICoreBusinessService _businessService;

    public LegacyIntegrationController(ICoreBusinessService businessService)
    {
        _businessService = businessService;
    }

    [HttpGet("customer/{id}")]
    public async Task<IActionResult> GetCustomer(int id)
    {
        var customer = await _businessService.FetchCustomerAsync(id);
        return Ok(customer);
    }
}

.NET Framework Desktop Client Call:

// Reference a shared .NET Standard 2.0 library with your model classes (e.g., Customer)
using (var httpClient = new HttpClient())
{
    httpClient.BaseAddress = new Uri("http://localhost:5000/api/legacy/");
    try
    {
        var response = await httpClient.GetAsync($"customer/{customerId}");
        response.EnsureSuccessStatusCode();
        
        var customer = await response.Content.ReadAsAsync<Customer>();
        // Update your desktop UI with the customer data
        customerNameLabel.Text = customer.FullName;
    }
    catch (HttpRequestException ex)
    {
        // Handle errors appropriately
        MessageBox.Show($"Failed to fetch customer: {ex.Message}");
    }
}

Pros & Cons: #

• Pros: Fully decoupled, supports remote/networked deployments, aligns with future Web/cross-platform plans, easy to test with tools like Postman.
• Cons: Requires writing API endpoints (minimal overhead, but still extra work).

2. Named Pipes – Lightweight Local Inter-Process Communication #

If your desktop UI and .NET Core backend run on the same machine, named pipes are a fast, low-overhead option that doesn’t require a network stack.

How to implement: #

• Both .NET Core and .NET Framework support the System.IO.Pipes namespace. Set up a pipe server in your .NET Core backend, and a pipe client in your desktop UI. Use JSON or Protobuf to serialize data between them.

Example Snippet (Named Pipe Client in .NET Framework): #

using (var pipeClient = new NamedPipeClientStream(".", "LegacyCorePipe", PipeDirection.InOut))
{
    pipeClient.Connect();
    var serializer = new JsonSerializer();

    // Send request to backend
    using (var writer = new StreamWriter(pipeClient))
    {
        writer.WriteLine(JsonConvert.SerializeObject(new GetCustomerRequest { Id = 123 }));
        writer.Flush();
    }

    // Read response from backend
    using (var reader = new StreamReader(pipeClient))
    {
        var responseJson = reader.ReadLine();
        var customer = JsonConvert.DeserializeObject<Customer>(responseJson);
        // Update UI
    }
}

Pros & Cons: #

• Pros: No network required, fast performance, minimal setup for local-only scenarios.
• Cons: Ties you to local deployment (won’t work if backend is on a remote server), less aligned with future Web goals.

3. Shared .NET Standard Library + Message Queue – Decoupled Asynchronous Communication #

If you need asynchronous, fire-and-forget communication (e.g., background tasks), this approach works well while keeping both systems loosely coupled.

How to implement: #

1. Create a .NET Standard 2.0 library containing your shared data models and message contracts (since .NET Framework 4.5+ supports .NET Standard 2.0).
2. Use a message queue like RabbitMQ or Azure Service Bus (both have clients for .NET Framework and .NET Core).
3. Have your .NET Core backend publish messages to the queue, and your desktop UI subscribe to them (or vice versa).

Pros & Cons: #

• Pros: Fully decoupled, supports async workflows, great for complex interactions, prepares you for future microservices architectures.
• Cons: Requires setting up and maintaining a message queue service (adds operational overhead).

4. COM Interop – Last Resort for Quick, Tight Integration #

Only use this if the above options aren’t feasible (e.g., strict time constraints with no room for API development). It’s a legacy approach but works for quick wins.

How to implement: #

• Mark your .NET Core classes/methods as [ComVisible(true)] and register the assembly as a COM component.
• In your .NET Framework desktop app, add a reference to the COM component and call it directly.

Important Note: #

.NET Core’s COM support is limited (works best with .NET Core 3.0+), and this approach locks you into Windows-only deployments, which conflicts with your cross-platform goals. Use this as a temporary fix only.

Final Recommendation: #

Go with the HTTP API approach first—it’s the most flexible, future-proof solution that sets you up for your eventual Web/cross-platform transition. If you only need local communication right now, named pipes are a great lightweight alternative.

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