WatiN and Thread.ApartmentState

This article explains why you need to set the Thread.Apartmentstate to STA when using WatiN. If you use a (test) runner which is not mentioned on this page but which needs some special setup to set the apartmentState to STA, please let me know so I can add the info to this page.

Index

  1. Why is setting the ApartmentState needed in the first place?
  2. Differences in ApartmentState between .Net 1.1 and .Net 2.0.
  3. Implications.
  4. Behaviour of WatiN when Thread is not an STA Thread.
  5. Using WatiN in a console or WinForms application.
  6. Using WatiN and MBUnit.
  7. Using WatiN and NUnit.
  8. Using WatiN and MSTest.
  9. Using WatiN and TestDriven.Net in VS 2003 and VS2005.
  10. Using WatiN and SharpDevelop’s NUnit test runner.
  11. Using WatiN and Fitnesse.

Why is setting the ApartmentState needed in the first place?

Copied from MSDN:

“Because COM classes use apartments, the common language runtime needs to create and initialize an apartment when calling a COM object in a COM interop situation. A managed thread can create and enter a single-threaded apartment (STA) that allows only one thread, or a multithreaded apartment (MTA) that contains one or more threads.”.

Since Internet Explorer is not Thread safe we need to use STA.

Implications

Using WatiN works fine in a console or GUI application when you apply the [STAThread] attribute to the main method (the sole entry point of the application). This way the main Thread runs as STA and all goes well. When using a runner like MBUnit, NUnit or any other runner that starts the main Thread, your code/tests depend upon the ApartmentState the runner started with.

Behaviour of WatiN when Thread is not an STA Thread.

WatiN will throw a ThreadStateException when you create an instance of the WatiN.Core.IE class, to help you remind to set the ApartmentState to STA.