Is my ObjectCache wrapper sound?
As Magus pointed out in the comments, making everything static can present some issues. Using these static properties in other classes makes those classes tightly coupled to the Cache class. Why should you care? Consider this class:

public class Bar
{
    public int DoSomething()
    {
        return 5 + Cache.CachedNumber;
    }
}


You've lost your ability to test DoSomething() in isolation from the rest of your code. Any time you test DoSomething(), it relies on a specific implementation of Cache. It also makes it difficult to use the Bar class with different cache types (in memory, database, file system, etc.). Ideally, Bar would look something like this:

public class Bar
{
    private ICacheProvider Cache { get; set; }

    public Bar(ICacheProvider cache)
    {
        this.Cache = cache;
    }

    public int DoSomething()
    {
        return 5 + Cache.CachedNumber;
    }
}


Now we can:


Test that DoSomething is doing its job, regardless of flaws in the ICacheProvider instance (by passing a mock ICacheProvider that always returns CachedNumber = 3, for example).
Pass in different ICacheProvider implementations that can very depending on my use case, and Bar will still work without caring about them.


Also, I would suggest not using something as vague as Cache or ICacheProvider (used for illustration). Once you start caching a lot of things, you may want to cache different properties differently, at which point your super cache class will become too large to maintain. Consider breaking it up into meaningful repositories that can implement caching however they want, or something similar.