I opened my blog today to write two lengthy posts, when I noticed in the site statistics that someone is repeatedly hitting my blog because he/she is having some problems with the LightSwitch IUserSettingsService implementation… Whoever you are, this quick one is for you…
What is the UserSettingsService?
The UserSettingsService is an internal implementation of the Microsoft.LightSwitch.Runtime.Shell.View.IUserSettingsService interface. The name of the interface, and the namespace it’s in, already reveal what it’s purpose is: persisting and retrieving any kind of specific user settings, to use in any of your client side code: your LightSwitch application, a custom shell, a custom theme, user control, … You can see it in action in the Shell extension walktrough on MSDN.
How can I access the UserSettingsService?
To get a reference to the implementation:
- make sure you added a reference to the Microsoft.LightSwitch.SdkProxy.dll assembly. You can find the dll where your visual studio is installed. So in my case: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\\LightSwitch\1.0\Client\Microsoft.LightSwitch.SdkProxy.dll
- Ask the VSExportProviderService, a service that allows you to query the MEF container of LightSwitch, for an IServiceProxy implementation, as such: VsExportProviderService.GetExportedValue()
- The returned IServiceProxy has a property called UserSettingsService. Retrieve the value.
When should I save my settings?
The IUserSettingsService has three methods, and one event. The first two of the three methods are self-explanatory:
- GetSetting retrieves the object/value/setting that was previously stored for a given name, or returns null if no value exists in its cache for that name.
- ResetSetting clears the object/value/setting that was previously stored for a given name.
- Since your values are only persisted right after this event, it’s considered best practice to subscribe to this event (ie: add an event handler), then call the SetSetting method for each of the key/value pairs you wish to save.
- The Closing event originates from the application Closing event (this means: closing the browser/current page tab for in-brower applications, or hitting the red X at the top right of your out-of-browser application). If you kill the process of your LightSwitch application, the event will not fire and thus none of your settings will be persisted. This implies that when you use the Stop Debugging (Shift-F5) command from Visual Studio, none of your settings will be persisted.
Why won’t it save my settings?
Each time you start a LightSwitch in-browser application (ie: project>properties>application type>web), the application will have a different ID. Because this ID is used to locate the folder on your hard disk where the settings are persisted, the LightSwitch application will retrieve a different folder each time. This means that using the IUserSettingsService does not work for in-browser LightSwitch applications that are started from Visual Studio. Suggested solution: switch to a LightSwitch desktop application to test, when you deploy as a web app it will work just fine.
Where are my settings persisted?
According to Bill R, they are stored in your MyDocuments folder for a LightSwitch desktop app, and in the SilverLight Isolated Storage for a LightSwitch web app.
As I described earlier, this implies that the “User” in “IUserSettingsService” is referring to the Windows User, not, as one might suspect, the user currently logged in to your LightSwitch application.
This also implies that because the IUserSettingsService is using the SilverLight Isolated Storage for LightSwitch web apps, there is a maximum quota of 1MB per LightSwitch app to store your settings.
And a special bonus tip…
Only 45 minutes after posting, a bonus tip came in from John Kears, a fellow LightSwitch hacker. 🙂
Moral of my story, is that you need to be certain that any type that you plan to save out as a usersetting, must be serializable else make it so.