.NET Framework和.NET CORE混合存在哪些问题? [英] What are the problems with mixing .NET Framework and .NET CORE?

问题描述

我有大量的中端和后端组件(存储库，服务等)，它们是针对.NET Framework 4编写的，但仍与我正在研究的新项目有关.这个新项目的前端将用ASP .NET CORE2.2编写.我应该怎么做-在.NET CORE中重新创建所有组件，或者使后端在.NET Framework上运行而前端在CORE上运行?在例如性能?

I have a load of middle and back end components (repositories, services etc) that were written against the .NET Framework 4 but that are still relevant to a new project that I'm now working on. The front end of this new project will be written in ASP .NET CORE2.2. What should I do - recreate all components in .NET CORE or keep the back end running against .NET Framework while the front end runs against CORE? What are the considerations in terms of e.g. performance?

推荐答案

通过组件，我想您正在谈论类库.您应该意识到，类库的目标框架基本上只指定了特定的API兼容性.最后打包的实际框架代码是基于实际应用程序的目标框架的.

By components, I'd imagine you're talking about class libraries. What you should realize is that the target framework of a class library basically just specifies a particular API compatibility. The actual framework code that's packaged in the end is based on the actual app's target framework.

换句话说，您可以将针对.NET Framework的类库项目的引用添加到针对.NET Core的应用程序中，然后将该应用程序发布到仅安装了.NET Core的计算机上，然后它将运行(没有.NET Framework).从理论上讲，至少.

In other words, you can add a reference to a class library project that targets .NET Framework to an app that targets .NET Core and then publish that app to a computer that only has .NET Core installed, and it will run (without .NET Framework). Theoretically, at least.

.NET Core在技术上不支持.NET Framework参考.它支持.NET Standard参考.但是，.NET Standard 2.0的API占用空间足够大，并且.NET Framework NuGet程序包的后目录和Internet上浮动的其他库也足够大，以至于Microsoft调整了编译器以允许直接引用.NET Framework库.大多数以.NET Framework为目标的代码实际上可以直接以.NET Standard为目标，而无需进行更改，并且Microsoft认为在大多数情况下掷骰子是足够安全的，而不是等待每个库维护者更改其库的目标框架.NET标准(这些库中的许多都不再维护了).

.NET Core doesn't technically support .NET Framework references. It supports .NET Standard references. However, the API footprint of .NET Standard 2.0 was large enough, and the back catalogue of .NET Framework NuGet packages and other libraries floating around the Internet was large enough, that Microsoft tweaked the compiler to allow direct referencing of .NET Framework libraries. The majority of .NET Framework-targeting code could actually target .NET Standard instead, without change, and Microsoft determined it was safe enough to roll the dice in most cases, rather than waiting on every library maintainer to change the target framework of their libraries to .NET Standard (many of these libraries aren't even maintained any more).

但是，有一个很大的警告.执行此操作时，您会收到编译器警告，基本上是在告诉您这里没有保证.它可以让您添加引用并 try 来使用它，但是如果.NET Core不支持使用的任何API，它将崩溃并刻录.然后由您来彻底测试您的应用程序，确保没有任何问题，然后根据需要抑制警告.

However, there's a big caveat. When you do this, you'll get a compiler warning, basically telling you that there's no guarantees here. It's going to let you add the reference and try to use it, but if there's any APIs utilized that aren't supported by .NET Core, it'll crash and burn. It's then up to you to thoroughly test your app, ensure that nothing is broken, and then you can suppress the warning, if you like.

总之，您可以直接在.NET Core 2.0+中引用.NET Framework库.他们可能实际上并没有最终工作，但是只要他们不使用任何不受支持的API(通常是Windows特定的东西，例如绘图，音频，GUI/绘画等)，那么您就可以了.

Long and short, you can directly reference .NET Framework libraries in .NET Core 2.0+. They may not actually end up working, but as long as they don't use any unsupported APIs (usually Windows-specific stuff such as drawing, audio, GUI/paint, etc.), then you'll be fine.

但是，如果您维护这些库，最好的选择是将它们重新定位到.NET Standard 2.0.如果您可以让他们对此进行编译，那么您将知道不会有任何问题，而不仅仅是猜测或希望，它不会对任何现有的.NET产生任何影响也使用它们的框架应用程序.

However, if you maintain these libraries, your best bet is to retarget them to .NET Standard 2.0. If you can get them to compile on that, then you'll know there won't be any issues, instead of just guessing or hoping, and it won't have any impact on any existing .NET Framework applications that use them as well.

这篇关于.NET Framework和.NET CORE混合存在哪些问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！