Dajbych.net

Portable Class Li­brary is a uni­ver­sal .NET li­brary. It is de­signed for shar­ing source code for ex­am­ple among WPF, Win­dows Phone and Metro style ap­pli­ca­tions. It may con­tain ev­ery­thing com­mon from tar­get plat­forms. Thanks to the Vi­sual Stu­dio 2010 ex­ten­sion you can start use it im­me­di­ately. Due to .NET Frame­work frag­men­ta­tion the Portable Li­brary is wel­come uni­fi­ca­tion el­e­ment. It is not nec­es­sary to com­pile li­braries against mul­ti­ple .NET plat­forms any­more.

Introduction

Ini­tially we had the .NET Frame­work. Later the Sil­verlight was added then also the Win­dows Phone, next the Xbox 360 and the Win­dows Run­time is com­ing. It is about 5 plat­forms where .NET runs. Types con­tain­ing each of them are slightly dif­fer­ent be­cause ev­ery plat­form is very spe­cific. There is no rea­son to sup­port touch in Xbox 360 like in Metro style app or Win­dows Forms. Win­dows Phone doesn’t need for its SQL Server Com­pact or huge ADO.NET and Entity Frame­work, but a tiny layer ac­cess­ing Code-First ap­proach and LINQ is enough. The Sil­verlight must have dif­fer­ent classes to ac­cess the file sys­tem. Portable Li­brary al­lows choos­ing plat­forms we want de­velop against. The li­brary then runs on cho­sen plat­forms.

It is of­ten needed to de­velop an ap­pli­ca­tion for mul­ti­ple plat­forms. The Portable Li­brary typ­i­cally con­tains code which would be the same on all plat­forms you want to share. It is not the user in­ter­face, which is dif­fer­ent on each plat­form, but mostly the main ap­pli­ca­tion logic. Portable Li­brary is or­di­nary for Model and View­Model and can con­tain even ser­vice ref­er­ence.

Usage

Portable Li­brary is ap­pli­ca­ble to Sil­verlight, Xbox 360, Win­dows Phone 7, Win­dows Phone 8, Win­dows Run­time (Win­dows Metro style app) and full .NET Frame­work. Portable Class Li­brary can­not be used with .NET Mi­cro Frame­work or SQL Server CLR. The Portable Li­brary project could be opened by both Vi­sual Stu­dio 2012 and 2010 if the Portable Li­brary Tools 2 ex­ten­sion by Base Class Li­brary team is in­stalled.

The ex­ten­sion adds a new project type.

At the be­gin­n­ing is nec­es­sary to choose tar­get plat­forms.

The first ver­sion was re­leased on Jan­uary 2011 for Vi­sual Stu­dio 2010. It con­tained ba­sic func­tion­al­ity to be in­ter­ested enough for de­vel­op­ers to try it and send feed­back to the BCL team.

The sec­ond ver­sion for Vi­sual Stu­dio 2010 was re­leased on May 2012. It al­lows as much func­tion­al­ity as Vi­sual Stu­dio 2012 ver­sion.

At Vi­sual Stu­dio 2012 is Portable Li­brary built in.

What is supported

–||–

Architecture with Portable Library

The idea is based on the ab­s­tract class which rep­re­sents the Model. It con­tains the im­ple­men­ta­tion of all the com­mon code from each plat­form. This model is lo­cated in the Portable Li­brary. There is also a View­Model which has a pa­ram­e­ter in its con­struc­tor to pass a ref­er­ence to the plat­form spe­cific model im­ple­men­ta­tion de­rived from the ab­s­tract model.

From the prac­ti­cal view it is not that sim­ple. The async & await key­words are not typ­i­cally sup­ported on each plat­form you want tar­get to. That’s why some ad­di­tional in­ter­faces are re­quired. I cre­ated a sim­ple demo to il­lus­trate the most com­mon pat­ters. Thank you to Daniel Plaisted for pro­vid­ing me the source code of task wrap­pers.

How it works

Profiles

The most com­mon pro­file, which many of de­vel­op­ers al­ready meet with, is the .NET Frame­work Client Pro­file. It is a sub­set of the full .NET Frame­work for build­ing desk­top ap­pli­ca­tions. ASP.NET is not in­cluded there, but it con­tains Win­dows Forms and WPF. The Sil­verlight is a plat­form pro­file be­cause it has s dif­fer­ent im­ple­men­ta­tion com­pared to .NET Frame­work. Its ms­core­lib.dll is not the same as is in the full .NET Frame­work. The same is the Win­dows Phone.

The pro­file is rep­re­sented by set of ref­er­ence as­sem­blies. Those as­sem­blies do not con­tain IL (In­ter­me­di­ate Lan­guage) in­struc­tions but con­tains the meta­data in­stead. Com­piler needs meta­data to know which API calls are valid. Ref­er­ence as­sem­blies for Metro style (Win­dows Run­time) pro­file are lo­cated in C:\Pro­gram Files (x86)\Ref­er­ence As­sem­blies\Mi­crosoft\Frame­work\.NET­Core. You can see there the ms­core­lib.dll and the Sys­tem.Col­lec­tions.dll. Why is this li­brary sep­arated when all col­lec­tions are im­ple­mented in ms­core­lib.dll? The .NET plat­form con­tains sev­eral lay­ers. De­pen­den­cies among them are very care­fully man­aged. For ex­am­ple ms­core­lib.dll does not de­pend on ASP.NET. There are some places where in ret­ro­spec­tive is a mis­take. There are some items which now would be el­i­gi­ble to be sep­arated. Pro­files are trying to fix this. That’s why the Sys­tem.Col­lec­tions.dll and the Sys­tem.Re­flec­tions.dll are sep­arated from the Sys­tem.Run­time.dll (which is an­other name for ms­core­lib.dll).

Platform Fragmentation

All .NET plat­forms have many com­mon but they also dif­fer from each other. The Sil­verlight has a dif­fer­ent ms­core­lib im­ple­men­ta­tion. The Xbox 360 is based on the .NET Com­pact Frame­work. The full .NET con­tains ASP.NET which does not make sense else­where for ex­am­ple on the Win­dows Phone.

Plat­forms are spe­cific mostly be­cause of the user in­ter­face. The in­ter­face INo­ti­fyProp­er­ty­Changed is the core of View­Model. In the Sil­verlight it is lo­cated in the Sys­tem.Win­dows.dll li­brary un­like in the full .NET where is lo­cated in the Sys­tem.dll li­brary. MEF (Man­aged Ex­ten­si­bil­ity Frame­work) is con­tained in the full .NET and in the Sil­verlight but not in the Xbox 360 or the Win­dows Phone. If you un­s­e­lect them you can de­velop mod­ules. When you se­lect the Xbox 360 you can­not use the net­work­ing stack.

Using the functionality for the .NET Compact Framework

The strong type is com­posed by as­sem­bly name, ver­sion num­ber, public key to­ken and re­tar­getable bit. It used to al­low running an ap­pli­ca­tion de­vel­oped against .NET Com­pact Frame­work on the desk­top where is the full .NET Frame­work. This flag is im­por­tant for the CLR which con­tains hard­coded ta­ble which tells: “When you see what­ever as­sembly A with set re­tar­getable flag use as­sem­bly B in­stead.”

When the Portable Li­brary has a ref­er­ence to the Sys­tem.Net.dll which con­tains im­ple­men­ta­tion of the net­work­ing stack the re­tar­getable flag is set. This li­brary ex­ists in the Sil­verlight but in the full .NET is its func­tion­al­ity built in the Sys­tem.Core.dll. What’s why is nec­es­sary to cre­ate a shadow as­sem­bly to for­ward types lo­cated in an­other as­sem­bly.

Type forwarding

Pro­files are work­ing thanks to type for­ward­ing. The as­sem­bly does not have to con­tain the type with its im­ple­men­ta­tion but it can con­tain just a type with its meta­data. The meta­data tells where the ac­tual type is lo­cated. The Portable Li­brary is built against a pro­file. It is lo­cated in C:\Pro­gram Files (x86)\Ref­er­ence As­sem­blies\Mi­crosoft\Frame­work\.NET­Portable. Those li­braries are tech­ni­cally as­sem­blies but con­tain only meta­data. In fact Portable Li­brary does not con­tain ref­er­ences to spe­cific li­brary (but tech­ni­cally still con­tain) but ref­er­ences to meta­data li­braries. This kind of ref­er­ence is called API Con­tract.

TypeRef, TypeSpec and TypeDef

When some as­sem­bly A is us­ing a type from an­other as­sem­bly B in fact it con­tains just a TypeRef. The TypeRef is point­ing to the Type­Spec which de­scribes the type. It is lo­cated in the meta­data as­sem­bly which is the A as­sem­bly com­piled against. The as­sem­bly B which is lo­cated in the spe­cific plat­form con­tains a TypeDef which is re­lated to the Type­Info. The Type­Spec con­tains enough in­for­ma­tion to de­scribe the type but not as much as the Type­Info. The CLR is man­ag­ing the map­ping be­tween the Type­Spec from the pro­file to the TypeDef from the plat­form. Intro­duc­tion of the Type­Spec and the TypeDef is the biggest vis­i­ble change in the .NET Frame­work during the last pe­riod of time. It al­lows Portable Li­brary to run on plat­forms which will be re­leased in fu­ture if they con­tain a sub­set which the Portable Li­brary is de­vel­oped against.