Purpose of Emit.OpCodes in .NET for Windows Store apps API?

Question

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?

Twombly

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) – Nurmi

@Nurmi 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 :-) – Twombly

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: mono-project.com/Cecil – Cornelia

@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. – Twombly

Answer 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).

Ellipsoid

Except the latter isn't available in windows store either. – Nurmi

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. – Ellipsoid

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. – Nurmi

@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. – Twombly

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... – Ellipsoid

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. – Ellipsoid

@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. – Twombly

@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 :-) – Ellipsoid

Answer 2

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.

Romanticist

Thanks, @Rafael, I will give it a second look. – Twombly