Creating a New Service Locator Instance

In unit testing scenarios, you must replace the current SharePoint Service Locator instance with a new service locator instance. The reason for this is that the default service locator instance requires access to the SharePoint object model in order to retrieve type mappings, which are stored as farm and site collection scoped configuration settings. By replacing the current service locator before you evaluate the SharePointServiceLocator.GetCurrent() method, you can avoid a run-time dependency on the SharePoint environment.

By default, the IServiceLocator interface is implemented by the ActivatingServiceLocator class. When the SharePoint Service Locator creates an instance of ActivatingServiceLocator, it retrieves type mappings from farm level configuration and adds these to the service locator instance. When you create a new instance of ActivatingServiceLocator manually, you bypass the retrieval of configured type mappings. As such, the service locator doesn't require access to farm-scoped configuration settings and can execute outside the SharePoint environment. Since an SPContext object is unavailable when your code runs outside the SharePoint environment, the service locator will not attempt to load site collection-scoped type mappings.

The following code shows you how to replace the current service locator instance with a new instance of ActivatingServiceLocator for unit testing purposes.

// Create a new service locator instance for unit testing purposes
ActivatingServiceLocator serviceLocator = new ActivatingServiceLocator();

// Replace the current service locator with the new instance

When you create a new instance of the ActivatingServiceLocator class, your service locator instance will not contain any of the default type mappings, such as ILogger. You should also be aware that any types you register in this way will not be persisted to the property bag and will therefore be lost if Internet Information Services (IIS) is restarted. For this reason, you should only create a new instance of ActivatingServiceLocator for unit test scenarios.

After each unit test you can reset the service locator to its original state by calling the Reset method. It is recommended that you call the Reset method as part of the unit test's cleanup step. This puts the service locator back into its original state and prevents tests from interfering with each other.


Failing to reset the service locator often causes other tests within your test suite to fail. If you have a test that succeeds in isolation but fails when run in the suite, there is a good chance you forgot to reset the service locator in one of your tests.
Each SharePoint Web application runs in its own application domain. Calling the ReplaceCurrentServiceLocator and Reset methods only affects the SharePointServiceLocator.Current instance in the current application domain. These methods do not have an effect in other application domains. Therefore, the ReplaceCurrentServiceLocator and Reset methods should only be used within unit tests. If you want to change the type of service locator for your application, you should register a custom IServiceLocatorFactory interface. See Using a Custom Service Locator for more information.

For more information on the ActivatingServiceLocator class, see Adding Type Mappings and Design of the SharePoint Service Locator.

For more information on using the SharePoint Service Locator in unit testing scenarios, see the scenario-based topic Testing Classes in Isolation.