How to create or use ready Shims for porting from .net framework to .net core / standard?

Question

How to create or use ready Shims for .net framework 4.6.1 elements to port them (from .net framework 4.6.1) to .net core 2.0 / .net standard 2.0?

---

Some classes of interest:, it would be nice to have shims for classes like:

System.Windows.Threading.Dispatcher

or

System.ComponentModel.ItemPropertyInfo.Descriptor

even

System.Windows.Controls.MenuItem

and many more...

---

Context:

The application (the code) is not 100% well organized. Business logic is not 100% separated from UI logic. The answer "do refactoring first" is definitely a good answer. But in my case things are not 100% how they should ideally be.

---

Approximate example, a try to do it mannually:

System.Windows.Threading.Dispatcher is not implemented in Core 2.0.

One could try to add:

public enum DispatcherShimPriority
{
    Background
    //...
}

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

Followed by two implementations of this interface:

public class DispatcherCore: DispaicherShim;

and

public class DispatcherFramework: DispaicherShim;

Followed by a a class (let's call it Shims) in a multitargeted project:

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

The result is the shim, which could be used in different APIs.

Is this a correct approach?

---

Actually, creating such shims requires much routine work. I have a feeling that this work is not necessary to be performed. I have a feeling that there is a ready solution for this problem...

---

I'm aware of Microsoft.Windows.Compatibility package. The question is rather related to porting when WPF is involved with many wpf-specific elements. Those elements are not in Microsoft.Windows.Compatibility package, but, unfortunately, they are used across my assemblies, which are candidates for retargeting to .Net Core 2.0. I mean shimming those classes, which are not in Microsoft.Windows.Compatibility.

Ok, we have this Microsoft.Windows.Compatibility.Shims, but i'm not sure that it is useful in my case; especially after reading the following text:

Microsoft.Windows.Compatibility.Shims: This package provides infrastructure services and shouldn't be referenced directly from your code....

---

Upd: emphasizing that the final target is .net core 2.0

Upd2: the whole task is to port the major part of a WPF app to .net core (leaving working WPF app) for potential web-client. The major part contains .net framework elements which are not implemented for .net core.

Upd3: Couple of words about complete strategy: The more complete strategy is Shared projects, first approach in this article (#if) . There are 2 major steps in my strategy: one is to gradually port code, starting from base libraries and finnishing at top libraries, But with intense use of stubs and PlatformNotSupportedExceptions. The second step is to move from top libraries to base libraries substituting stubs and exceptions by .net core implementations, On demand (!) - no need to subsitute all stubs and exceptions.

Upd4 We have already split portable tests from non-portable tests (into two libs). It is very important that we run the tests during the porting process.

Answer 1

Moving from Standard .Net to .Net Core is not just an upgrade, you could almost call it a move to a new platform considering how things are put together. Moving to .Net core means learning and creating a new framework where existing code can be copied.

Due to the large differences between .Net core 1, 1.1, 2.0 and 2.1 The migration process form these has changed a lot, so there is no 1 size fits all "shim" and having some kind of wrapper or migration tool would be quickly made obsolete. Work needs to be done to migrate your code.

Some core OS APIs are similar but a lot of framework code has been moved or changed, so chasing like for like swaps might also be difficult. Its really worth doing some R&D to see where the differences are not to mention the use fo 3rd party libraries etc.