14

I am considering porting a third-party library to .NET for Windows Store apps. The library makes excessive use of System.Reflection.Emit.OpCodes via calls to the ILGenerator.Emit method overloads.

In the .NET for Windows Store Apps API, the OpCode structure and OpCodes class are included, but there is no ILGenerator class, and as far as I have been able to find out no replacement either.

I am obviously missing something, but: without the ILGenerator class, what is the purpose of including System.Reflection.Emit.OpCode and OpCodes in the .NET for Windows Store apps API?

Anders Gustafsson
  • 15,837
  • 8
  • 56
  • 114
  • 3
    Good question, but unlikely to be answerable by many. All I could posit is that they're still needed for some internal purposes and that there's no "harm" in exposing them (much as `LocalVariableInfo` is available, but no sensible way I've found to obtain one) – Damien_The_Unbeliever Feb 20 '13 at 07:40
  • 1
    @Damien_The_Unbeliever Many thanks for looking more closely into this issue. I have little experience with the `Reflection.Emit` namespace myself so I thought I'd ask, but apparently it is not immediately obvious why only `OpCode` and `OpCodes` remain available after all :-) – Anders Gustafsson Feb 20 '13 at 08:06
  • 1
    If you need a replacement for ILGenerator.Emit, take a look at Mono - Cecil. I haven't used it, but others use it as an expression tree interpreter: http://www.mono-project.com/Cecil – Philipp Aumayr Feb 20 '13 at 08:20
  • @PhilippAumayr Many thanks for this interesting suggestion. I did a quick Google search and Nuget test, and it does not seem like Cecil is immediately available for WinRT at this point. Not sure how much work it would be to port it, but I might look into this as well. – Anders Gustafsson Feb 20 '13 at 08:33

2 Answers2

1

Good question. While I cannot say for sure, there are only two reasons I can think of that use OpCode / Opcodes (and I cannot really imagine it's used for something else):

  1. Assemble a piece of code using ILGenerator
  2. Disassemble a piece of code using f.ex. MethodInfo.GetMethodBody and then parsing the bytes containing the IL code

Since it's not the former, I guess they're using the latter. The application for this is static code analysis; I myself use it f.ex. to implement some Mocking behavior and figuring out what the lambda expression was that was passed to it (in this case Expressions couldn't be used). Another applications of code analysis that might be more likely in this scenario is checking if certain classes/methods/constructs are used which are disallowed (I can imagine that they don't want you to use certain functionality).

atlaste
  • 30,418
  • 3
  • 57
  • 87
  • Except the latter isn't available in windows store [either](http://msdn.microsoft.com/en-us/library/system.reflection.methodinfo.aspx). – Damien_The_Unbeliever Feb 22 '13 at 07:41
  • Well, there's more than one way to get IL bytes, one way is to upload a DLL somehow and disassemble it manually. Granted, it seems rather far-fetched. – atlaste Feb 22 '13 at 07:45
  • 1
    But all of the framework methods for getting IL bytes seem to be blocked off. Yes, you could disassemble manually - just as you could define the `OpCodes` yourself, if you were going to do so. – Damien_The_Unbeliever Feb 22 '13 at 07:50
  • @StefandeBruijn Interesting aspect, but as Damien points out, `MethodInfo.GetMethodBody` and the `MethodBody` class are not included in *.NET for Windows Store apps*. Would you even consider (manual) disassemby in a *Windows Store app*? This seems more relevant for regular .NET Framework applications. – Anders Gustafsson Feb 22 '13 at 07:53
  • 1
    True, but it would make sense if the store submission process actually uses the same libraries (it seems to do this kind of analysis). It's clear they tried to remove the Emit code - but if you were Microsoft and this is something that might change in the future, this is not something you want to define again. But to be honest I'm just guessing here... – atlaste Feb 22 '13 at 07:53
  • As far as defining them yourself goes: Opcodes could change. That means you probably don't want to define them for yourself. Would I consider manual disassembly? Well it's not like parsing a DLL is so hard, so I guess I created worse things... And yes, I can see the usefulness of a 'Reflector' as WinRT app. – atlaste Feb 22 '13 at 07:59
  • @StefandeBruijn Thanks for looking more closely into this issue. As you also mention, it seems likely that the `OpCodes` inclusion is a preparation for a potential future. We'll see if time will tell. – Anders Gustafsson Feb 25 '13 at 08:39
  • @AndersGustafsson True. I read somewhere that Microsoft plans to add dynamic proxy support for WinRT in the future, but I cannot find the link anymore. At that moment the question is answered I suppose :-) – atlaste Feb 25 '13 at 08:44
1

You may find Mono Cecil useful to replace some of the functions of System.Reflection, officially there is no port of it for WinRT, but unofficially, there is a port available here, just note that is based in the Silverlight version of Mono Cecil.

Also be aware that you can't modify dlls and exes outside your app package, this is a security measure of the WinRT sandbox.

Rafael
  • 2,827
  • 1
  • 16
  • 17