Have you ever heard of .ini files for your .Net assemblies? Neither had I.
It turns out that they do exist, and they have the function of telling the clr how to jit.
I recently ran into a problem at work, where, after upgrading to .Net 4.0, I the application would crash horribly. I had foolishly gone about some massive refactoring as well, so wasn't really sure whether I'd damaged the application during the refactor, or by doing the .Net upgrade. What I did know, is that if I ran the application from inside Visual Studio, it worked. Outside it bombed. A Heisenbug of frustration.
Thankfully, after a half day of doing my bestest debugging (obviously not good enough, and I hadn't stooped to windebug and sos yet), a colleague offered up a solution. I've not really had the time to verify this, but I was told that the .Net 4.0 is far more agressive with it's optimisations than previous versions. As a result, some methods/classes were being inlined that previously had not been. This caused some reflection based work to return the wrong assembly name for a call, and resulted in the application I work on going bang. Not being in control of the assemblies that were exhibiting this behaviour, meant that we had to control the optimisation of the assemblies. Thus, the solution linked above.
Basically, we added a *.dll.ini file for the assemblies we needed to control with the .ini files containing:
[.NET Framework Debugging Control]
This turned off the optimisations that were giving us grief, at the expense of slowing those assemblies down a little.
I wish I could find a more fine tuned way of controlling that optimisation, so that I could for instance, only tell the compiler to not inline certain classes, but for now, this'll have to do. If you know of any, please let me know.