Quick tip: five things you should know about the IUserSettingsService in LightSwitch

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:

  1. 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
  2. Ask the VSExportProviderService, a service that allows you to query the MEF container of LightSwitch, for an IServiceProxy implementation, as such: VsExportProviderService.GetExportedValue()
  3. 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.
The third method however, is a bit tricky.  The SetSetting method sets the value/object/setting for a given name (or adds a new entry) to its cache, but it doesn’t persist that value yet.  The values are only persisted right after the IUserSettingsService fired it’s Closing event.  This implies two things:
  • 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.

Advertisements

5 thoughts on “Quick tip: five things you should know about the IUserSettingsService in LightSwitch

  1. Hey John,
    thanks for replying so quickly. This is the second time this week I try to reach out to one particular person and he replies back so soon. 😮
    I added your comment in the original article, thanks for the additional tip!
    Enjoy the holidays!

  2. Thanks for this information Jan!

    Until I read this blog posting, I did not realize that the SetSetting was cached and so it completely explains why values appear to be saved mid-way through the application as I was able to read them back through any subsequent calls to GetSetting but when I stopped the process (debugger) they weren’t. I thought I was going a bit bonkers and was not putting two and two together :-).

    The cool part is that any SetSetting updates you happen to make within your application outside of the normal close event, are also eventually persisted at the point of application close, and since the values are cached by LightSwitch, the instance of your application that is saving state via SetSetting is still able to read back those changes as LightSwitch reads back from the cache.

    LightSwitch Rocks!

    • Hey John!
      Always nice to hear from you, and glad that I could help prevent you from going totally bonkers 😀
      To make things obviously, they should have renamed the event from “Close” to “LastChanceToSaveWhateverYouWantToSaveBeforeThisApplicationWillSelfDestruct”, but anyways, what’s in a name…

      Keep on rocking!

  3. Pingback: Windows Azure and Cloud Computing Posts for 12/28/2011+ - Windows Azure Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s