Forum Xamarin.Forms

Why Shared Projects?



  • TedRogersTedRogers USMember ✭✭✭✭

    Hey all, I know this thread is a bit old but was considering this recently. I am using a Shared Project but interested in exploring using PCL.

    How would you implement the equivalent in the iOS Build settings for "HttpClient implementation" and "SSL/TLS implementation"? Sorta pretty easy putting all web request code in a Shared Project and building with these settings.

    See attached:

  • TedRogersTedRogers USMember ✭✭✭✭

    Ok, I have answered my own question. The solution is to inject an NSUrlMessageHandler into whatever object in the PCL creates the HttpClient.

  • TheosTheos NLBeta ✭✭

    I just noticed that when I create a new XF project, it uses Shared by default, and I don't have the option anymore to select Shared or PCL like we had before.
    I'm using the latest beta-channel release.

    Xamarin is now heading to Shared?

  • NMackayNMackay GBInsider, University mod


    Noticed that too, guessing it's a bug.

  • TheosTheos NLBeta ✭✭

    @NMackay said:

    Noticed that too, guessing it's a bug.

    Thanks for your confirm, guess so. In the preview, while creating the new project, it mentions that it will be a .csproj, but finally it's an .shproj
    Will search if it's already reported.

  • NMackayNMackay GBInsider, University mod


    I hope it's a bug, I don't like the shared approach and would stop using the product if we were forced down that path as it stands.

  • ReijnnReijnn USMember ✭✭

    Doesn't seem to be a bug.
    Take a look at this thread:

  • NMackayNMackay GBInsider, University mod


    Thanks for the heads up, honestly I despair.

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    Yes, it seems a unexpected decision, without notice

  • NMackayNMackay GBInsider, University mod

    Shared sucks.

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    @DavidOrtinau have you more accurate and up to date news?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @NMackay I like shared. :)

    @AlessandroCaliaro I'll get a current status on it this morning. I'm hearing conflicting news and don't want to speak too soon.

    Regardless of the PCL option visibility on the File > New template, PCL is supported and available.

    I'm curious, when a change like this is being entertained, how would you expect/desire notice to be given?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    I'm reading that based on feedback the PCL option is being put back in the templates for the next RC.

  • NMackayNMackay GBInsider, University mod
    edited February 2017


    I don't like shared :smile:

    I know PCL is still supported but our lives are been made more difficult for no apparent benefit, I know Miquel preferes Shared but we're the customers :neutral: It's an inconvenience.

    Classic example was Android certification change, while the change was for the better in the long run our certificates had the same alias which caused all sorts of issues, we ended up having to push out new signed apps via Hockeyapp which meant users having to uninstall etc and losing local preferences etc, had we known via some sort of communication about new features we'd have flagged up me needed an extra field of something to tag our certificates with a friendly name. It's sorted now but it was a breaking change.

    There's no thought into apps that have been in development for many years when new VS cycles come out, as long as the new features sort of work it's all good, the cycle updates invariably break legacy projects and require manual hacking of csproj fies etc to see what changes have broken the project, there was an example of this recently with AppCompat having an issue on older droid projects. Breaking changes is still my biggest pain point to the degree I only test cycle updates at home now and even that's a pain as my uni dev environment has been broken a few time trying to get Cycle 9 beta tested.

    A least some more indepth "What's new" on a blog/newsletter of significant changes (screenshots) in the tooling would be good rather than a list of bug fixes and a one line description that sneaks the change in.

    My comments above relate to the IDE integration in Visual Studio and living with Xamarin Forms projects rather than communicating changes in The Forms framework which isn't an issue now thanks to your efforts and Bryan before. There's some really basic stuff still broken in the VS integration 2 years on, you just learn to work round it.

    Hopefully someone see's sense on this one.

  • RyanDixonRyanDixon USMember ✭✭✭

    The only time I consider using Shared Projects is when there is a lot of native code across Windows based platforms as that way you end up reducing the amount of repeated code across say UWP, WinRT and WinRT Phone.
    I see a lot of plugins doing the same thing as well...

    Other than that though, 100% agree that PCLs are the way forward, at least until netstandard becomes a bigger deal.

  • PierceBogganPierceBoggan USForum Administrator, Xamarin Team, Developer Group Leader Xamurai
    edited February 2017

    @Theos @AlessandroCaliaro @NMackay @RyanDixon: As @DavidOrtinau said, this should be added back for all cross-platform templates in an upcoming release. At some point in the near future, we should probably discuss adding netstandard as a code sharing option, but I'll leave that for another day. :smile:

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    Thanks @Theos and @NMackay - I thought it was a bug too, glad you guys followed up on it. PCL all the way here. Never ran into a shared project in production in the 2.5 yrs I have been developing forms. No developer I have worked with starts a shared project. Could just be the circles I run in though. :)

  • JohnHardmanJohnHardman GBUniversity mod

    I normally use PCLs, but as per @RyanDixon have been known to put code common to different Windows platforms into shared projects.

    Frustratingly, I've just had to take this a stage further to cope with Xamarin.Auth. I have my own code wrapping Xamarin.Auth, with that code portable across the target platforms. Until today, I'd had that code in a PCL. However, to cope with releases of Xamarin.Auth not always handling all platforms consistently, I found myself needing a way to have one version being used for UWP (I'll check WinRT later) and a different version being used for Android and iOS. To do this, I basically stripped all Xamarin.Auth code out of the common PCLs, and put it instead into a shared project., with that shared project being referenced by my platform-specific projects. The platform-specific projects then use different versions of the Xamarin.Auth NuGet package, and the shared project ends up using the right one for the platform. A lot of re-factoring, but seems to be the best way of coping with Xamarin.Auth's release process.

    Tagging @AdamP in case it's worth an update at

  • AndrewzAndrewz USMember ✭✭
    edited March 2017

    Since many people use PCL, more than Shared I think, why not include PCL from start? Why make PCL a 2nd citizen?
    Can someone please confirm Visual Studio 2017 RTM has PCL?

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    It's an old discussion... I like PCL and I have never used Shared, but I suspect the trend will be Shared in the future.

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @Andrewz - VS 2017, its now moving to .NET Standard, but PCL is still supported. .NET Standard is basically just the next version of PCL.

    @AlessandroCaliaro - I actually think that .NET Standard/PCL will continue to be used by a large number of developers. Just because Miguel and others on the Xamarin team use shared, doesn't mean they set the trend.

    I have found that people who started pre Xamarin Forms, tend to think of Xamarin Forms as a way to share code between platforms, whereas people who started after tend to think of Xamarin Forms as a platform that is converted to native, and this helps set the tone on how they view a project.

    In the last ~2.5yrs in the enterprise / medium-large business, not once have I ever started or come on board an already started project, that used shared. No Xamarin Developer I have ever worked with ever mentions it. PCL/.NET Standard is just the default in this world and rightly so :)

    I actually don't even think Xamarin Team members who provide the shared code samples have ever worked on a large enough project in Xamarin to see where Shared breaks down and all the benefits of PCL/.NET Standard become very apparent. On this point, it is where I think the Xamarin team lost touch with that user base.

    I'm not sure if this is like another "XF isn't meant to be used for complex applications" point they made long ago, and the community just rejected that statement. Xamarin eventually came around :)

  • HaithamhajHaithamhaj USMember ✭✭

    @AdamP said:
    I was thinking maybe I had been too harsh on Shared Projects and they might have their merits in certain use cases. Then I came across this:

    Is this really the recommended way to implement SQLite on a SharedProject? Because it uses a lot of ifdefs and you have to copy and paste code rather than using a NuGet package.

    Or is there be a better way to implement that with SharedProjects? (I am genuinely asking out of curiosity)

    That current example stands as some of the main reasons I would never use a SharedProject.

    AdamP, I am working with PCL, but I facing some issues because I need to use some DLLs that are only targetting Android and IOS so I can't refrence these libraries from my PCL. I need to use some classes from these DLLs. The only way I am seeing is to use the shared project instead of PCL. IS there another way?

  • AdamPAdamP AUUniversity ✭✭✭✭✭
  • HaithamhajHaithamhaj USMember ✭✭
    edited April 2017

    I know DI, but the return type is not defined in PCL, so how to use the return type.
    ex. I want to call a function that return a list of contacts so the contact type should be defined in PCL or what??
    public class Contact
    public Contact();

        public IEnumerable<Note> Notes { get; set; }
        public IEnumerable<Organization> Organizations { get; set; }
        public IEnumerable<Website> Websites { get; set; }
        public IEnumerable<InstantMessagingAccount> InstantMessagingAccounts { get; set; }
        public IEnumerable<Address> Addresses { get; set; }
        public IEnumerable<Relationship> Relationships { get; set; }
        public string Suffix { get; set; }
        public string Nickname { get; set; }
        public string LastName { get; set; }
        public string MiddleName { get; set; }
        public string FirstName { get; set; }
        public string Prefix { get; set; }
        public string DisplayName { get; set; }
        public bool IsAggregate { get; }
        public string Id { get; }
        public IEnumerable<Email> Emails { get; set; }
        public IEnumerable<Phone> Phones { get; set; }
        public Bitmap GetThumbnail();
        public Task<MediaFile> SaveThumbnailAsync(string path);
  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @Haithamhaj - You need to define an abstraction in your PCL. Then map the data to this abstraction, when passing to your PCL.

  • HugoLogmans_HugoLogmans_ NLMember ✭✭✭

    One reason to force stick to SharedProjects is to make the work of package designers easier. If you don't want to use the Xamarin Forms Resolver (as it's an antipattern) and want to instantiate platform dependent classes from the PCL, you need to create a bait-and-switch package. And that introduces complexity in the package (building the empty PCL classes) AND in the usage (making sure the package version is exactly the same for all platforms). IoC solves this problem well, but people find it hard to understand.

    Of course, this only counts if ALL developers start using shared project packages (by removing the option in the new project wizard). And I really hope they won't do that :)

  • rogiheerogihee NLMember ✭✭✭

    I use Shared Projects for main core apps, IMHO PCL's are meant for shareable nuget libraries, not as the "main" core app lib. I never use platform #ifdefs.

    In the end I would much favor a netstandard approach, but then a 2.0 version where you don't miss half the API of .Net.

Sign In or Register to comment.