This environment disables AutoInstall because it can cause problems with tests that use Windows Forms and that require COM message pumping. Just because a thread happens to instantiate a Control does not imply that it should always be enlisted into the Windows Forms synchronization context.

Specifically this setting change resolves an obscure hangs that can occur. Creating a Form will auto-register the WindowsFormsSynchronizationContext. This is fine as long as a message pump is running in the thread. However as is typical with tests, such message pumps are short-lived so soon enough there is no pump. Now when a system event like UserPreferenceChanged occurs, the SystemEvents class will try to synchronize with the registered handler using a WindowsFormsSynchronizationContext but there is no pump running. The call hangs indefinitely. What's more, the test runner will not be able to unload the AppDomain because it will remain stuck in native code!

As a work-around, we disable auto-installation of the Windows Forms synchronization context.

For more information, see the following: http://ikriv.com/en/prog/info/dotnet/MysteriousHang.html http://www.aaronlerch.com/blog/2008/12/15/debugging-ui/