Implementing common control library for both the WPF and UWP version of an application
-
Hello, this might not be a real question, more like an interest about, how bad my current workaround is. I hope it's OK to post here :) . I have an application which I have started developing for WPF and now I also want to port it to UWP. I have created some custom visual controls for the app in a Controls library, which is a Class Library in C# and references .Net WPF libraries. Some custom panels would look very similar with code working in both frameworks, so I thought it would be nice to reuse my old code. This is the solution I came up and currently porting the library to: - left the original Controls class library project untouched - created a Controls.UWP class library for UWP platform - added source files from Controls to Controls.UWP as linked files - finally - and currently working on - resolving the namespace changes by adding stuff like this at the beginning of source files:
#if WINDOWS_UWP
using Windows.Foundation;
#else
using System.Windows;
#endifHowever, in some cases I must completely rewrite the class eg. because I used OnRender function to draw it, so now I have to rewrite it to use Win2D. For this reason I don't know if it's worth bother with #if statements. What do you think, is this a bad idea?
-
Hello, this might not be a real question, more like an interest about, how bad my current workaround is. I hope it's OK to post here :) . I have an application which I have started developing for WPF and now I also want to port it to UWP. I have created some custom visual controls for the app in a Controls library, which is a Class Library in C# and references .Net WPF libraries. Some custom panels would look very similar with code working in both frameworks, so I thought it would be nice to reuse my old code. This is the solution I came up and currently porting the library to: - left the original Controls class library project untouched - created a Controls.UWP class library for UWP platform - added source files from Controls to Controls.UWP as linked files - finally - and currently working on - resolving the namespace changes by adding stuff like this at the beginning of source files:
#if WINDOWS_UWP
using Windows.Foundation;
#else
using System.Windows;
#endifHowever, in some cases I must completely rewrite the class eg. because I used OnRender function to draw it, so now I have to rewrite it to use Win2D. For this reason I don't know if it's worth bother with #if statements. What do you think, is this a bad idea?
How I would tend to do this is put common code inside a PCL which can be used by both sides. Then all you have to do is write your platform specific code and call the shared functionality.
This space for rent
-
How I would tend to do this is put common code inside a PCL which can be used by both sides. Then all you have to do is write your platform specific code and call the shared functionality.
This space for rent
Thank you for the reply! Then I guess, I wanted to create a monster with platform specific code (the UI controls) for two frameworks in common source files. I have already used PCL, that's why I thought it would be nice to have something similar for UI, too. Also, since my post I found other issues, like the missing
FrameworkPropertyMetadata
from UWP and more restricted attached property accessors. So, it seems, that I couldn't save anyway as much code-rewriting as I wanted :( . -
Thank you for the reply! Then I guess, I wanted to create a monster with platform specific code (the UI controls) for two frameworks in common source files. I have already used PCL, that's why I thought it would be nice to have something similar for UI, too. Also, since my post I found other issues, like the missing
FrameworkPropertyMetadata
from UWP and more restricted attached property accessors. So, it seems, that I couldn't save anyway as much code-rewriting as I wanted :( .The biggest problem you will face is that, despite appearances, WPF and UWA are two vastly different beasts. Universal Windows programs are a lot closer to Silverlight, so there are things that you can do in WPF that just aren't available in WPF (and vice versa). This would have a fundamental impact on things such as what your XAML does, which would be a major pain to work around.
This space for rent