How you store the data on the client side doesn't matter very much. I'd look into IsolatedStorage for your purposes, though. What might be more difficult is to tell when the cache turns stale. This is actually what System.Runtime.Caching is good at. Does the server data change at all, or only after a new release of the application? If the data changes only after a new release, you might want to include it as resources into the application setup. If not, you'd have to have some timeout or signal which tells the client that it is time to check for changed data on the server. Have you already considered lazy loading of the data? That way, the delay would probably not occur all at application startup and would be less noticable, and probably you wouldn't even have to load the complete data into the client.
Regarding Timeouts: in our application, we have a fixed timeout which is set to each reference list when it is first loaded, and every time it is requested from the cache, that timeout is checked. If it has expired, the cache is transparently refreshed before the list is returned. This is a tradeoff, because the data on the client side could be stale for some time. We accept this, because it isn't critical in our case, and that way every list is responsible for itself and we don't need a central registry keeping track of each list's state in order to set the timeout from outside.
