1

Long story short, I'm using a framework which will throw ExecutionEngineExceptions if I call certain LINQ methods. Similar to the way that I can use Reflection to see which types are defined in an assembly, I want to be able to see which methods are actually called in the assembly.

I know there are standalone tools which do this, but I want to easily run this check as part of a checkin process and fail the build process if it finds any of these.

vargonian
  • 3,064
  • 3
  • 27
  • 36
  • Obsolete used with `true` as a parameter causes build errors. – Simon Whitehead Oct 24 '13 at 23:37
  • @SimonWhitehead OP wants to forbid using LINQ methods, so they can't be marked with `Obsolete`. – BartoszKP Oct 24 '13 at 23:40
  • Closest thing that might suit your needs I've found: [link](http://programmers.stackexchange.com/questions/152912/warn-about-3rd-party-methods-that-are-forbidden). – BartoszKP Oct 24 '13 at 23:50
  • @HansPassant It's not some random crash; it's a known issue in MonoTouch when building on an iOS device (since iOS requires ahead-of-time compilation). So, I don't need to debug ExecutionEngineException; I just need to prevent code from being checked in which isn't supported when compiled on device. – vargonian Oct 25 '13 at 04:20

2 Answers2

2

You can user Debugging API or Profiling API (unmanaged) to be able to examine what's happening in runtime. This is what profilers usually do. Reflection API can't give you runtime information.

More generally, what is called depends on the program state, and you don't have access to this before you run (i.e. during build) to be able to know what actually gets called you need to run the whole thing provide it with all the input that you normally give it and than you might be able to find out what gets called. Of course if you provide different input what's get called can also be different.

I use "input" in a very broad sense in the paragraph above. For example current value of the clock can also be considered an input (if the software uses it in any shape or form of course)

Update Based on your clarification, you can use GetMethodBody method to examine method bodies and find out what they might call.

You also might find this question and answers useful.

Community
  • 1
  • 1
Andrew Savinykh
  • 25,351
  • 17
  • 103
  • 158
  • I don't care if the code is *actually* called; I just want to ensure that it's not *potentially* called anywhere in any method defined in the assembly. Tools like Reflector seem to be able to discover this information. – vargonian Oct 25 '13 at 00:07
  • GetMethodBody and the MethodBody class appear to do exactly what I need, thank you very much. – vargonian Oct 25 '13 at 00:15
  • @vargonian note though that you might need mono.cecil library to "decypher" the byte stream of MSIL. Reflection API alone won't be enough. See the last link in the answer for the details. – Andrew Savinykh Oct 25 '13 at 00:20
0

If I understand your question correctly...

You have a 3rd Party Linq Provider, and that Linq provider does not support everything that you can express with Linq syntax and it will throw a runtime error if the Linq statement isn't supported...is that correct?

If that's it, then it is pretty tough to identify at compile/build time the unsupported Linq statement, with static analysis you would need to parse the code to identify it.

Of course there is a different way, and that is with Unit Testing, write unit tests that exercise the code, and run the tests from the build server, fail the build if the tests fail. You can also use a code coverage tool, to determine how much of your code is covered by tests, you can do this at a class level as well.

Tim Jarvis
  • 18,465
  • 9
  • 55
  • 92
  • Well, the details aren't important, but I'm using the Unity game engine which uses MonoTouch, and when compiled on an iOS device, it will fail at runtime if you call IEnumerable.OrderBy() anywhere in your code, for example. I would have loved and preferred the unit testing solution, but unfortunately the failure will only happen on an iOS device, and our unit tests are not run from an actual device. – vargonian Oct 25 '13 at 00:09