Why .NET Standard 2.0

There is simply no reason not to be using .NET Standard 2.0 at this point (you can still target 1.4 if you need older UWP support, but just do 2.0!). It supports all of your favorite platforms including every single Xamarin platform, offers 20K+ more APIs than 1.X, and has a 70% API compatibility with NuGet packages today (it will also consume non-.NET Standard libraries in a compat mode). On top of that it is the future! It replaces PCL and Shared Projects (with multi-targeting, which I will save for another blog post) and will make your life as a cross-platform developer much more enjoyable.

Easy as 1,2,3,4 🐒

1. Unload your PCL project (right click -> unload), and start editing it (right -> click edit)
2. Delete Everything in the csproj and insert this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <!--<PackageReference Include="" Version=""/>-->
  </ItemGroup>

</Project>

3. Add back NuGets (simply open packages.config, and add the package references above, or via the NuGet package manager.
4. Delete AssemblyInfo.cs (this is now in the csproj) and packages.config (also in csproj via PackageReference)

That is it! You are done! Welcome to the wonderful world of .NET Standard 2.0! If you had any reference to other projects you will want to add those back in!

So Easy Let Me Show You

That is right, it is so easy that I shot an entire 6 minute video where I do this in real time!

Learn More

To learn more about .NET Standard head over to the documentation and to follow along with my Git commits you can find the source code to the library I converted in the video over on my GitHub.

Additionally, Frank and I discussed .NET Standard on Merge Conflict:

• Merge Conflict 38: One Library to Rule Them All
• Merge Conflict 50: We Have Standards
• Merge Conflict 77: dotnet pack holiday

Here is the easiest example of taking a photo and displaying it in a Xamarin.Forms image.

takePhoto.Clicked += async (sender, args) =>
{
    await CrossMedia.Current.Initialize();

    var file = await CrossMedia.Current.TakePhotoAsync(new StoreCameraMediaOptions
    {
        Directory = "Sample",
        Name = "test.jpg"
    });

    if (file == null)
        return;

    image.Source = ImageSource.FromStream(() =>
    {
        var stream = file.GetStream();
        file.Dispose();
        return stream;
    });
};

Improvements

With this release I really focused on performance, memory optimizations, and adding new features that developers have been asking for. The top of the list has been Image Resizing when taking and picking photos. Now, all you need to do is set the PhotoSize in the Media Options:

PhotoSize = PhotoSize.Medium

This will shrink it in half, or you can simply specify a custom resize ratio:

PhotoSize = PhotoSize.Custom, CustomPhotoSize = 90

Better yet, I have also added a new way of compressing the image quality by just setting another parameter when taking or picking a photo:

CompressionQuality = 92

These can really help when displaying photos to users and when you don’t want a huge 2400x4600 photo saved locally. However, you may want to have the original photo saved to the users gallery, and the Media Plugin has you covered! Simply set:

SaveToAlbum = true

And what do you know the original photo will be saved to the camera roll on each device!

There are a bunch of other new features like specifying cropping on iOS and UWP, new permissions support for iOS 10 and Android N (new fancy File Providers), and even overlay support for iOS:

Optimizations

I have spent a lot of time on optimizing the code especially for Android. This means that photos will be automatically rotated based on Exif information, bitmaps are only loaded into memory when needed for continuous photo taking, and a plethora of other bug fixes that have been reported on the GitHub page. This release also has a nice update to the new Permissions Plugin that you can now get your hands on that has some awesome new features.

I am also really excited for all of the new documentation that I wrote up for this release, documenting just about every feature that I could and even including a lot of nice sample apps in the tests folders to check out.

What’s Next

I would  love to reach a new 3.0 release with some new optimizations including custom photo resizing to a max width and height, but would also love to hear what you want, or is it finally everything that you want :) Let me know on the GitHub Page.

An Easier Way to Develop

Immediately I realized that setting up projects for iOS, iOS Unified, Android, WP, WP RT, Windows Store, and the PCLs was a big pain if you had to do it all manually, so I wanted to solve this. With a bit of hard work and help from @Kzu I was able to introduce brand new Visual Studio templates for creating plugins and nuspecs. This makes it so you are immediately productive with a full project setup so you can start coding.

Vibrate

Have you ever wanted to tap into the vibration feature of your mobile device from a common API? Well here it is, simply call Vibration(int milliseconds); and you are done! Simple and effective.

Device Info

When using Xamarin.Forms I really enjoyed that I could execute specific functionality by checking the platform type from a PCL or shared code. So why shouldn’t you be able to do this normally? Device Info was born and also brought to the table the ability to get firmware version, device model, unique Id, and more.

Image Circle Control Plugin

Next up was something a bit different; a control plugin for Xamarin.Forms. I really like circle images, I mean I really like them a lot. In fact, I keep talking about them on dates that I go on and I even blogged about them over on the Xamarin Blog. So the Image Circle control plugin for Xamarin.Forms was introduced so no one else would ever have to write code to create circle images from scratch.

Connectivity

Creating online/offline mobile apps can be a bit tricky and each platform has a different way of figuring out if the device has connectivity. So instead of writing this code over and over again I decided to take it to the next level and create a connectivity plugin so you could just check to see if there is an internet connection. Even better is that you can subscribe to be notified when your user is disconnected!

Battery Status

This plugin started as a fun little project on my plane ride from Seattle to Austin for the holidays and ended up with me coding, testing, and releasing this plugin on Christmas Day! Check the current batter percentage left, the devices power source, and of course register for notifications when anything changes.

I love plugins for xamarin and they don’t just work on iOS and Android they all work on Windows Phone and most work on Windows Store as well. I hope that everyone will find these useful and inspire you to create your own plugin. If you are interested to see how I created these be sure to see the entire source code on my GitHub!

Happy Holidays!

Component vs. Plugin

For a long time, Xamarin developers have been able to add rich functionality to their mobile applications by adding Components from the Component Store. While you might consider these “plugins” of sorts, let me define what a plugin means to me.

Component When refer to Components, we’re generally talking about a library for Xamarin.iOS or Xamarin.Android that has been packaged for the Xamarin Component Store - similar to how a NuGet is a Library that has been packaged for the NuGet Gallery. Sometimes they have the same API, however sometimes they do not. For instance, Twilio has a great component that has very specific and tight integration with iOS and Android, and requires you to write code in the platform specific project.

Plugin

When I refer to a plugin for Xamarin, I am referring to a special kind of NuGet that adds cross-platform functionality or abstracts platform specific functionality to a common API. These are both completely cross-platform and extremely small (i.e., they do 1 or 2 things really well with minimal to no dependencies). The plugin API can be accessed on each platform; however, most likely you will only use the common API in a Portable Class Library or Shared Code project.

I like to use the name Plugin as it follows the same pattern as MVVMCross. In fact, nearly every single MVVMCross Plugin could be turned into a Plugin for Xamarin & Windows with a small amount of work so any Xamarin developer could take advantage of it.

I created my Vibrate and Settings Plugins specifically to provide simple examples of Plugins for Xamarin & Windows - but another great source for model plugins would be nearly anything that comes from Paul Betts, such as Akavache.

Xamarin.Forms or Xamarin plugin?

If you read my earlier blog post about creating plugins specifically for Xamarin.Forms, you might be wondering if you should create them for only Xamarin.Forms or if you should create a more platform independent Xamarin plugin. This is a great question as well and just remember that any “Xamarin plugin” would work in a Xamarin.Forms project. So, it really only depends on what you are trying to accomplish. If you intend to leverage some of the functionality that is built into Xamarin.Forms, or to create custom controls for Xamarin.Forms, then your plugin should be a “Plugin for Xamarin.Forms”.

If you are not using anything that explicitly depends on Xamarin.Forms, then you should really strive to make it completely platform independent, and leverage the Bait & Switch approach to target iOS, Android, and Windows Platforms. I tend to always attempt to target iOS, Android, and Windows Phone at minimum in all of my plugins to ensure compatibility with Xamarin.Forms.

Naming

After taking a few swings at this, I’ve found that following this naming scheme works pretty well:

• Xamarin.Forms only:
• Feature Plugin for Xamarin.Forms
• Xamarin.iOS/Android/Mac:
• Feature Plugin for Xamarin
• Xamarin + Windows Platforms:
• Feature Plugin for Xamarin and Windows

Replacing “Feature” with what your plugin does :)

If you want to learn more about creating plugins, be sure to check out my full repo on GitHub.

Settings Everywhere

Back in March, I updated my settings plugin to be completely generic from any framework. This means anyone can use it no matter if you are developing with traditional Xamarin, Xamarin.Forms, or MVVMCross. Today, I am pleased to announce a brand new update, 1.4.0.0, that brings a flurry of enhancements and fixes.

Enhancements

Over the last several months I have added support for Windows 8.1 and Windows Phone 8.1 RT development and in this latest version I bring full support for Xamarin.iOS Unified projects.

Simplified API

I have received a lot of feedback over the year on how the API worked. The biggest issue was that I enforced that you first attempt to “Update” the setting and then call “Save” to actually store the value. This is nice if you wanted to do batch saving of settings, however it was very annoying and created extra code. I have listened and created an even easier API:

There you have it, simply get and set from the settings and the library will handle the rest for you.

Data Types

I have also expanded the datatypes that you can store:

• Boolean
• Int32
• Int64
• String
• Single(float)
• Guid
• Double
• Decimal
• DateTime

Bullet Proof

In addition to all of these enhancements I wanted to make sure that going forward anyone would be able to pull down the library, make changes, and do a full regression test. I have built out a full NUnit test library to ensure the highest quality for the library.

Get it today

As always you can get the entire source code on the GitHub project where you can contribute to the project. Additionally, you can get the NuGet today.

Shared Code != Universal App && Shared Code != PCL

So it should be stated that Shared Code projects are not universal apps and they are not PCLs. A Universal App is just a project template for WP8.1 and WinStore 8.1 apps that use a shared code project. The idea of a Universal App is simply that these two platforms have a shared project and maybe they are able to share some of the UI which is XAML (I still have to explore this more). Also, a Shared Code project differs from a PCL because the PCL does not have the ability to call platform specific code without an abstraction layer like the shared code project can. Additionally, they work completely different at Compile vs Deploy time. Remember that PCL’s can compile against a “contract” and implementation, but at build and deploy time the platform specific version will is used. The shared code project is compiling and deploying against what is in each parent project and their references.

So to me this means that a PCL is for library creators and a Shared Code project is for app creators, but an app creator can also live completely in PCL land if they want. I have been and I enjoy it, but I am still constrained to what PCL limits me to, but allows me to easily add platforms in the future without modifying code. So I think I will start more projects with shared code projects in the future.

Get it in VS!

While Miguel tweeted that support for shared code projects will be added to XS in the future if you live 100% of the time in VS then you can get started today with shared code projects. The first thing you need to do is install the shared code project visual studio plugin assuming you already have Visual Studio 2013 Update 2 RC installed.

With that installed we can go ahead and create a new project:

Then you can add in your iOS and Android apps like normal. Once you want to start writing code in your Shared Code Project you will want to add them as a reference to your other projects so you can get intellisense and bring in namespaces.

Once I have added them here you will be able to see the reference in the project references:

What am I coding against?

Shared code project actually have no references… well actually they have every reference of the parent. What is really cool is that you can toggle between each project when you have a file open from the shared code project.

This means you will probably have to do a lot of toggling between everything to make sure it compiles correctly, but it is pretty slick. So now if I wanted to add HttpClient into the mix here I would add the reference to my iOS and Android project like I normally would, and then start writing code in my Shared Code project:

And there you have it, Shared Code projects integrated into Visual Studio for Xamarin projects!

On my GitHub I have started to build out a lot of applications, sometimes using MvvmCross and sometimes not. One of my most starred repos is my MvvmCross plugin for saving settings on Android, iOS, WP, and Win 8. My idea originally was simple: Use the native settings management system across all platforms. This means SharedPreferences, NSUserDefaults, IsolatedStorageSettings, and ApplicationDataContainer. I didn’t want to do anything too crazy to re-invent the wheel, so this means you can only store data values that the platform allows such as:

• Boolean
• Int64
• String
• Single
• DateTime

Doing anything more then this to me means you should use some sort of blob storage such as Akavache. Since my library is very simple this means you can still use a PreferenceActivity on Android to get a nice native settings screen (this was my main motivation really). So it is great that I have MvvmCross support, but what about standard Xamarin projects?

Today, I am pleased to introduce a brand new GitHub repo called “Xam.PCL.Plugins”. This is a repo that is open source and will house all of my PCL NuGet Plugins for cross platform development. To start things off I am introducin my very first plugin, which as you might have guessed is cross platform settings! It is already available on NuGet for your app consumption :)

All you need to do is install the NuGet into both your PCL and client projects and you will be on your way! If you are interested in creating more plugins with me or converting MvvmCross plugins over simply fork my repo and send a pull request. You can use my settings project as an example of how to structure your project to work properly with PCLs. Additionally, PCLStorage is a great repo to also look at for starting development for a more advanced PCL.

One feature in particular was a bit tricky which was that when the app starts up it calls out to a web service to pull down an update notification. I use HttpClient to easily call out with GetStringAsync and then parse the JSON with Json.NET. While this feature seems trivial, you have to remember that a PCL uses just a subset of the .NET Framework and unfortunately when you select Windows Phone System.Net.Http is no longer available. So here is how I went about adding in this functionality.

Create my PCL

From File -> New Project you will want to create a new Portable Class Library. Once you name it you can specify what platforms you want to support in this popup:

Inside of Xamarin Studio it is very similar except that this popup doesn’t exist. You will have to select the Projects options and select the platforms you want to select after the project has been created, which is easy enough:

NuGet to the rescue!

One amazing thing about PCLs is the vast libraries that are available on NuGet. To get started you first need to get the latest NuGet manager for either Visual Studio or Xamarin Studio to consume these NuGets in your app. Once you have this we can simply right click on our References in the PCL and select Manager Nuget Packages. Once the window opens up simply search for Http Client to find the System.NetHttp Nuget:

Awesome! Now we have HttpClient in our PCL and we can use it to make web request…. right?

Not so fast! Troubles in PCL Land

One thing to know about Portable class libraries is that they aren’t like other libraries out there and can bent and twisted to do crazy things. I wont get into the details of how PCLs exactly work as you can read Stephen Cleary’s post on them. I will say is that the NuGet package we just installed has a portable implementation of the HttpClient for platforms that don’t have them built in, such as Windows Phone. We can compile against this “contract” and implementation, but at build and deploy time the platform specific version will be used. This is important because both Xamarin.Android and Xamarin.iOS already have an implementation of System.Net.Http, so to make sure they get used we will want to add the references to those projects from our Add References popup.

On Windows Phone though it is a bit trickier as we need proper async/await support and a few platform specific HttpClient implementations. This is easy to remedy though as all we need to do is add the same NuGet to our Windows Phone projects! Check! Done!

Close to the finish line!

Now ideally at this point we should just be “done” and when I was building out my demo project I thought I was until I ran my app on an iOS device. As you may know that iOS apps are all ahead of time compiled (AOT), which means that if any of your code needs to JIT it simply will not work. For some reason at compile time the facades don’t kick in properly and it tries to use the NuGet version of System.Net.Http which has some specific functionality for older platforms. We simply do not need this, so let’s show MSBuild who the boss is and redirect it to use our DLL that we have already. All you need to do is create a new app.config file in your Android and iOS project. We will then tell the app.config to forcefully use our DLL that we included with this config:

Now we are back on track and everything works properly!

Super charge HttpClient!

Now we could just stop there, but what fun would that be? HttpClient is great, but we can actually improve upon it with using platform specific networking libraries. This is where Paul Betts’ ModernHttpClient Component comes in. He describes it as:

*This library brings the latest platform-specific networking libraries to Xamarin applications via a custom HttpClient handler. Write your app using System.Net.Http, but drop this library in and it will go drastically faster. This is made possible by two native libraries:

On iOS, AFNetworking 1.3.3

On Android, via OkHttp 1.2.1*

So this is fantastic because we don’t actually have to change any of our HttpClient code except for when we create a new one where we can pass in a HttpMessageHandler. So let’s get this puppy installed and super charged!

First off is to install the ModernHttpClient Component in both Android and iOS projects. You can do this by right clicking the components folder and selecting Get More Components. Once the component store comes up simply search for ModernHttpClient and add it to your project:

Alright, now it is time for some platform specific code as we will need a way to get the AFNetworkHandler or OKHttpNetworkHandler in our PCL. To do this we will need a little bit of platform abstraction, so I will create an interface that I will implement on both Android and iOS. The interface is simple as it has one simple getter for a HttpMessageHandler and then simply create the specific handler on each platform:

I have my own IoC container that I use to register these classes in each application’s start up code. Then whenever I need to actually create a new HttpClient I use this simple method to get the correct HttpMessageHandler to pass in to HttpClient’s constructor:

There you have it! HttpClient everywhere and super charged on both Android and iOS with ModernHttpClient. If you happen to be using MvvmCross check out my good friend Tomasz’s GitHub for a nice plugin for ModernHttpClient.

*Note: System.Net.Http relies on Microsoft BLC Build Components NuGet and this is recommended to add to all of your projects that reference the PCL.

It is important to remember that there is nothing special you need to do to get PCL support. If you copied over dlls or added xml files you should remove all of this and just use the Stable branches of Xamarin to get official support.

What is a PCL and what are profiles?

A PCL is a portable class library which is a project template inside of VS and XS which allows you to select platform targets that the project will be compatible with. This is amazing because you have one project that works everywhere. PCLs have actually been around since VS 2010, but they have always been locked into Windows specific platforms, but that all changed last November when Microsoft and Xamarin announced a major partnership which included PCL support for Xamarin.Android and Xamarin.iOS apps. PCLs use these things called “profiles”, which are actually supposed to be hidden from developers, but you will see them everywhere. Profile numbers are a peek into what platforms the PCL supports and how NuGet handles PCL support when installing. There are several parts to a profile such as net45, wp8, and now monotouch and monoandroid. PCLs work a bit interestingly which is that the DLss that are in the .NET subset are actually more like stub methods or interfaces that you are developing against. The DLL that gets used is the DLL that is included in the base project. This still puzzles me a bit and I am not a Microsoft PCL compiler expert like Daniel Plaisted, so you can ask him tons of questions on Twitter.

Tips & Tricks

1. Remember that PCLs are platform independent. Not all APIs will be available to you.

2. Don’t try to put platform specific code in a PCL, that is now what they are for. Abstract all platform specific code with interface that you implement on each platform

3. PCL’s are great for large or small libraries, try to break your project up into small re-usable components. For instance I have a Settings PCL that is cross platform compatible that I reuse on every project. Growing a large PCL is fine, but try to think about how you can reuse code on more projects

4. Choose only the targets you want to support. The more you select the smaller the subset of .NET you will get. If you select Windows Phone which doesn’t have HTTPClient you will not get access to it.

5. Use NuGet to fill in the gaps. If you need to use a specific PCL profile be sure to search NuGet to see if there is something to fill in the missing functionality such as HTTPClient or PCL Storage.

6. Recommendation is to leave out Silverlight and Windows Phone if you are not currently developing for these platforms as they will limite your APIs.

7. This means use Profile 7 or Profile 78 for your projects based on your needs.

Setup

Here is a short guide on how to create your first PCL:

Visual Studio

Inside of Visual Studio it is easy to create a PCL by simply selecting File->New Project -> C# -> Portable Class Library.

When you select this you will see a dialog pop up asking you what platforms you wish to support.

That’s it you are good to go. As you can see they hide the “Profile” from you, but if you expand your References folder and select the .NET Subset DLL you will see in the path a specific profile that you are using.

Xamarin Studio

Similar to Visual Studio you will create a new PCL by selecting File->New Project -> C# -> Portable Library:

Now instead of popping up the target dialog like Visual Studio does you need to actually edit the project properties to specify the correct PCL Profile:

PCL/NuGet Issues

All PCLs and NuGets are not created equal and you will need to do some testing that is for sure. One issue that a lot of people might run into is with Json.NET that has an official Xamarin Component and also an official NuGet as well. While the NuGet does have official support for Xamarin.iOS and Xamarin.Android and issue does comes up if you are using profiles that include .NET 4.5, which is that Json.NET will install a newer version that is including System.Runtime.Dynamic, which is not supported in Xamarin.iOS. This means that that NuGet in general just will not work. There are a few work around for this and I recommend simply installing the Json.NET component in both the Android and iOS project and then manually referencing this DLL (iOS or Android it doesn’t matter) in your PCL. The only thing you will really miss is the DeserializeAsync, which you can create your self easily by wrapping it in a Task. This may change in the future as I have been working with James to get this fixed, but this can be the case with any NuGet out there so be careful.

I hope this helps you get up and running with PCLs. I love PCLs because they are awesome so always feel free to reach out to me on Twitter with questions.

Unable to display content. Adobe Flash is required.

Pre-requisites: I am going to be using VS 2013 and making an Android App based on the Azure sample. You should:

1. Read through the Android Setup Guide for Azure

2. Ensure your Azure Database is setup

3. Ensure your Azure Table named “TodoItem” is setup

Step 1: New PCL

Select new project in VS2013 and select Portable Class Library. Name your solution “TodoList” and your project: “TodoList.Portable”:

When prompted to select targets select: .NET 4.5, Windows Store, Xamarin.Android, Xamarin.iOS. *NOTE: Windows Phone is not supported in the Azure Mobile Services PCL.

Step 2: Add Azure Mobile Services Nuget

UPDATE 12/16 Don’t actually use the nuget file here, we want to actually reference our component directly. There are a few reasons for this after talking with Paul Batum from Microsoft.

You will want to go to the component store and download the azure mobile service: https://components.xamarin.com/view/azure-mobile-services and then reference both “Netonsont.Json.dll” and “Microsoft.WindowsAzure.Mobile.dll”. You could reference these from the download component later on as well.

**Don’t do this:

Next up is to add the AMS nuget. Simply right click on References and click “Manage Nuget Packages”. Search for “Azure Mobile Services” and click Install.

Such as: Install-Package WindowsAzure.MobileServices -ProjectName TodoList.Portable -Version 1.1.0

Step 3: TodoItem + AzureWebService

Next up let’s first delete Class1.cs and create the TodoItem.cs:

Now our AzureWebService.cs will have a helper to “GetTodoItems” and “AddTodoItem”:

Make sure you fill in your specific Azure Settings.

Step 4: Android Project Setup

Next add a new Android ICS Project named “TodoList.Droid”. Once the project is created add a reference to you “TodoList.Portable” project. After that right click on the Components folder and hit “Get More Components”. Search for Azure Mobile Services and hit Add to App.

Step 5: Add in the UI

The next part is to add an EditText and Button to the UI that will add new items. Under it will be a ListView that we will populate with all of our TodoItems.

Step 6: Hook it all up

Last thing is to tie into this UI and the Azure Mobile Services. We will create our adapter and then get the current TodoItems. When our user clicks to add a TodoItem we will send it up to Azure and add it to the UI if successful:

There you have it. The same can be done for Xamarin.iOS as well.

Cheers!

Our team here at Ceton does a bit of cross development on both Mac and on Visual Studio. If you are doing WP or Windows Store apps then this is a must. I prefer to create all of my base solutions and projects inside of VS first. Get some Nugets going with the nuget manager and the most important part is to ENABLE NUGET PACKAGE RESTORE!!! Simply right click on your project and say… Enable Nuget Package Restore. This will allow you to sync up your nugets over on XS.

Alright so let’s say you got all your packages up and running in VS how do you sync them over in Xamarin Studio???

The first thing you will need to do is go into the .nuget folder that VS has created and you will find Nuget.targets. For some reason if you have nugets it will try to auto update them, if this is works for you then great, however XS has ALWAYS thrown an error for me, so I say hey let’s just do it manually. So a bit down you sill see somethign that says “NuGet command” after the platform specific code. Well let’s NOT let this run unless we are on windows so add “ Condition=” ’$(OS)’ == ‘Windows_NT’“ to that Property group

Alright awesome!!

So now you will have to create a script over on your MAC to update your Nugets.. This is kind of a pain but you only have to do it every once in a while.

1.) In terminal go to your_project/.nuget

2.) Make script executable "chmod 755 osxnuget.sh”

3.) Fill in the script: it should be something like this:

mozroots --import --sync
mono --runtime=v4.0.30319 NuGet.exe
mono --runtime=v4.0.30319 NuGet.exe install ../project.core/packages.config -Output ../packages
mono --runtime=v4.0.30319 NuGet.exe install ../project.test/packages.config -Output ../packages
mono --runtime=v4.0.30319 NuGet.exe install ../project.ui.android/packages.config -Output ../packa

4.) Run it with “./osxnuget.sh”

If XS was open simply restart it.

Boom you are good to go again!

So last night at the Xamarin drinkup in Bellevue there was a lot of discussion about PCL and also bout MVVM frameworks such as the one I am using MVVMCross (Mvx). While PCL is “sorta”/“kinda”/“it should just work” on the Xamarin platforms there still seems to be a lot of confusion and a lot of issues setting up. So this morning I am going to do a quick overview of What is PCL, Why you should use PCL and how to get it setup inside of Visual Studio on your PC and also inside of Xamarin Studio on your Mac. I blame this entire article on Frank Krueger so thank him on twitter and buy is amazing apps.

What:

PCL stands for Portable Class Libraries. The whole concept was that different platforms are all crazy with different code such as Xbox, Windows Phone, Silverlight. So why not write a lot of your core logic in a language that any of them can understand. A subset of the full framework that these platforms can consume.

Why:

The what basically summarizes all of this to be honest, but think about writing one core logic for your app with one type of project that anything can consume. No more project or file linking involved, simply add the PCL core project to your client apps and boom tons of functionality for you. Now I wont get into it, but throw in an MVVM framework into this mix and everything should/kind of is amazing. The biggest issue that I have seen from PCL is that not everything supports it, it is only for microsoft platforms, and until recently with .net 4.5 the BCL (which you can look up and I am not going to go into details) weren’t a PCL. However!!! Seeing that Xamarin.iOS and Xamarin.Android allow you to code in C# with the .Net Framework AND that they allow you to use PCL projects…. 1 code base for iOS, Android, Windows Phone, and Windows Store apps.

More Info Before We Begin

Now how PCL stuff works is everything is a Profile. Profiles basically saying hey if you are this profile you can use these dlls. This is nice so PCLs can distinguish between different platforms. I target Profile104. Which allows WP, Windows Store, Android, and iOS apps.

The current issues

I don’t have a 100% work around for getting the BCL nuget package working so async/wait and .net 4.5 will have to wait a bit until Xamarin and Microsoft figure everything out. So for right now I am living in the .net 4.0 world and still loving it.

Visual Studio

My setup is Visual Studio 2012 on Windows 8 Pro with the latest Alpha release of everything Xamarin.

1.) Go to “C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile104\SupportedFrameworks”

2.) Add these 2 xml documents which will allow MonoAndroid and MonoTouch to be targeted PCL platforms.

3.) Optional: you could add these to other platforms as well if needed, i use 104 because it works.

4.) Start up Visual Studio and create a new Portable Class Libary project.

5.) When you see a pop up for platforms simply select:

After that you should be on your way. Create a new iOS app, android app and just add in the project as a reference. If you don’t want to use the xml files there is another way that my good friend Tomasz Cielecki uses which he blogged about.

Mac:

So things are a bit trickier here. My current setup is the latest version of xamarin.studio (alpha), Mac OSX 10.7.5, XCode 4.6.1.

1.) The biggest issue is that the PCL files that Visual Studio references aren’t actually on your mac or installed when you install Xamarin Studio. You can read about the problem here.

2.) So let’s move them over. If you have a PC there is a folder you want to copy which is located at: “C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable”

3.) Copy this entire folder… or download it RIGHT HERE if you don’t have a PC.

4.) You need to copy it over onto your Mac to this directory: /Library/Frameworks/Mono.framework/External/xbuild-framework/

So all together inside of /Library/Frameworks/Mono.framework/External/xbuild-framework/ should be .NetPortable with .Net4.0 and .net4.5 inside and also MonoTouch.

If you are on a linux box you can copy to: $(libdir)/mono/xbuild-framework

5.) Alright so you should be good to go, but you would need to now create a new PCL project in Xamarin Studio. So Create a new Solution

6.) I like to name “MyApp.Core” and the Solution Name “MyApp”

7.) Once the project is created simply Right Click on the Project and go to: Options -> General and select Mono for Android and MonoTouch.

8.) If for some reason this doesn’t stick or tells you that Profile 104 isn’t installed it is lying and you will need to manually modify your .csproj in a text editor and simply ensure these 3 lines are in your main Property Group:

TargetFrameworkVersion: v4.0
TargetFrameworkProfile: Profile104
FileAlignment: 512

**Sorry about the xml tags missing tumblr is weird and I need to fine a better code plugin.

And if for some reason that doesn’t work… just use my pre-made template you can download from HERE.

So I think that just about wraps it up. If you have issues leave a comment, or hit me up on twitter @JamesMontemagno