1
votes

I have a portable class library that targets WSA, NET45 and WP8, and I would also like to target SL5. What's silly is that 99% of the library code is SL- compliant, but in has a couple of places where I make a call to a reflection API to retrieve type property or field:

var fields = myType.GetTypeInfo().DeclaredFields;

Unfortunately GetTypeInfo is not available in SL5, so the above code won't compile. So I basically have there options:

  1. Don't target SL5 from the PCL, so I will need to keep a separate library for Silverlight.
  2. Extract from PCL code that uses reflection, so PCL will need to resolve this dependency on start.
  3. Do something smart at runtime, so PCL can detect what methods are available and call the appropriate one.

Option 1 is ok, but I'd rather find an alternative to maintaining a duplicate library. Option 2 would be ok if I had to extract a large piece of functionality so it would be worth introducing a bootstraper. When it's a couple of lines that don't compile it's silly to drag DI/IoC.

So I am thinking about option 3 without clear understanding if it's even possible. Reflection is my friend, but it's a reflection API mismatch that I am trying to overcome.

Advises/experience sharing is appreciated.

2

2 Answers

1
votes

After playing with the code it struck me that I could simple use old way of retrieving fields:

var fields = myType.GetFields(BindingFlags.Public | BindingFlags.Static);

I was under impression that because of reflection API change this syntax is not available in PCL, but it was in fact opposite: using this syntax I can target both .NET 4.0.3, .NET 4.5, .NET for WSA, WP8 and SL5.

-1
votes

How about this?

Reflection.Assembly = Reflection.IntrospectionExtensions.GetTypeInfo(GetType(*anyTypeInAssembly*)).Assembly