Portable Class Libraries just got REALLY useful with new licensing changes
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.
- Async for .NET Framework 4, Silverlight 4 and 5, and Windows Phone 7.5 and 8
- Microsoft ASP.NET SignalR .NET Client
- Microsoft BCL Build Components
- Microsoft BCL Portability Pack
- Microsoft Composition
- Microsoft Compression
- Microsoft HTTP Client Libraries
- Microsoft Immutable Collections
- ODataLib
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.
About Newsletter
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.
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 json.net, 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.
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.
@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.
Thanks for the info. The reason silverlight was targeted was vs.net auto selected this, even if you uncheck it, it gets re-checked as vs.net 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);
responseMessage.EnsureSuccessStatusCode();
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=1.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
What is the special sauce I'm missing? It should just work right?
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 http://blogs.msdn.com/b/dotnet/p/pcl_known_issues.aspx (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.
System.Runtime
System.IO
System.Threading.Tasks
I guess the ship works, but it would be nice if you didn't have to weld it before you can use it...
...
:/
Please re-open this user voice request Microsoft!
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2268376-make-net-real-platform-independent-add-linux-sup
Comments are closed.
Thanks for pushing to make this happen.