Scott Hanselman

Portable Class Libraries just got REALLY useful with new licensing changes

November 14, 2013 Comment on this post [16] Posted in ASP.NET | Open Source
Sponsored By
Flickr Photo by thienzieyung used under Creative Commons

It takes a little while to turn a large ship. I love the .NET community and I'm happy to have been a part of it from the beginning. I'm also happy that I'm helping (in a small way) turn the ship from the engine room along with a lot of like-minded individuals.

Sometimes what seems like a "can't you just" request requires days and weeks of legal this-and-that and meetings and "alignment" (that's a thing business people LOVE to say). But if you're patient and keep pushing, change happens.

You have have noticed on the .NET Blog this week that Portable Class Libraries are now enabled for Xamarin. You perhaps remember this post on Portable Class Libraries that I wrote, with this screenshot:


Today on 2013 with Xamarin installed, I see this after File | New Project.


Of course, there's still wasted space, but I hope you can see the change. ;) The more interesting,  perhaps, change is the legal licensing changes to make sure you're allowed to use useful Portable Libraries on other platforms, like Xamarin.

In my original post there were negative (and these discussions continued on Twitter and UserVoice) comments like:

Hi Scott, unfortunately that wasted space you refer to can't be used until MS changes the licensing on many of their Nuget components (e.g. HttpClient) as these stipulate that they have to be used on Windows systems... making them far from portable!
Are you aware of this, and do you know whether this situation will change in the near future?

Yes, it just changed. We've been lifting these as fast as we could, starting with ASP.NET Katana in July, getting PCLs everywhere, and finally changing licenses on ALL these libraries this week.

The lifting of this restriction also applies to some non-portable libraries like, ALL the Microsoft .NET NuGet Libraries, the Entity Framework and all of the Microsoft AspNet packages.

Go forth and be happy. Even  better, you can use these portable libraries as  dependences to new portable libraries that you create and share.

Ships may turn slowly, but they do turn, and ultimately, in significant ways.

Sponsor: Thanks to Red Gate for sponsoring the feed this week! Easy release management: Deploy your .NET apps, services and SQL Server databases in a single, repeatable process with Red Gate’s Deployment Manager. There’s a free Starter edition, so get started now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
November 14, 2013 22:11
Yes, ships do turn, excited to learn the new licensing changes. So now we can move from PSL (Platform Specific Library) on Xamarin to PCL. No reason not to.

Thanks for pushing to make this happen.
November 14, 2013 22:11
That is cool. On a side note, I think we all got the feeling you were pretty swamped with the VS 2013 release :)
November 14, 2013 22:11
I don't think anyone really doesn't grok the long-time-to-turn-a-big-ship metaphor and Microsoft. The pain-points the community feels from Microsoft's lack of agility really only hurts Microsoft in the long run. (not that you don't feel the same way, just sayin' :)

It's great that there are less restrictions *now*; but until now teams have had to do something else--which may have included leaving the Microsoft stack almost entirely with very little possibility to return despite these changes.
November 15, 2013 0:33
This is AWESOME, thanks to all who pushed and made it happen!
November 15, 2013 3:50
Is it really useful though, have you tried to do anything with it ?

It seems to work ok for simple things but outside of that, the story grinds to a halt.

I have created a portable library targeting Xamarin Andriod and Xamarin ios. Cant add references to:

- Microsoft.Bcl.Compression
- Microsoft.AspNet.WebApi.Client
- Restsharp
- Microsoft.Bcl.Immutable

All have an error similar to "Install-Package : Could not install package 'Microsoft.Bcl.Compression 3.9.73'. You are trying to install this package into a project that targets 'portable-net45+sl50+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."

Referencing Http works so does, but the http api becomes so thin, i.e. there is no HttpClientExtensions, so PostAsJsonAsync is gone.

So to do a simple http request posting json and receiving json requires a lot of ceremony. Still not sure how I'm going to add support for http compression. Looks like I'll go back to file linking instead of the PCL.

The ship might be turning, but without doors, you can't get on....

rant over.

November 15, 2013 4:03
Excellent! This is one more step to promote the CLI as some of the best programming environment out there, regardless of corporate agendas. I long for the day where C# is considered on an equal footing with other languages like Java, C++ and Python when it comes to cross-platform development (in the non-Microsoft sense).

However, from what little contact I have had with them, the PCLs in their current form need to die. When I saw those two Xamarin checkboxes added, I thought "yet another random BCL subset of types and members I won't be able to use because one platform doesn't support them". Portable class libraries should be assemblies whose types and members I can fully rely on when targeting any platform, regardless of which checkboxes I have ticked in some dialog. Adding a Windows Store App target and suddenly getting errors that String.Normalize or some other BCL member does not exist is not a great experience.
November 15, 2013 4:53
@Jimbob you need to install NuGet 2.7.2. One of the fixes was to how it handles portable targets. Once you update you should be able to install those packages in your project.
November 15, 2013 5:29
@Kiliman I'm using Nuget 2.7.41101.299

November 15, 2013 5:38
@Jimbob As Kiliman mentioned, you need NuGet 2.7.2. However I noticed in the error message it looks like your PCL is targeting Silverlight 5, which isn't supported by the packages you got errors with. When you choose just Xamarin.iOS and Xamarin.Android, the PCL target picker is choosing what it thinks is the closest profile, but it's currently not really making the right choice. Try choosing .NET 4.5 and Windows Store apps (Windows 8) along with the Xamarin platforms. (I don't think RestSharp supports PCLs at all, so it probably still won't work.)

@Tristan I think the root problem you are seeing is that the APIs supported by each platform are different. While it's normal to have different feature areas available on different platforms, we do want to avoid arbitrary API differences like you have seen. Starting with .NET 4.5, Windows 8 Store apps, and Windows Phone 8 we have been designing for portability, so you won't see arbitrary individual API differences when targeting those platforms. Also, Xamarin isn't making the problem any worse, as they are not adding new API subsets you can target, just adding support for the existing API subsets that we already had.

For a bit more information about this, see my StackOverflow answer here and the "Why APIs Aren't Portable" section of this blog post.
November 15, 2013 6:24

Thanks for the info. The reason silverlight was targeted was auto selected this, even if you uncheck it, it gets re-checked as believes it doesn't lower the denominator (I guess). It wasn't deliberate.

Following your suggestion, I added windows phone 8 and deselected silverlight. This was a step forward as now I can install the nuget packages. Seems like a broken model though, adding more dependency flags in the PCL allows for a package to be installed, you'd think it would be the other way round.

So at least the package installs, but running it is a different story. I have this simple code in my PCL. (this is sample code, dont judge me)

var handler = new HttpClientHandler
AllowAutoRedirect = true,
CookieContainer = new CookieContainer(),
UseCookies = true,
AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip

var client = new HttpClient(handler) {BaseAddress = new Uri(_baseUrl)};

var responseMessage = await client.PostAsJsonAsync(uri, request);


return await responseMessage.Content.ReadAsAsync<TResponse>();

This compiles, yay, but running it on the IOS device it bombs out with

System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http.Primitives, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

What is the special sauce I'm missing? It should just work right?

November 15, 2013 6:51

Just incase you end up here with your google fu.

So, to get the above working, you will need to add the same nuget packages (http client etc) in your other projects (i.e. iphone app). But then it wont compile anymore. oh nos.

Next step is to follow (repeated here just in case it gets 404'd)

To resolve this issue, remove the following references from your app project (iphone in my case). You will be able to build at that point.


I guess the ship works, but it would be nice if you didn't have to weld it before you can use it...

November 15, 2013 11:54
Wonderful. I like the new direction.
November 15, 2013 16:24
Really awesome ! x.NET!

November 15, 2013 16:59
Hooray, now I only need to compile my shared code to PCL and Compact Framework. :)
November 15, 2013 22:51
@Jimbob Yes, there are some rough edges today, but they'll get fixed over time. I feel like we've just made a huge step forward :-)
November 18, 2013 19:40
Now we just need Microsoft to give proper support to .NET running on Windows, Linux, OSX, etc. A *much* bigger request, I know, but we really need it. If anything, it will grow the number of developers that can write C#.

Please re-open this user voice request Microsoft!

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.