Forum Cross Platform with Xamarin


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

Understanding Code Sharing Options

CodeMonkeyCodeMonkey GBMember ✭✭✭
edited October 2012 in Cross Platform with Xamarin

Hi all

I have just finished reading the Xamarin 'Code Sharing Options' document and wanted to clarify something:

In all of the code sharing options, you end up with one core library, and then 1..* copies of the library for each of your targeted platforms.

Is the main reason for this so that you can use conditional compilation within the core library to provide different functionality for the different platforms?

If that is the primary reason, could I use one library reference for all projects if I know their will be no need for any conditional compilation?

Note I have only spent the morning going over some of the cross platform concepts so may have missed something obvious. I just couldn't find any other obvious reasons for why a copy of the core library was needed for each platform/project.



  • gshacklesgshackles USInsider, University, Developer Group Leader ✭✭

    It depends on how you define "needed", but in my experience it's a very good idea and helps avoid many potential problems. Since each platform exposes it's own "profile" (its subset of the .NET framework) there's no guarantee that code referenced in a class library compiled against a different profile will be present in the one you're targeting. If/when you hit such a piece of code, your app will crash since it won't know where to find the class or method you're looking for.

    Linking the source files into different class libraries helps avoid this problem, since you'll know right at compilation whether you're referencing something that isn't supported by a particular profile. Sure, technically if you know you're not referencing anything that will cause problems you might be able to run ahead without this safeguard, but in my experience it's not worth the risk since software tends to change over time.

    Conditional compilation is simply a technique you can use to share code/files across projects when using this approach, but not the reason for taking this approach. There are many other techniques for facilitating code sharing as well, such as abstraction, the observer pattern, partial classes, etc. Here's another thread in this forum with good conversation about Portable Class Libraries as well, so I'd also recommend reading through that if you wanted an option that would let you avoid linking the files into separate class libraries.

    I also did a Xaminar some months back on the topic, which might help you get started as well.

  • For my stuff, not so much a "copy" as different .csproj files so that each can have different #defines, reference different assemblies/projects as necessary, etc. Also some projects might include an extra .cs file or two that the other does not.

    For example:

    FooBar.MA.csproj   [ Mono for Android ]
    FooBar.MT.csproj   [ MonoTouch ]
    FooBar.Mono.csproj [ Server ]

    Even though many of my libraries are 100% cross-platform, I still have created unique csprojs for each platform to avoid profile issues Greg mentions.

    The only hassle is having to do a "show all files, include to project" when you add a file to one csproj and then need to sync the others.

  • BryanCostanichBryanCostanich USMember, Xamarin Team Xamurai

    @CodeMonkey, if you use the options there, you never actually wind up with copies per sé, but rather linked files, which point back to the original.

    As @GShackles pointed out, the reason for the separate projects or linking, is because if you create a Xamarin.iOS (MonoTouch) C# library and then try to include it in a Xamarin.Android (Mono for Android) project, it won't work. They have different .net profiles, just as how you can't use a standard windows .net library in a silverlight project (different MSCorelibs). We're working on solving this long term, but for now, you either have to link, or use the Portable Class Libraries.

    Portable Class Libraries aren't in that doc because at the time it was written, it wasn't quite available, and was pretty buggy. We now have pseudo support for them, to this scenario in action, check out @ConceptDev's port of TaskyPro @ TaskyProPortable.

    We don't generally recommend this approach for a number of reasons, which was also another reason we didn't push to try and include it in that doc. For more information, check out the discussion on it here:

  • NicWiseNicWise NZMember, Insider, Beta mod

    @t9mike quick gotcha that kicked my backside yesterday:

    If you make the MyLib.MA.csproj from MyLib.csproj, DONT just copy the file off and rename it. Make a whole new MfA (or MT) library, and then add the files. Otherwise, you may end up with this:

  • @nicwise said:

    If you make the MyLib.MA.csproj from MyLib.csproj, DONT just copy the file off and rename it. Make a whole new MfA (or MT) library, and then add the files

    Yup, I do new library project for the target platform. I also redefine the bin directories to be different for each platform (see below).

    But I can still run into issues when switching between platform solutions since there is a common obj folder for Release and Debug builds in MD.

    Perhaps I'm just "doing it all wrong," but I'd like to see configurable obj directories or have them use same name as output path trailing directory.

    Here is how I remove obj folders if I ever see things getting out of wack:

    find top-dir -name obj -type d -print0 | xargs -0 rm -rv
  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    Thanks for all the info guys!

    I spent today going through the MWC core library and applying the same framework to the app I am working on, it's slowly starting to make sense! I haven't yet tried calling my library from an IOS app, but I have to learn xCode before I do that..

  • NicWiseNicWise NZMember, Insider, Beta mod


    I hadn't thought about the obj folder. that might be whats causing me a few issues. :)

    thanks for the heads up.

  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    I've started up my shiny new mac this morning and started exploring MonoDevelop and Interface Builder, liking it so far (although I'm not a mac person).

    One question, I have my app.corelibrary project which is a C# class library, I am using the File linking method to implement my code sharing so what I am trying to do now is create my app.ios.coreLibrary.linked project but I'm not sure what project type this should be? I created it as a C# class library but I can't reference it from my IOS app project.

  • StuartLodgeStuartLodge USBeta ✭✭✭

    Sounds like you should be able to reference it.

    If all else fails, one thing you can do is open up the .csproj file in textedit/notepad/vi/whatever and compare it to the .csproj of a working core project - e.g. - the important bit is normally the GUIDs inside

  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    I'm selecting 'Edit References' and then selecting the project tab which is displaying the various projects in my solution, but I don't see any dll's to reference. Maybe I need to browse to the actual debug folder and access the DLL that way?

  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    Ok, It was what I thought, the References menu doesn't seem to show dll's from the other projects in your solution, you have to browse to the bin folder and add it that way.

  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    Still think my project type for my ios linked files is wrong. If I look at the properties for the MWC IOS linked project it states a target framework of 'MonoForIphone', but I don't see that option when I look at the properties of my project. It say 'Mono/.NET4.0'.

  • CodeMonkeyCodeMonkey GBMember ✭✭✭

    I solved this project type issue by copying the ProjectTypeGuids from the MWC app into my csproj file, but would like to know what project type we should be using, it doesn't mention in any of the guides I've read.

  • gshacklesgshackles USInsider, University, Developer Group Leader ✭✭

    For the MonoTouch version you'll need to create a MonoTouch Class Library project instead of the normal .NET Class Library one you're using. This will make sure the code gets compiled against the proper profile, and will also allow you to reference the project from a MonoTouch app.

Sign In or Register to comment.