Return to Question

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.

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.

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

Actually, creating such shims requeres 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...

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.

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...