I ran into the same problem a few days ago. As unbird mentions you must dispose of any device resource you acquire a reference to by calling Get* functions. One thing to remember is that Dispose() does not destroy the resource, it simply decreases the reference count and invalidates said reference, the resource itself is only destroyed when it hits zero. So in theory this should work:
using (Resource resource = CubeMapSRV.Resource)
resource.DebugName = "sky cubemap";
In practice, I prefer to avoid messing around with reference counters and instead created a helper class which stores a resource and provides non-reference-counted access to SRV's, RTV's, UAV's, ... By the way, this problem also applies to ImmediateContext and a bunch of other stuff, and you don't need to set variables to null after disposing them. I think the underlying issue is that the C# memory management model does not quite map to how DirectX works, so you need to be a bit more careful with what you do to avoid making incorrect assumptions.
Edited by Bacterius, 31 October 2013 - 03:42 PM.
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis