Customize .NET Portable Class Library Profiles? -

i need add and/or modify profiles allow more classes , members shared in pcl (many of them built-in in framework, such thread.sleep). what's best way this? there tools that?



ps: i'm not seeking anwser tell me no or stop. want have compile-once dlls may shared in different environment. no per-platform binary, no recompile, no ifdef.


following got far:

requirement:

• target environements: silverlight 5 , .net framework 4.5.
• purpose of pcls: shared infrastructure ria client , asp.net server (without wcf)
• what's lacking in default profiles: xpath, thread methods, dynamicmethod/ilgenerator

pcl profiles: under reference assemblies\microsoft\framework.netportable:

• all assemblies stubs, "retargetable" attribute set.
• all assemblies have flags = 0x171: 0x001 signed, 0x100 retargetable, , 0x070 undefined in assemblynameflags (appears have no effect)
• all references between assemblies "retargetable" attribute well.
• all assemblies silverlight support versioned 2.0.5.0.
• built pcl binaries contain 2 references each of referred assemblies (ex: mscorlib 2.0.5.0 retargetable + mscorlib 4.0)

customization attempt #1

• profile: silverlight 5 + .net framework 4.5 (profile 24)
• copy sl5 mscorlib.dll profile 24
• mark sl5 mscorlib.dll retargetable (change delay signed)
• resharper: failed resolve extension methods, error in generic type/value match
• build: success, run: success

customization attempt #2

• profile: silverlight 5 + .net framework 4.5 (profile 24)
• copy sl5 dlls profile 24
• mark sl5 dlls retargetable (change delay signed)
• mark references between sl5 dlls' retargetable
• resharper: failed resolve extension methods, error in generic type/value match
• build: success, run: success

customization attempt #3

• profile: silverlight 4 + .net framework 4.0.3 (profile 18)
• copy sl4 mscorlib.dll profile 18
• mark sl4 mscorlib.dll retargetable (change delay signed)
• resharper: success
• build: success, run: success

customization attempt #4

• profile: silverlight 4 + .net framework 4.0.3 (profile 18)
• copy sl4 dlls profile 18
• set .net runtime version of sl4 dlls v4 (original dlls have that, unknown of effects)
• mark sl4 dlls retargetable (change delay signed)
• mark references between sl4 dlls' retargetable
• resharper: success
• build: success, run: success

customization attempt #5 inherit #4

• profile: silverlight 4 + .net framework 4.0.3 (profile 18)
• add sl4's system.numerics (included in other sl profiles) redistlist\frameworklist.xml
• add sl4's system.xml.xpath (not included in sl profiles) redistlist\frameworklist.xml
• result: unable resolve system.numerics , system.xml.xpath default pcl references
• fixes: reference both dlls manually - unable force them retargetable, though vs wouldn't compile non-retargetable system.numerics or system.xml.xpath due noted problem below

notes:

• compile error: "... defined in assembly not referenced, must add reference assembly". happens after assemblies made retargetable 1 of references between them not changed "retargetable"

it works degree, quite troublesome customize existing referenced dlls or add new ones, nor can 1 validate pcl code after overriding referenced dlls (if possible @ all).

since won't take no or stop answer let me try explain why bad idea. short answer is: if pcl doesn't expose api it's because won't work.

first of pcl doesn't have it's own set of apis. pcl exposes intersections of apis between given set of platforms want target. now, there cases api level intersection yield more apis pcl exposes. there several reaons why might case.

1. the api isn't available on platforms
2. the api available doesn't work
3. the api defined in different assemblies

the first 1 should obvious. pcl isn't actual platform exposes what's there. can't give apis don't exist across platforms target. after all, expose intersection.

the second 1 sounds bit strange happen. take, example, file io on windows phone 7. althought file class technically available on windows phone, it's documented as

this type present support .net compact framework infrastructure in silverlight windows phone, , not intended used in application code.

you may "what care?" , try find out security model on phone prevent accessing files looking for. exposing api in pcl not helpful. in fact, our team believes hurt because leads down non-portable path.

the third issue around apis being implemented in different assemblies bit more involved. in order understand why issue need consider how clr handles apis in general. clr doens't have concept of loading indiviual types as, example, java does. in .net types implemented in assemblies , in order use them ("load them"), need load assembly defines type. under covers, type references include both, namespace qualified type name assembly type defined in. in general, types have same namespace qualified name live in different assemblies considered different. example, type mynamespace.mytype, assembly1 , mynamespace.mytype, assembly2. please note assemblies have notion of qualified name well; includes assembly name , public key token. allows 2 companies produce both assembly called "foo" , not confuse clr (assuming, of course, signed different keys). in essence loading type requires few steps: finding assembly type defined in, loading assembly, , loading type.

usally, different .net platforms use different keys platform assemblies, example, mscorlib. may wonder how can use types silverlight on .net framework. reason clr has concept of assembly unfification. assembly unfication allows .net framework treat references silverlight's mscorlib references desktop version. valid because silverlight's mscorlib designed subset of .net framework version (for particular combination of versions is).

although may sound silver bullet bridge paltform differences, it's not. on time, different platforms chose different assembly factorings. take, example, icommand. it's available in .net 4 , silverlight 4. however, in wpf it's implemented in presentationcore.dll while silverlight put in system.windows.dll. understand why pcl doesn't expose icommand when target .net 4 , silverlight 4 let's see happen if pcl expose it.

in pcl, have put icommnad in assembly. either chose use silverlight assembly or full framework one. no matter 1 pick, type not resolve on other platform presenationcore.dll exists in .net 4 , system.windows.dll exists in silverlight 4.

we solved problem allowing references icommand in system.windows.dll succeed on full framework. how did this? answer type forwarding. type forwarding allows assembly "i define type foo". when clr tries load type foo assembly, assembly says "no, no -- type foo defined in other assembly bar". in other words, assembly foo contains pointer bar's version of type. call pointers type forwarding entries.

this concept allowed solve icommand mismatch adding system.windows.dll full framework contains type forward actual implementation. pcl gives icommand in system.windows.dll , can sure type load requests can succeed on both, .net framework silverlight. this, however, requires target @ least .net framework 4.5 previous versions didn't had type forward.

for apis should exposed aren't working platform owners close gaps. have 2 strategies that:

1. we ask platform owners add missing apis or type forwards
2. we ship portable implementation in out-of-band fashion. take example async or httpclient.

however, "just" addding pcl doesn't work.

edit: if miss feature in pcl can unblock yourself. our tester daniel has written blog post shows few techniques can use.