Porting the .net Class Library to the Windows Store Storage Class Library

I have a class library that targets .net 4 and is used on different platforms through Mono. Now I want to port it for use in Windows 8. I know that the name continues to change, but it is currently called the "Class Library (Windows Store Apps)" in VS2012.
At first I started by trying to transfer everything to the Portable Class Library, but it turned out to be too complicated, because some things simply did not have a common approach that worked on all platforms, and other supported things simply were not accessible to the compiler.
So I created a Windows storage class library and created links to existing files in my standard class library, so updating one day will update both. I plan to use preprocessing directives to make changes between two class libraries For example

#if NETFX_CORE Task.Delay(someTime); #else new System.Threading.ManualResetEvent(false).WaitOne(sometime); #endif 

My question is, is this method a reasonable approach? I have the same default namespace and assembly name. Could this ever cause problems for my compiler? Aggregates designed for different platforms, therefore, will never be used together in one application, but both will sit in the same solution in Visual Studio.

+4
source share
2 answers

All in all, yes, that should work. This particular case is a bad example, as the two implementations function very differently, illustrating that you may need to rethink some aspects of your design. For cases when there is a similar exchange of APIs (with similar semantics), I personally tend to shift the difference behind the helper method, so my "main" code should not worry about it - just helper code. Reflection would be a good example of this (changes in reflection are annoyingly deep).

Two projects with different target platforms should be in order. I sometimes hit the IDE glitch where it complains about temporary files. I think this is due to file sharing between projects. I registered it when connected

0
source

Try

 Task.Delay(msDelay).Wait() 
0
source

All Articles