如何创建或使用现成的Shims从.net框架移植到.net core/standard？

Question

如何为元素创建或使用现成的Shims来.net framework 4.6.1将它们(从.net framework 4.6.1)移植到.net core 2.0/ .net standard 2.0？

---

一些感兴趣的类:对于像以下类这样的类具有垫片会很好:

System.Windows.Threading.Dispatcher

要么

System.ComponentModel.ItemPropertyInfo.Descriptor

甚至

System.Windows.Controls.MenuItem

还有很多...

---

语境:

应用程序(代码)不是100%组织良好.业务逻辑与UI逻辑没有100%的分离.答案"先做重构"绝对是一个很好的答案.但就我而言,事情并非100%理想.

---

近似的例子,试图用手工做:

System.Windows.Threading.Dispatcher未实施Core 2.0.

人们可以尝试添加:

public enum DispatcherShimPriority
{
    Background
    //...
}

public interface DispaicherShim
{
    void Invoke(Action action, DispatcherShimPriority prio);
    void BeginInvoke(Action action, DispatcherShimPriority, prio);
}

接下来是这个接口的两个实现:

public class DispatcherCore: DispaicherShim;

和

public class DispatcherFramework: DispaicherShim;

Shims在多目标项目中跟随aa类(让我们称之为):

public static DispaicherShim CreateDispatcher()
{
#if NETCOREAPP2_0
    return new DispatcherCore();
#else
    return new DispatcherFramework();
#endif       
}

结果是垫片,可以在不同的API中使用.

这是正确的方法吗？

---

实际上,创建这样的垫片需要很多日常工作.我觉得这项工作没有必要进行.我觉得这个问题有一个现成的解决方案......

---

我知道Microsoft.Windows.Compatibility包裹.当WPF涉及许多特定于wpf的元素时,问题与移植相关.这些元素不在Microsoft.Windows.Compatibility包中,但不幸的是,它们在我的程序集中使用,这些程序集可以重新定位.Net Core 2.0.我的意思是填补那些不在的课程Microsoft.Windows.Compatibility.

好的,我们有这个Microsoft.Windows.Compatibility.Shims,但我不确定它在我的情况下是否有用; 特别是在阅读以下文字后:

Microsoft.Windows.Compatibility.Shims:此包提供基础结构服务,不应直接从您的代码中引用....

---

Upd:强调最终目标是.net core 2.0

Upd2:整个任务是将WPF应用程序的主要部分移植到.net core(留下工作的WPF应用程序)潜在的Web客户端.主要部分包含.net framework未实现的元素.net core.

Upd3:关于完整策略的几个词:更完整的策略是共享项目,本文的第一种方法(#if).我的策略有两个主要步骤:一个是逐步移植代码,从基础库开始,在顶级库中完成,但是大量使用存根和PlatformNotSupportedExceptions.第二步是从顶级库转移到基础库,用.net核心实现替换存根和异常,按需(!) - 不需要替换所有存根和异常.

Upd4我们已经将便携式测试从非便携式测试中拆分为两个库.在移植过程中运行测试非常重要.

Answer 1

从标准 .Net 迁移到 .Net Core 不仅仅是升级，考虑到事物的组合方式，您几乎可以将其称为迁移到新平台。迁移到 .Net core 意味着学习和创建一个可以复制现有代码的新框架。

由于.Net core 1、1.1、2.0和2.1之间存在很大差异，这些迁移过程发生了很大变化，因此没有一种适合所有“垫片”的方法，并且可以快速制作某种包装器或迁移工具过时的。需要完成一些工作来迁移您的代码。

一些核心操作系统 API 是相似的，但许多框架代码已被移动或更改，因此追逐同类交换也可能很困难。确实值得做一些研发来看看差异在哪里，更不用说使用第三方库等了。