While creating my skinning extension, I’m noticing some weird behaviour with the default UserSettingsService returned by the imported IServiceProxy. One would think that this service stores settings that are specific to the user, you know, the one logged in to the LightSwitch application, managed in the LightSwitch’s Security module (users & rights)…
You are correct that the user settigns are not stored in the database. Also the settings are stored on the PC and not “with” the app so it is true that the users settings will not presist across machines.
As far as where we write them to:
On a desktop app we write to “Environment.SpecialFolder.MyDocuments” + \Microsoft\LightSwitch\Settings\[App]
On a web app we use SliverLight Isolated Storage (http://www.silverlight.net/learn/graphics/file-and-local-data/isolated-storage-(silverlight-quickstart)
The settings you can store and retrieve with the UserSettingsService, are saved in locations specific to the currently logged in Windows user, on that particular machine, which is insufficient for our needs.
In my opinion, LightSwitch user settings are a valid candidate to be stored in the default dataworkspace ( i.e. the database). That way, different users can have different settings even if they access the LightSwitch application from the same Windows account on the same machine (unless you use Windows authentication obviously), and the user’s settings persist over different machines.
That’s why, the skinning extension comes with a lengthy install guide asking the developer to “please create this table in the dataworkspace with these specific fields”… Not a good practice, I know, but our hands are kind of tied together because of the LightSwitch UserSettingsService implementation.
Unless of course… We can come up with some kind of alternative…