[kozukumi]

Have you written about how you found the process? The good and bad things, etc. With UWP being so new and untested it is hard to find much information on porting an already established codebase to the platform. How is performance, etc?

[maxpert]

Hey thanks for your interest, I have been working on UWP for quite a while now; it has been both good and bad.

My biggest gripe right now is no good DB support (SQLite requires an extension and that two is not enough; you have next to nothing ORMs and well EF7 is still RC). In today's world I can't image an App not finding database as a useful platform feature, Android/iOS have builtin DB support and they prove the fact how important DB support could be. I just don't understand what were people smoking when they made a decision to not include a DB framework in UWP.

XAML framework has it's own bugs, caveats, and yes there is next to nothing material available to help you. They have improved a-lot with x:Bind but then you find bugs like this https://social.msdn.microsoft.com/Forums/en-US/c2bde144-47ae... over which you would spend a whole week and then say "AH FUCK IT; use Binding instead".

Performance is good with .NET native but not as good as you would picture a native code to be. I have seen Java blowing my mind just with JIT. Personally I felt Microsoft has done good job of performance on PC since they have mastered the x86/x64, but ARM feels a little slow to me.

I personally strongly feel (coming from WP 8.1 platform) that UWP is better but it feels like an RC; it has broken ends, missing good documentation (hell wrong documentation sometimes), and next to nothing opensource community support. One of my colleagues clearly said that if he has to choose to work on another UWP project he would choose to not work on it.

[NicoJuicy]

I'm not noticing any performance difference, porting isn't much of a hassle.

I ported some layers of my DDD-webapplication ( huge codebase) to UWP to support Windows RT. So i could re-use my Api Client Connector.

The biggest problem i ran into was with reflection. So i split up one of my nuget package to a UWP-supported DLL and an "extension" dll. Which contained the non UWP/PCL supported methods / functions.

The UWP is used in my Api Connector and the extension dll is widely included into my "web application" + other apps ( import, export, wpf client, website, webapi ...).

The other thing ( not really a problem) was that i dropped support for SilverLight since one of the Nuget DLL's i use, didn't support that. And i don't use SilverLight in the current situation, so the choice was easily made.

Also, PCL requires async methods, so i had to change my Http Calls to support Async and use a different method to call the HTTP ( which really didn't take a long time). But i used a dirty trick to support Async ( eg. an extention method that extends uses my IApiInterface, to convert it to Async :) -- I needed it fast and didn't noticed any downsides till now.

PS. UWP supported dll is called Portable Class Library ( PCL) if you want to look it up.