Home Dashboard Directory Help

Cannot control CacheItemPolicy properties from config file by noonand2


 as Deferred Help for as Deferred

Sign in
to vote
Type: Bug
ID: 740522
Opened: 5/4/2012 1:47:10 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
User(s) can reproduce this bug


With reference to the System.Runtime.Caching class in .NET 4.0 it seems possible to only set a limited number of things in the configuration file to wit:
•polling interval
•the amount of memory that that cache is allowed to consume
•the percentage of memory that needs to be hit before the cache will be scavenged

A sample section is shown below:

<system.runtime.caching> <memoryCache> <namedCaches> <add name="NameOfMyCache" pollingInterval="00:05:00" cacheMemoryLimitMegabytes="0" physicalMemoryLimitPercentage="0"/> </namedCaches> </memoryCache> </system.runtime.caching>

However it appears none of the really useful items (IMHO!) are controllable from the config file. These are the options that are all in the CacheItemPolicy class such as AbsoluteExpiration, SlidingExpiration and Priority (I can understand how the Callback functions aren't exposed although I would expect to see some options as to what to do in the event that these were called)

The question is, why is it not possible to do this from a config file or do you have to go away and roll your own custom sections?
Sign in to post a comment.
Posted by Microsoft on 5/7/2012 at 3:17 PM
Thank you for the suggestion. We're tracking this for consideration in a future release.
Posted by MS-Moderator10 [Feedback Moderator] on 5/7/2012 at 4:16 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by MS-Moderator01 on 5/4/2012 at 2:42 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.