PCL and .NET NuGet Libraries are now enabled for Xamarin

PCL and .NET NuGet Libraries are now enabled for Xamarin

Rate This
  • Comments 25

Earlier today, Soma announced a collaboration between Microsoft and Xamarin. As you probably know, Xamarin’s Visual Studio extension enables developers to use VS and .NET to extend the reach of their apps across multiple devices, including iOS and Android. As part of that collaboration, today, we are announcing two releases around the .NET portable class libraries (PCLs) that support this collaboration:

Microsoft .NET NuGet Libraries Released

Today we released the following portable libraries with our new license, on NuGet.org:

You can now start using these libraries with Xamarin tools, either directly or as the dependencies of portable libraries that you reference.

We also took the opportunity to apply the same license to Microsoft .NET NuGet libraries, which aren’t fully portable today, like Entity Framework and all of the Microsoft AspNet packages. These libraries target the full .NET Framework, so they’re not intended to be used with Xamarin’s iOS and Android tools (just like they don’t target Windows Phone or Windows Store).

These releases will enable significantly more use of these common libraries across Windows and non-Windows platforms, including in open source projects.

Cross-platform app developers can now use PCL

Portable class libraries are a great option for app developers building for Microsoft platforms in Visual clip_image001Studio, to share key business functionality across Microsoft platforms. Many developers use the PCL technology today, for example, to share app logic across Windows Store and Windows Phone. Today’s announcement enables developers using Xamarin’s tools to share these libraries as well.

In Visual Studio, you’ll continue to use Portable Class Library projects but will be able to reference them from within Xamarin’s tools for VS. That means that you can write rich cross-platform libraries and take advantage of them from all of your .NET apps.

The following image demonstrates an example set of .NET NuGet library references that you can use within one of your portable libraries. The .NET NuGet libraries will enable new scenarios and great new libraries built on top of them.

You can build cross-platform libraries with .NET

This announcement also benefits .NET developers writing reusable and open source libraries. You’ve probably used some of these libraries, for example Json.NET. These developers have been very vocal about wanting this change. This announcement greatly benefits those library developers, enabling them to leverage our portable libraries in their libraries.

Getting started with portable libraries and Xamarin

You can start by building portable libraries in Visual Studio, as you can see in the screenshot above. You can take advantage of the portable libraries that we released today. Write code!

You’ll need an updated NuGet client, to take advantage of this new scenario. Make sure that you are using NuGet 2.7.2 or higher, or just download the latest NuGet for your VS version from the Installing NuGet page.

We are working closely with Xamarin to ensure that our NuGet libraries work well with Xamarin tools, as well as PCL generally. Please tell us if you find any issues. We’ll get them resolved and post them to our known issues page.

Thank You

Thank you for the feedback on UserVoice. With today’s announcement, we can mark the request to Remove the platform restriction on Microsoft NuGet packages as complete. Thanks to Phil Haack for filing the issue. Coupled with our collaboration with Xamarin, .NET developers have some compelling tools, especially for targeting mobile devices.

Both Microsoft and Xamarin want to see this scenario succeed. We’d love your feedback. Please tell us how the new features are working for you.

This post was written by Rich Lander, a Program Manager on the .NET Team.

Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • wow, it's a great news since we haven't had to use trick any more :)

  • Does this mean the portable Reactive Extensions build will work now? :)

  • Awesome! This makes cross-platform development really efficient, particularly when coupled with Xamarin and Intersoft Crosslight which have been long built upon PCL enabling code reuse on iOS, Android, WP8 and Win8.

    Keep up the good works guys!

  • cool, thanks

    I also noticed .NET 4.5.1 for Windows 7 (hope for Windows Server 2008 R2 too) that if I got it well allows one to build for Windows Store apps on Win7

    what you should also do though is stop breaking Windows Phone 7.x projects (even 7.5 ones) by upgrading them to WP8 automatically when opened in VS2013. That forces one to keep on using VS2010 or VS2012 too in parallel with VS2013 or stick to older versions of Visual Studio in order to support Windows Phone 7.5+ (else do backwards upgrade on Windows Phones to make them WP8-compatible or something)

  • I cannot use SignalR with a Xamarin profile 158. SignalR's target is win+sl50+wp80+net45 and my Xamarin 158 adds MonoAndroid10+MonoTouch10. I get this error:

    Could not install package 'Microsoft.AspNet.SignalR.Client 2.0.0'. You are trying to install this package into a project that targets 'portable-win+net45+sl50+wp80+MonoAndroid10+MonoTouch10', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

    Any workarounds or tips?

  • @tim: It looks like you need to update NuGet to version 2.7.2 or higher.  See this link for information on how to do so: docs.nuget.org/.../installing-nuget

    Daniel Plaisted, MSFT

  • Great

  • Good News !!!!

  • I do not know why, but httpclient manipulates my headers.

                   loginContent.Headers.Clear();

                   loginContent.Headers.TryAddWithoutValidation("Content-Type", "text/xml;charset=UTF-8"); -> it inserts space after semicolumn. Why???

  • @Vincenzo: HttpClient parses all headers for acceptable values based on the header name then re-serializes to string.  As a side effect it introduces whitespace, which is consistent with the definition of the Content-Type header field www.w3.org/.../rfc2616-sec14.html.  

Page 2 of 2 (25 items) 12