Because there are now two distinct phases ”the first when the language compiler creates the .exe or .dll, and the second when the JIT compiler executes the program at runtime ”an intriguing possibility becomes available.
Normally, you want a production program to execute fast during normal execution. Because enabling debug tracking lowers performance a little and disabling code optimization can lower performance significantly, you usually want to turn off debug tracking and turn on code optimization. But when you need to investigate a production problem, you want the ability to turn debug tracking on and code optimization off. If you could manage both of these settings on a per-execution basis without having to recompile your program, you could have the best of all possible worlds .
Step forward a configuration file called MyApp .ini, where MyApp is the name of your program. If you place this file with this name in the same folder as your .exe or .dll, it allows you to configure these two JIT compiler settings on a run-by run basis. The lines in the INI file that control these settings are as follows , where 1 = true and 0 = false:
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
This allows you to override the debug tracking and optimization settings that were specified when the .exe or .dll was built. It's ideal for investigating those troublesome production problems that you're unable to duplicate on your own machine. As long as you make sure that the correct debug symbol (.pdb) file is available, you can step through source code and do full debugging without having to recompile your production program or having to revert back to a debug version of your code.