Forum Xamarin.Forms

The case for .NET Standard in favour of shared project for Xamarin.Forms

bradmbradm AUMember ✭✭✭

There is a bunch of information online about using .NET Standard for your Xamarin.Forms app, but I'm still confused as to why you would want to use one over the other. The main sources I have read through/watched:
1. Sharing Code Overview (MS docs)
2. .NET Standard 2.0 Support in Xamarin.Forms
3. .NET Standard and Xamarin.Forms for the .NET Developer

My history is I've been a Xamarin developer since the Novell days. Since the introduction of Xamarin.Forms (1.5ish?) I've always used it for creating apps over Xamarin.iOS and Xamarin.Android directly. I've never created a Forms app with PCL, always shared library. One thing I've relied heavily on is the ability to just go:

#if __IOS__
    UIApplication.SharedApplication.StatusBarHidden = true;
#elif __ANDROID__
    // Other things.

Being able to do this in the Forms code directly has made things nice and easy. Another example I have used it is in in my own HTTP REST classes, and the ability to use cookie containers in certain ways that would work on both platforms (bugs that may have been resolved now). I now know that in the first example I could create a dependency service called StatusBarActions or something. The second example I know now not to re-invent the wheel and I could just use RestSharp. It's just that one of the listed benefits of using shared code is the ability to use those pre-processor directives.

Likewise two of the main pros of .NET Standard are "Allows you to share code across multiple projects." and "Refactoring operations always update all affected references.". But wouldn't this still be true for a shared Forms app?

Lately I was playing around with converting some smaller in progress apps to be .NET Standard Forms apps. I really enjoy the simplicity of having my main NuGet packages (Xamarin.Essentials, Json.NET, FFImageLoading, sqlite-net-pcl, etc) in the Forms project itself. Its really nice to be able to update all packages at once. The package list also stays nice and short, although I think that's more to do that it doesn't list all package dependencies as new packages. I also liked that it forced me to write cleaner code. Things were good... until I tried Xamarin.Forms on macOS.

Although it is still in preview one of the first things I found that out of the box Xamarin.Essentials was not having a bar of it. It's just one of many packages that may not be supported. It made me think of another project I am working on, Onewheel Community Edition App. It relies heavily on the Plugin.BLE NuGet package that doesn't support macOS or UWP. If I wanted to add either of those platforms I now have to add it via a dependency service or something similar. Alternatively if I used a shared project I could just have a

#if __IOS__ OR __ANDROID__ etc. 

I can see both being possible. One makes it easier when a core component is platform specific, but can also make it more of a pain in the case of Xamarin.Essentials when you may just want to use it to display the app version number.

So the real things I want to know are:

  • Is it worth it?
  • Are there any performance benefits of either?
  • Are there binary size or binary security differences that are worth noting.

What are other peoples experience with it shared vs .NET Standard. Are there some other programming paradigms that I am not thinking of to make .NET Standard apps make more sense?


  • NMackayNMackay GBInsider, University admin

    This article sums it up, both approaches are valid.

    I personally hate shared, compiler directives get out of control quickly and really, it makes sense to some but certainly I've never used Shared on commercial projects where there's a team.

    .NETSTandard keeps a nice clean SOC between what specifically will work on all sorted platforms and using DI to get at custom platform specific code.

    I won't knock anyone for using Shared, I just rarely see it been used in community blog posts etc.

  • ShantimohanElchuriShantimohanElchuri USMember ✭✭✭✭✭

    Even I didn't like Shared projects first, it limits the shared code to business logic and not to GUI and second, as @NMackay said, the assembly directives are messy.

    Even I was checking Xamarin since Novel days but real boos came in 2014 when Xamarin Forms was introduced. The massive interest can be measured by one incident: During Evolve 2014 Xamarin Forms session by Smith seen overflow of the conference room.

    Yes, I see PCL and now .NET Standard is more popular with XF devs.

  • bradmbradm AUMember ✭✭✭

    I really want to like .NET Standard apps. Im re-building one of my older apps over the Christmas break to be .NET Standard from the get go. I love the idea of cleaner code. I was hoping there was just some nice performance boosts or smaller file size you could have from using .NET Standard XF app.

    Via Twitter James Montemagno mentioned how a .NET Standard app has improved build times, so that's a plus I guess.

  • bradmbradm AUMember ✭✭✭

    This topic made it into the Merge Conflict podcast episode 130, 9 minutes in.

  • BobWhittenBobWhitten USMember ✭✭
    edited February 2019

    I've been using Shared Project with some success, and I have often avoided the #if directives by using partial classes for those things that platform specific.

    For example, I have a Util class that has SoundAlert() method to make some indication of completion. These sounds are specific for the platform for each kind of alert.

    For each platform I have the partial class Util implementing platform-specifics. My SoundAlert() method just calls a partial method SoundAlertPlat(), which is different for each platfrom.

    This has some drawbacks, of course, but it seems to have worked for me, including some difficult Bluetooth LE code.

    I am curious what others think about this approach.

  • bradmbradm AUMember ✭✭✭
    I think it makes sense, and it would make it much easier to push your project to a .NET Standard one in future if you ever made that change.

    After making .NET Standard apps since this post I’ve corne to really like them. I don’t feel there is any performance improvement in terms of size and speed of the app. But having to write and look at cleaner code is always a plus.
Sign In or Register to comment.