Limitations of Portable projects vs. Shared projects RRS feed

  • Question

  • User9567 posted

    I suppose using Shared template gives more flexibility because the code in the shared project can contain platform-specific parts switched by compile-time directives. But for the same reason (platform-specific #if directives) I find PCL approach cleaner. When it works. I'd like to know from those who tried both, what do you prefer? When do you use each of them?


    Thursday, May 29, 2014 8:13 PM

All replies

  • User39542 posted

    Great question - and one I suspect will have many opinions :-)

    My personal preference is to use PCLs. It forces me to think about what I can share and what I cannot, and it allows me to unit test the PCL logic - I can't do that with a Shared Project (without hosting it somewhere else).

    But, it really kind of depends on what you plan to do with the code. If it's just for a single app, and you have a small team (or even just one developer), then Shared Projects are more versatile and will allow you to add platform-specific features much easier.

    However, because of that versatility, it also makes it really easy to produce hard-to-maintain code that has subtle bugs due to conditional compilation - particularly once you try to use it cross-application. You can use partial classes/methods to avoid this, but it's not enforced and you won't know it's broken until you try to compile/test it for each app.

    Thursday, May 29, 2014 8:19 PM
  • User9567 posted

    Thanks for the quick response and great answer. I share your view on advantages of PCLs when it comes to better code partitioning. But have you experienced situations when you had to switch from PCL to Shared projects because you couldn't achieve certain goals using PCLs?

    Thursday, May 29, 2014 8:46 PM
  • User352 posted

    Xamarin.Forms is (obviously) written without any shared projects. I believe most any issue with PCL can be resolved with good dependency injection and proper architectural design. Though if you need to interop with a LOT of third party libraries, you might end up writing a lot of wrappers to do that. I think this is where Shared Projects can really shine!

    Thursday, May 29, 2014 8:48 PM
  • User9567 posted

    Thanks Jason! That sounds promising.

    Thursday, May 29, 2014 8:50 PM
  • User11072 posted

    Personally I prefer shared projects which are really just an easier way to do code linking. Yes with PCLs you can get around platform specific limitations with DI but that adds more complexity to your application and you have to pay attention to what PCLs you can reference from your PCL. Granted an overuse of #ifs in your shared projects leads to hard to read/maintain code so you have to be careful there too.

    If you do PCLs you will have trouble referencing other assemblies, particularly non-PCLs. With shared projects you will have a lot easier time referring other projects that may only have native versions of the platforms you need but no PCL but in so doing PCLs won't easily be able to use your native assemblies (without using DI or similar).

    As others have indicated I don't think there is a clear one size fits all choice here and which to use would seem to depend on the situation and team.

    Monday, June 2, 2014 9:11 PM
  • User208550 posted

    I've read some pretty good answers here, but didn't see anything (maybe I missed it) regarding app performance and file size. Does shared vs PCL impact performance or file size one way or another? Thanks in advance.

    Thursday, March 31, 2016 12:05 AM
  • User76916 posted

    @Kon_ - In most applications or with proper design a shared project vs PCL won't see any significant difference in performance or file size.

    Using a lot of PCL libraries might add a slight increase in size over a shared project but again nothing significant since you would have to write native code for each function anyway.

    And if you are calling your DI Framework hundreds of thousands of times then that would cause a perf decrease but if you are in that situation I think the architecture of the app would be incorrect.

    Also this forum post went through PCL vs Shared a bit more: http://forums.xamarin.com/discussion/59381/why-shared-projects/

    Thursday, March 31, 2016 12:29 AM
  • User179286 posted

    Just to add, that at the Moment XF with Xaml does not work for UWP with shared projects. I started with a shared project but changed it to a PCL without any problems.

    @AdamP correct me, but if I store the Interface Reference I get from DI in my PCL there shouldn't be any performance drawbacks.

    Thursday, March 31, 2016 1:38 PM
  • User76916 posted

    @ThomasBurkhart - thats right, you wouldn't get any performance penalty if you stored the reference there.

    Thursday, March 31, 2016 10:31 PM
  • User145607 posted

    which category, PCL or shared project does xamarin form belong to ? thanks

    Tuesday, May 24, 2016 3:42 PM
  • User179286 posted

    @jeffchen2002 You can built Xamarin Form projects as PCL or as Shared projects. But PCL is recommended

    Tuesday, May 24, 2016 9:15 PM
  • User243799 posted

    after creating the pcl, my InitializeComponent(); is not recoginized. but it is compiled.

    public partial class Page1 : ContentPage { public Page1() { InitializeComponent(); } }

    Thursday, July 21, 2016 5:14 PM
  • User260026 posted

    @AdamP My Release android apk is huge 57mb. Im using XF shared proj with sdk and user assemblies link option on. another app using PCL XF and lot of images and audio is 35 mb. my shared app has mono.android.dll of 22 mb while other one is of 1.6 MB. Im gettin response that its bcoz Im using shared proj but Im asking you since you say there shouldn't be any file size diff between shared and PCL.

    Tuesday, October 24, 2017 8:07 PM
  • User76916 posted

    @PrasanjitBiswas - I just did a quick test. I standard PCL or Shared project, both produce an APK of about 17MB, only a 10Kb difference. You must be adding or doing more with your Shared Project, to increase the size. Maybe you have selected multiple architectures for that project? Mono.Android should be about ~1.4MB.

    Wednesday, October 25, 2017 1:17 AM