如果要申请配额，可以在构造里检查存储配额然后执行一下代码，但要考虑到用户可能阻止该请求：

using (var store = IsolatedStorageFile.GetUserStoreForApplication())
{
    Int64 IsoQuota = store.Quota; //单位为bytes
    Int64 requestIsoQuota = 1000;
    if (store.IncreaseQuotaTo(IsoQuota +requestIsoQuota )) //增加到指定大小
    {
       //……
    }
}

执行上述代码将自动提示用户"是否要增加可用存储"，结果如下图2：

为了保持默认的1MB默认存储，我们选择“否”以便于后面的测试，如果选择了“是”也没关系，我们可以在应用程序存储选项页中选择该程序删除网站对应的存储使其重新初始化到1MB。在上述代码中，我们请求增加的配额为1000bytes，但是提示请求的大小依然是默认的配额1MB，这里Silverlight是如何显示申请存储配额时请求的大小的呢？

经测试发现，Silverlight对请求的大小采用了小数点保留一位四舍五入的策略，上图的请求的大小实际上就是上述代码中(IsoQuota +requestIsoQuota)除以(1MB*1024*1024)四舍五入保留一位小数的结果。在默认配额情况下，如果请求的配额requestIsoQuota 小于0.05MB=52428.8bytes=52429时，提示请求到的存储大小的小数位将被忽略，但这并不影响实际的存储配额，提示请求的大小依然是1.0MB，如果requestIsoQuota大于或等于0.05MB=52428.8bytes（requestIsoQuota类型为Int64，即requestIsoQuota最小为52429时提示请求大小为1.1MB）将提示请求大小为1.1MB。这里我们可以来验证一下，将requestIsoQuota的值更改为52428，提示请求的大小为1.0M，选择“是”对其进行增加可用存储，然后将requestIsoQuota的值更改为1，这时候的提示是请求的大小为1.1M，这也就从侧面反映了显示出来的请求的大小并不影响实际的存储配额，虽然他们可能是不一致的。